Bug 194359

Summary: bsdinstall(8) should set active flag in GPT PMBR if not booting using EFI
Product: Base System Reporter: Colin Percival <cperciva>
Component: binAssignee: Allan Jude <allanjude>
Status: Closed FIXED    
Severity: Affects Some People CC: allanjude, banym, emaste, hans, info, jrm, lidl, marcel, marcis.lielturks, pi, re, rodrigc, sbruno, vangyzen
Priority: ---    
Version: 10.1-STABLE   
Hardware: amd64   
OS: Any   
Attachments:
Description Flags
make zfsboot set pmbr active flag if booted via BIOS
none
Fix syntax error in previous patch none

Description Colin Percival freebsd_committer 2014-10-14 22:54:40 UTC
As mentioned in bug #133493, some systems will not boot if there is no "active" slice in the "MBR".  Others, such as my laptop, will boot but only after printing "Invalid partition table!" and waiting for someone to hit Enter.

This was fixed in 2009 by r198097; but it turned out that this broke EFI booting (since EFI requires that the GPT protective MBR has no active bits set).  EFI was unbroken 16 months ago by r251588... but this re-broke non-EFI booting on the affected machines.

It seems to me that the right compromise here would be for bsdinstall to set the "active" flag if and only if a system is being set up for GPT with "legacy" booting.
Comment 1 Allan Jude freebsd_committer 2014-10-14 23:15:02 UTC
Is there an easy way to do that? Generally we're just installing what is in the '/boot/pmbr' file. I don't think the gpart utility has the ability to set this flag.

We either need gpart to be able to do that, or a 2nd file like /boot/pmbr.active
Comment 2 Colin Percival freebsd_committer 2014-10-14 23:17:57 UTC
Very easy, once you know how: gpart set -a active <disk name>
Comment 3 Marcel Moolenaar freebsd_committer 2014-10-15 00:37:14 UTC
Indeed. The set attribute command was deliberately changed to apply not just to partitions, but also to the scheme itself. This made it possible to to set the active flag in the PMBR for the GPT scheme, even though GPT partitions themselves do not have an active flag.

