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.
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
Very easy, once you know how: gpart set -a active <disk name>
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...
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?
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?
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.
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
@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.
> 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.
(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.
(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.
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?
(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.
lstewart described the problem he encountered here: https://lists.freebsd.org/pipermail/freebsd-fs/2012-August/014864.html
reclassify.
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)
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.
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'
Created attachment 148553 [details] Fix syntax error in previous patch Updated patch
(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.
(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?
(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.
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.
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.
Sry. Forgot the link to the manuall fix/workaround: http://lists.freebsd.org/pipermail/freebsd-i386/2013-March/010437.html
(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 ?
Some further ideas how to fix or workaround this BIOS/UEFI bug?
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?
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?
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
Has a consensus been reached on the proper solution to this?
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?
Allan: This isn't just a lenovo problem btw -- I filed this PR because it affected my Dell E7440 laptop.
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.
Just the active flag does not seem to do the trick
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.
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?
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
A patch for this has been proposed: https://reviews.freebsd.org/D3091
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.
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!
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
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
Testinstall on X220 with GPT, ZFS and encryption: works! Very nice!
(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"
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"
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
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"
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
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"
(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.
Allan: Is this issue resolved or are there still things to do?
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.
(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.
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
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.
(In reply to Eric van Gyzen from comment #56) My two outstanding revisions have been MFCed
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"
Closing as fixed based on feedback from allanjude and cperciva.