If the installer knows what the firmware is ((I don't know if we pass anything from the loader to the kernel), then it can indeed set the active flag in PMBR when the firmware is a BIOS and not do that when the firmware is (U)EFI. And only do this on x86...
Comment 4 Colin Percival freebsd_committer 2014-10-15 00:53:56 UTC
I have only a very vague notion of how booting works these days, but my understanding is that we're already setting up things differently based on whether we expect to boot via BIOS or UEFI; and that (aside from when using a ZFS root, which is incompatible with UEFI) the installer detects how it was booted and sets up the system to boot the same way.

If the above is correct, I think all we need is a "if we're setting up the disk to be booted via BIOS, gpart set -a active it".  Allan, does this make sense?
Comment 5 Allan Jude freebsd_committer 2014-10-15 01:03:58 UTC
I don't have one of the systems that does not work, so it is hard for me to test.

Who has a system that refuses to boot if the fake partition in the fake MBR used in a GPT partition table is not set to active? Does running the gpart set command from the install cd then make it work?

What systems refuse to boot if it IS set active?
Comment 6 Colin Percival freebsd_committer 2014-10-15 01:12:10 UTC
Allan: My laptop doesn't refuse to boot, but it does behave badly (bogus error message) when booting via BIOS + GPT if the fake MBR is not set to active.  Running the above-mentioned command fixes this.

My understanding from Marcel's commit r251588 is that having the fake MBR set as active breaks UEFI booting, but I haven't tested this myself.
Comment 7 Allan Jude freebsd_committer 2014-10-15 01:15:56 UTC
Ok, I can test the UEFI stuff on this side.

I can easily add the gpart set to the zfsboot portion of bsdinstall

Although I might make more sense to add it elsewhere to make it apply to Nathan's parts of the installer as well.

We can detect if the installer was booted BIOS or UEFI from a sysctl: machdep.bootmethod
Comment 8 Craig Rodrigues freebsd_committer 2014-10-15 03:24:19 UTC
@Allan: I installed FreeBSD with GPT/ZFS on an HP Elitebook 8460p laptop, with BIOS, not using EFI.
The system would not boot until I set the active partition.
Comment 9 Ed Maste freebsd_committer 2014-10-15 19:06:00 UTC
> If the installer knows what the firmware is ((I don't know if we pass anything from the loader to the kernel))

We report if the system was booted by BIOS or UEFI via the machdep.bootmethod sysctl (returns BIOS or UEFI).

I think this won't help though, because it returns BIOS for both the legacy BIOS case and the UEFI CSM (i.e. simulated BIOS) case, and based on the discussion here it seems (some) real BIOS needs the PMBR active flag set while CSM needs it unset.
Comment 10 Hans Ottevanger 2014-10-15 19:33:02 UTC
(In reply to Allan Jude from comment #7)
> Ok, I can test the UEFI stuff on this side.
> 

Allen,

Back home I have a legacy system that is affected by this issue and another one that isn't, see:

https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080500.html

Whenever I get home (hopefully by tomorrow) I can help testing. Both systems are available, nothing else is currently running on them.
Comment 11 Marcel Moolenaar freebsd_committer 2014-10-15 20:01:54 UTC
(In reply to Ed Maste from comment #9)
> > If the installer knows what the firmware is ((I don't know if we pass anything from the loader to the kernel))
> 
> We report if the system was booted by BIOS or UEFI via the
> machdep.bootmethod sysctl (returns BIOS or UEFI).
> 
> I think this won't help though, because it returns BIOS for both the legacy
> BIOS case and the UEFI CSM (i.e. simulated BIOS) case, and based on the
> discussion here it seems (some) real BIOS needs the PMBR active flag set
> while CSM needs it unset.

I guess that means we need to be able to distinguish between true BIOS and UEFI CSM. There seems to be some code for that:

http://kernel.ubuntu.com/git?p=cking/debug-code/.git;a=commit;h=2e654e01bf4014b27387cf64bb03316064478eea

I have no idea how well this works or if this is at all a legit way to do that.
Comment 12 Ed Maste freebsd_committer 2014-10-15 20:17:45 UTC
From that file:
>  73         if (stat("/sys/firmware/efi", &buf) != -1)
>  74                 flag |= EFI_SUPPORT;

I'm not sure if Linux creates /sys/firmware/efi for the legacy boot case, but if so we'd need to find out how it does that.

Do we know which systems fail to boot with PMBR active bit set in the non-(U)EFI boot case?
Comment 13 Marcel Moolenaar freebsd_committer 2014-10-16 01:08:00 UTC
(In reply to Ed Maste from comment #12)
> From that file:
> >  73         if (stat("/sys/firmware/efi", &buf) != -1)
> >  74                 flag |= EFI_SUPPORT;
> 
> I'm not sure if Linux creates /sys/firmware/efi for the legacy boot case,
> but if so we'd need to find out how it does that.
> 
> Do we know which systems fail to boot with PMBR active bit set in the
> non-(U)EFI boot case?

I known ia64 rejects the partitioning entirely. I belief lstewart@ ran into the problems on x86 that triggered the change to not set the active flag by default.
Comment 14 Craig Rodrigues freebsd_committer 2014-10-16 01:21:43 UTC
lstewart described the problem he encountered here:

https://lists.freebsd.org/pipermail/freebsd-fs/2012-August/014864.html
Comment 15 Mark Linimon freebsd_committer freebsd_triage 2014-10-17 23:42:54 UTC
reclassify.
Comment 16 Ed Maste freebsd_committer 2014-10-21 18:45:27 UTC
Presumably the change desired here is in gpart_ops.c::gpart_activate, adding scheme == GPT && x86_bootmethod() == BIOS to the list of schemes already there (MBR, EBR, PC98)
Comment 17 Allan Jude freebsd_committer 2014-10-21 21:17:55 UTC
Created attachment 148547 [details]
make zfsboot set pmbr active flag if booted via BIOS

The attached patch changes zfsboot ("ZFS Auto Mode" in the installer, not guided/manual mode) to set the pmbr active flag if the machdep.bootmethod = BIOS

This needs testing by those with applicable hardware.

I'll try to generate a .ISO with these changes later tonight.
Comment 18 Allan Jude freebsd_committer 2014-10-22 00:15:30 UTC
I've modified a pair of Glen's 11 snapshots to use this patched bsdinstall

http://freebsd.bsdbasement.com/

I provided a bootonly .iso and a mini-memstick

both have the MANIFEST file removed, so bsdinstall will install whatever is the latest snapshot on FTP without complaining about checksums

If those with machines that exhibit this issue could test the 'Auto (ZFS)' mode in the installer and see if it solves the problem (it does a gpart set -a active $disk'
Comment 19 Allan Jude freebsd_committer 2014-10-22 00:16:54 UTC
Created attachment 148553 [details]
Fix syntax error in previous patch

Updated patch
Comment 20 Hans Ottevanger 2014-10-22 12:47:10 UTC
(In reply to Allan Jude from comment #19)

I just tried the modified boot-only iso on an Intel DP965LT. After an Auto (ZFS) install the system now reboots without any problems. Auto (UFS) still has the same issue as before ("No bootable device -- insert boot disk and press any key"). which of course is as expected.

On my Asus NL4VM-DH installing UFS works, but I still get a message about 
being unable to read the backup GPT header. Rebooting a ZFS installation fails (register dump followed by "BTX halted"), but that also happens when installing 10-RC2 on ZFS, so I do not think this is relevant to the issue at hand.
Comment 21 Allan Jude freebsd_committer 2014-10-22 15:02:05 UTC
(In reply to hans from comment #20)
> (In reply to Allan Jude from comment #19)
> 
> I just tried the modified boot-only iso on an Intel DP965LT. After an Auto
> (ZFS) install the system now reboots without any problems. Auto (UFS) still
> has the same issue as before ("No bootable device -- insert boot disk and
> press any key"). which of course is as expected.
> 

Thanks for taking the time to test this for me. So it does seem that this is solving the problem

> On my Asus NL4VM-DH installing UFS works, but I still get a message about 
> being unable to read the backup GPT header. Rebooting a ZFS installation
> fails (register dump followed by "BTX halted"), but that also happens when
> installing 10-RC2 on ZFS, so I do not think this is relevant to the issue at
> hand.

Is there anything special about your disk setup that might cause issues with the very last sector? Some motherboard RAID and other types of things store their metadata in the last sector, and can clash with GPT, although those are supposed to make the logical drive 1 sector smaller so that this doesn't happen.

Is that NL4VM-DH using UEFI?
Comment 22 Hans Ottevanger 2014-10-22 16:45:39 UTC
(In reply to Allan Jude from comment #21)
> (In reply to hans from comment #20)
> > (In reply to Allan Jude from comment #19)
> > 
> > I just tried the modified boot-only iso on an Intel DP965LT. After an Auto
> > (ZFS) install the system now reboots without any problems. Auto (UFS) still
> > has the same issue as before ("No bootable device -- insert boot disk and
> > press any key"). which of course is as expected.
> > 
> 
> Thanks for taking the time to test this for me. So it does seem that this is
> solving the problem
> 

Definitely, but for ZFS only. A similar change could be done for UFS, or something like in comment #16 could be implemented.
 
> > On my Asus NL4VM-DH installing UFS works, but I still get a message about 
> > being unable to read the backup GPT header. Rebooting a ZFS installation
> > fails (register dump followed by "BTX halted"), but that also happens when
> > installing 10-RC2 on ZFS, so I do not think this is relevant to the issue at
> > hand.
> 
> Is there anything special about your disk setup that might cause issues with
> the very last sector? Some motherboard RAID and other types of things store
> their metadata in the last sector, and can clash with GPT, although those
> are supposed to make the logical drive 1 sector smaller so that this doesn't
> happen.
> 

The disk was in use as single disk for ages in this same system. For now I blame it on the BIOS.

> Is that NL4VM-DH using UEFI?

No, it is a board from 2006, it has a BIOS. I only included these results to show that something that worked before, i.e. installing UFS without the "does not boot" issue, still works with your change. The NL4VM-DH is too rare to worry about much.
Comment 23 Joseph Mingrone freebsd_committer 2014-10-23 01:10:41 UTC
I tested the modified image with a Lenovo X220, which refuses to legacy boot anything GPT.  It wouldn't even boot the USB image unless I UEFI boot. I installed to an external drive with the auto ZFS option, but not luck legacy booting off that drive.  I'm thinking the booting issue with the X220 is a different issue, i.e., not related to setting the active flag in GPT PMBR.
Comment 24 Dominik Zajac 2014-10-24 15:04:34 UTC
I tested the image including the fix on a Lenovo T420 with no luck. 

Here my status:

- Booting the image from USB in UEFI mode worked.
- Booting the image from USB in Legacy Only didn't work. 
 
Installing zfs without encryption just with default values didn't lead to a booting sytem after reboot. 

As far as I understood the UEFI/Bios bug reports in that specific version of Thinkpads not only checks the partition active status. It looks like the type of the first partition is part of the problem, too. 

I stumbled over this manual fix but had no time to try it. It looks just like a dirty workaround to have a useless first partition to trick the UEFI/Bios.
Comment 25 Dominik Zajac 2014-10-25 08:42:33 UTC
Sry. Forgot the link to the manuall fix/workaround:

http://lists.freebsd.org/pipermail/freebsd-i386/2013-March/010437.html
Comment 26 Kurt Jaeger freebsd_committer 2014-10-25 20:20:30 UTC
(In reply to Joseph Mingrone from comment #23)
> I tested the modified image with a Lenovo X220, which refuses to legacy boot
> anything GPT.

I have a X220 to do tests. Is anyone working on getting the uefi and zfs boot code
integrated ?
Comment 27 Dominik Zajac 2014-11-15 09:44:16 UTC
Some further ideas how to fix or workaround this BIOS/UEFI bug?
Comment 28 Allan Jude freebsd_committer 2014-11-15 16:35:43 UTC
I still need more people to test the patched ISO I created

Specifically what needs to be tested:

After a root-on-zfs installation on GPT, does a system that previously failed to boot in BIOS mode, now boot?
Comment 29 Joseph Mingrone freebsd_committer 2014-11-15 17:00:52 UTC
It's still not clear to me if the X220 is in this category.  Allan, you said at one point it was, but could you confirm since the patched iso didn't work.  Has anything changed since I lasted tested?
Comment 30 Marcus von Appen freebsd_committer freebsd_triage 2015-02-18 11:54:22 UTC
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
Comment 31 Glen Barber freebsd_committer 2015-07-07 15:47:44 UTC
Has a consensus been reached on the proper solution to this?
Comment 32 Allan Jude freebsd_committer 2015-07-07 16:05:35 UTC
Not that I am aware of.

I now have a pair of X220's with which to test fixes locally.

The real question is: is a fix that makes the lenovo's work "safe for everyone", or should we have a separate lenovo_pmbr file?
Comment 33 Colin Percival freebsd_committer 2015-07-07 18:31:40 UTC
Allan: This isn't just a lenovo problem btw -- I filed this PR because it affected my Dell E7440 laptop.
Comment 34 Ed Maste freebsd_committer 2015-07-07 18:38:30 UTC
The installer needs to provide the option of setting or clearing the active flag. For extra credit we could have a default table based on smbios.
Comment 35 Allan Jude freebsd_committer 2015-07-07 19:05:55 UTC
Just the active flag does not seem to do the trick
Comment 36 Joseph Mingrone freebsd_committer 2015-07-07 19:20:48 UTC
FWIW, I can boot a GPT-partitioned disk on an X220 now by 1) creating a fake slice in the PMBR and 2) setting it active.  I'm not sure if anything changed or if I was screwing something up in the past.
Comment 37 Marcel Moolenaar freebsd_committer 2015-07-07 19:26:34 UTC
Besides the behavior of the installation process, is there anything we need to change as part of the release cycle so that we create images that will boot on the machines in question?

Using sysctl or smbios to determine what to do only works for the installation process, not the release cycle.

Isn't it safer to have x86 images (created by the release process) use MBR and not GPT and leave GPT got the installation process?
Comment 38 Allan Jude freebsd_committer 2015-07-12 05:57:59 UTC
The installer images are usually BSD partitioned, so don't have an MBR at all. This works everywhere that I am aware of.

It is only the installed systems that have a problem.

This issue is slightly different that I originally thought.

An installer option to set the active flag now makes sense to me, and I will update the original patch from last October for inclusion.

Separately, I also have an automated fix for the Lenovo+GPT boot issue, please see: https://lists.freebsd.org/pipermail/freebsd-current/2015-July/056543.html
Comment 39 Allan Jude freebsd_committer 2015-07-15 05:44:03 UTC
A patch for this has been proposed: https://reviews.freebsd.org/D3091
Comment 40 Allan Jude freebsd_committer 2015-07-16 04:37:38 UTC
If you have hardware that requires the the PMBR be set to active (gpart set -a active <disk>), please provide the output of:

kenv | grep smbios

so I can add your hardware to the blacklist in the installer, so it will have the fix applied, without you having to manually ask for it.
Comment 41 Colin Percival freebsd_committer 2015-07-16 04:45:19 UTC
On my Dell E7440:

smbios.bios.reldate="02/18/2014"
smbios.bios.vendor="Dell Inc."
smbios.bios.version="A08"
smbios.chassis.maker="Dell Inc."
smbios.chassis.serial="3RS4XZ1"
smbios.memory.enabled="16777216"
smbios.planar.maker="Dell Inc."
smbios.planar.product="091TRH"
smbios.planar.serial="/3RS4XZ1/CN1296343M0159/"
smbios.planar.version="A00"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.maker="Dell Inc."
smbios.system.product="Latitude E7440"
smbios.system.serial="3RS4XZ1"
smbios.system.uuid="4c4c4544-0052-5310-8034-b3c04f585a31"
smbios.system.version="01"
smbios.version="2.7"

Thanks!
Comment 42 commit-hook freebsd_committer 2015-07-18 18:50:18 UTC
A commit references this bug:

Author: allanjude
Date: Sat Jul 18 18:49:48 UTC 2015
New revision: 285679
URL: https://svnweb.freebsd.org/changeset/base/285679

Log:
  Add support for two workarounds for known issues booting GPT in legacy mode on some hardware

  For Lenovo laptops with buggy bios (x220, t420, t520):
  	Write the 0xee entry into the second slot in the pmbr instead of the first

  For some Dell and HP models:
  	The BIOS gives a warning message when booting in legacy mode from a GPT partitioned disk where the 0xee partition in the pmbr is not flagged active
  	For models known to have this problem, mark the pmbr active during installation

  Use smbios data to identify machines known to be affected by any of the above, and offer the user the option to apply the workaround

  In bsdinstall's ufs auto mode (autopart partition wizard):
  	Allow users to select which type of partition table to use
  	Keep current defaults: MBR for BIOS, GPT for UEFI
  	This allows users to choose GPT for legacy boot if they wish

  PR:		184910
  PR:		194359
  Reviewed by:	Michael Dexter
  Approved by:	marcel
  MFC after:	3 days
  X-MFC-With:	r285594
  Relnotes:	yes
  Sponsored by:	ScaleEngine Inc.
  Differential Revision:	https://reviews.freebsd.org/D3091

Changes:
  head/usr.sbin/bsdinstall/partedit/gpart_ops.c
  head/usr.sbin/bsdinstall/partedit/part_wizard.c
  head/usr.sbin/bsdinstall/partedit/partedit.c
  head/usr.sbin/bsdinstall/partedit/partedit.h
  head/usr.sbin/bsdinstall/scripts/auto
  head/usr.sbin/bsdinstall/scripts/zfsboot
Comment 43 Allan Jude freebsd_committer 2015-07-18 21:59:37 UTC
I have produced a memstick image of 10.2-BETA2 with these patches applied. Please test it:

http://www.allanjude.com/bsd/FreeBSD-10.2-BETA2-amd64-20150718-r285678_bsdinstall-memstick.img.xz

SHA256 (FreeBSD-10.2-BETA2-amd64-20150718-r285678_bsdinstall-memstick.img.xz) = d277249b63eec68fa4b201372a8a2b853ae1f8a9734907d641e88bbd052dce9d
Comment 44 Kurt Jaeger freebsd_committer 2015-07-19 06:41:22 UTC
Testinstall on X220 with GPT, ZFS and encryption: works! Very nice!
Comment 45 Hans Ottevanger 2015-07-19 07:40:26 UTC
(In reply to Allan Jude from comment #40)

My Q6600 systems on an Intel DP965LT board, that requires

/sbin/gpart set -a active adaX

to get it to boot after installation:

smbios.bios.reldate="03/26/2009"
smbios.bios.vendor="Intel Corp."
smbios.bios.version="MQ96510J.86A.1761.2009.0326.0001"
smbios.chassis.maker="                                "
smbios.chassis.serial="                                "
smbios.chassis.tag="                                "
smbios.chassis.version="                        "
smbios.memory.enabled="8388608"
smbios.planar.maker="Intel Corporation"
smbios.planar.product="DP965LT"
smbios.planar.serial="AZLT72000084"
smbios.planar.version="AAD41694-210"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.maker="                                "
smbios.system.product="                                "
smbios.system.serial="                                "
smbios.system.uuid="8235a276-ffd9-11db-82cd-0011113186f6"
smbios.system.version="                        "
smbios.version="2.4"
Comment 46 Sean Bruno freebsd_committer 2015-07-20 23:16:44 UTC
Dell E7240 requires gpart set -a active ada0:

smbios.bios.reldate="05/19/2015"
smbios.bios.vendor="Dell Inc."
smbios.bios.version="A15"
smbios.chassis.maker="Dell Inc."
smbios.chassis.serial="BVBPF12"
smbios.memory.enabled="8388608"
smbios.planar.maker="Dell Inc."
smbios.planar.product="05PTPV"
smbios.planar.serial="/BVBPF12/CN1296346B03CA/"
smbios.planar.version="A00"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.maker="Dell Inc."
smbios.system.product="Latitude E7240"
smbios.system.serial="BVBPF12"
smbios.system.uuid="4c4c4544-0056-4210-8050-c2c04f463132"
smbios.system.version="01"
smbios.version="2.7"
Comment 47 commit-hook freebsd_committer 2015-07-21 00:34:09 UTC
A commit references this bug:

Author: allanjude
Date: Tue Jul 21 00:33:16 UTC 2015
New revision: 285732
URL: https://svnweb.freebsd.org/changeset/base/285732

Log:
  Add the Dell E7240 laptop and Intel DP965LT motherboard to the list for the GPT active workaround

  PR:		194359
  Requested by:	sbruno, hiren
  Approved by:	marcel
  MFC after:	3 days
  Relnotes:	yes
  Sponsored by:	ScaleEngine Inc.
  Differential Revision:	https://reviews.freebsd.org/D3139

Changes:
  head/usr.sbin/bsdinstall/scripts/auto
Comment 48 Juan Ramón Molina Menor 2015-07-21 10:16:01 UTC
Acer Veriton M6630G requires active flag with CSM boot:

smbios.bios.reldate="08/25/2014"
smbios.bios.vendor="Acer                    "
smbios.bios.version="P21-B4                 "
smbios.chassis.maker="Acer"
smbios.chassis.version="        "
smbios.memory.enabled="8388608"
smbios.planar.maker="Acer"
smbios.planar.product="Veriton M6630G"
smbios.planar.version="V:1.0   "
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.maker="Acer"
smbios.system.product="Veriton M6630G"
smbios.system.version="        "
smbios.version="2.7"
Comment 49 commit-hook freebsd_committer 2015-07-21 21:12:59 UTC
A commit references this bug:

Author: allanjude
Date: Tue Jul 21 21:12:31 UTC 2015
New revision: 285769
URL: https://svnweb.freebsd.org/changeset/base/285769

Log:
  MFC: r285679
  	Add auto-detecting workaround for Lenovo GPT boot issue
  	Add auto-detecting workaround for "GPT Active" boot issue
  	Allow user to select partitioning scheme in the ufs wizard

  PR:		184910
  PR:		194359
  Approved by:	re (gjb), marcel
  Relnotes:	yes
  Sponsored by:	ScaleEngine Inc.
  Differential Revision:	https://reviews.freebsd.org/D3144

Changes:
_U  stable/10/
  stable/10/usr.sbin/bsdinstall/partedit/gpart_ops.c
  stable/10/usr.sbin/bsdinstall/partedit/part_wizard.c
  stable/10/usr.sbin/bsdinstall/partedit/partedit.c
  stable/10/usr.sbin/bsdinstall/partedit/partedit.h
  stable/10/usr.sbin/bsdinstall/scripts/auto
  stable/10/usr.sbin/bsdinstall/scripts/zfsboot
Comment 50 Kurt Lidl freebsd_committer 2015-07-22 23:25:52 UTC
While not a laptop, I have an Atom based motherboard that won't
boot from a gpt labeled disk unless it is marked active:

smbios.bios.reldate="08/02/2010"
smbios.bios.vendor="Intel Corp."
smbios.bios.version="MOPNV10J.86A.0311.2010.0802.2346"
smbios.chassis.maker="                                "
smbios.chassis.serial="                                "
smbios.chassis.tag="                                "
smbios.chassis.version="                        "
smbios.memory.enabled="4194304"
smbios.planar.maker="Intel Corporation"
smbios.planar.product="D510MO"
smbios.planar.serial="BTMO02500B7Q"
smbios.planar.version="AAE76523-403"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.maker="                                "
smbios.system.product="                                "
smbios.system.serial="                                "
smbios.system.uuid="505f63c0-79fc-11df-bbce-000ea60cdec2"
smbios.system.version="                        "
smbios.version="2.5"
Comment 51 Hans Ottevanger 2015-08-04 18:04:24 UTC
(In reply to Hans Ottevanger from comment #45)

Just FYI:

My INTEL DP965LT systems still require "gpart set -a active ada0" to get the installation to reboot after installing FreeBSD 10.2-RC2.

When I bluntly copy the bsdinstall/auto script from -CURRENT to the 10.2-RC2 memstick image the UFS based installation still works perfectly and nicely asks before setting the partition active. The system reboots without problems.
Comment 52 Marcel Moolenaar freebsd_committer 2015-08-28 03:17:46 UTC
Allan: Is this issue resolved or are there still things to do?
Comment 53 Colin Percival freebsd_committer 2015-08-28 03:22:37 UTC
I can't speak for anyone else, but since I opened this bug... 10.2 works perfectly for me.  Warning message pops up during installation, I say "ok", and the necessary magic happens.
Comment 54 Allan Jude freebsd_committer 2015-08-28 03:46:17 UTC
(In reply to Marcel Moolenaar from comment #52)

There are a few additional models of machine that have been identified that I need to add to the blacklist. I'll do that this weekend and get this bug closed.
Comment 55 commit-hook freebsd_committer 2015-09-16 03:32:52 UTC
A commit references this bug:

Author: allanjude
Date: Wed Sep 16 03:32:28 UTC 2015
New revision: 287843
URL: https://svnweb.freebsd.org/changeset/base/287843

Log:
  Add a number of models to the bsdinstall GPT hack blacklist

  PR:		194359
  Approved by:	bapt (mentor)
  MFC after:	2 weeks
  Sponsored by:	ScaleEngine Inc.
  Differential Revision:	https://reviews.freebsd.org/D3525

Changes:
  head/usr.sbin/bsdinstall/scripts/auto
Comment 56 Eric van Gyzen freebsd_committer 2016-01-23 21:10:43 UTC
Allan:  I would like to merge r293860 to stable/10, but it looks like the prerequisite r285732 is not yet merged.  Do you plan to merge it before the 10.3 freeze?  Thanks.
Comment 57 Allan Jude freebsd_committer 2016-01-23 22:16:17 UTC
(In reply to Eric van Gyzen from comment #56)
My two outstanding revisions have been MFCed
Comment 58 Mārcis Lielturks 2016-01-29 22:42:37 UTC
Apparently Intel DP35DP can't boot from GPT in legacy mode too. Yesterday I tested that setting the active flag makes it boot. However I switched away from this system and I'm writing here just for the record.

In case You want to add this system to the workaround list, here's smbios information.

Thanks!

smbios.bios.reldate="07/15/2009"
smbios.bios.vendor="Intel Corp."
smbios.bios.version="DPP3510J.86A.0572.2009.0715.2346"
smbios.chassis.maker="                                "
smbios.chassis.serial="                                "
smbios.chassis.tag="                                "
smbios.chassis.version="                        "
smbios.memory.enabled="4194304"
smbios.planar.maker="Intel Corporation"
smbios.planar.product="DP35DP"
smbios.planar.serial="USDP7440024S"
smbios.planar.version="AAD81073-207"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.maker="                                "
smbios.system.product="                                "
smbios.system.serial="                                "
smbios.system.uuid="f86b9e90-8a0e-11dc-adf6-0013d4d9c938"
smbios.system.version="                        "
smbios.version="2.4"
Comment 59 Joseph Mingrone freebsd_committer 2017-08-02 13:38:43 UTC
Closing as fixed based on feedback from allanjude and cperciva.