Bug 184910 - bootcode not installed correctly by bsdinstall(8)
Summary: bootcode not installed correctly by bsdinstall(8)
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Allan Jude
Depends on:
Reported: 2013-12-16 19:50 UTC by Max Parmer
Modified: 2015-07-21 21:14 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Max Parmer 2013-12-16 19:50:00 UTC
Following a simple UFS autopartitioned install from `bsdinstall` on a Lenovo x220 (w/latest BIOS image available from Lenovo) the bootcode does not appear to be installed. I.e. the system reacts as if there is no bootable OS on the boot drive.

I experimented with GPT partitioning and also made some attempts to get bootcodes working for ZFS (with both but MBR and GPT schemes) and never quite sorted out what to bootcode to install where to render the install bootable.

It is my understanding the x220s (and some other Lenovo laptops) have some known idiosyncratic boot behavior, but it also seems as if bsdinstall has been skipping the branch wherein it installs bootcodes on this system.

In all experiments I used the memstick USB image

I have not experienced this issue with virtualized systems


To remedy this I have exited to a shell following the installer, and have manually run:

gpart bootcode -b /boot/mbr /dev/ada0
gpart bootcode -b /boot/boot /dev/ada0s1
How-To-Repeat: Install with any autopartitioned option in `bsdinstall` on a Lenovo x220 (regardless of legacy boot vs. EFI boot BIOS setting) with either a current or vintage BIOS installed.
Comment 1 Joseph Mingrone freebsd_committer 2013-12-31 13:49:20 UTC
I can confirm there is still a problem with 10RC3.

The X220 has a quirk/feature/bug in that it refuses to boot from a GPT
partitioned disk if you select "legacy boot" in the BIOS.  This
apparently is a problem for GNU/Linux users as well. So, we're stuck
with MBR partition schemes until UEFI booting is supported.

Here is the bsdinstall_log from an attempt to install MBR/ZFS/GELI:

Like Max, I'm told there is no OS installed after rebooting.

After bsdinstall finishes if I try to manually add the boot code with

# gpart bootcode -b /boot/mbr ada0
# gpart set -a active -i 1 ada0
# dd if=/boot/zfsboot of=/dev/ada1s1 count=1
# dd if=/boot/zfsboot of=/dev/ada1s1a skip=1 seek=1024

the two dd commands return operation not permitted errors even
when setting kern.geom.debugflags=0x10.  Now after I reboot I see an
error about not having ufs filesystems.

If there is anything else I can test, just let me know.

Comment 2 Allan Jude freebsd_committer 2015-07-12 19:46:39 UTC
This is not a bug with bsdinstall, but with the lenovo bios.

Can you please try this fixed image:

Just write it to a USB stick and try to boot from it
Comment 3 commit-hook freebsd_committer 2015-07-15 02:24:06 UTC
A commit references this bug:

Author: allanjude
Date: Wed Jul 15 02:23:56 UTC 2015
New revision: 285594
URL: https://svnweb.freebsd.org/changeset/base/285594

  Add a new option to gpart(8) to fix Lenovo BIOS boot issue

  PR:		184910
  Reviewed by:	ae, wblock
  Approved by:	marcel
  MFC after:	3 days
  Relnotes:	yes
  Sponsored by:	ScaleEngine Inc.
  Differential Revision:	https://reviews.freebsd.org/D3065

Comment 4 commit-hook freebsd_committer 2015-07-18 18:50:16 UTC
A commit references this bug:

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

  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

Comment 5 Allan Jude freebsd_committer 2015-07-18 22:00:06 UTC
I have produced a memstick image of 10.2-BETA2 with these patches applied. Please test it:


SHA256 (FreeBSD-10.2-BETA2-amd64-20150718-r285678_bsdinstall-memstick.img.xz) = d277249b63eec68fa4b201372a8a2b853ae1f8a9734907d641e88bbd052dce9d
Comment 6 commit-hook freebsd_committer 2015-07-21 15:50:47 UTC
A commit references this bug:

Author: allanjude
Date: Tue Jul 21 15:50:16 UTC 2015
New revision: 285756
URL: https://svnweb.freebsd.org/changeset/base/285756

  MFC: r285594
  	New partition flag for gpart, writes the 0xee partition in the pmbr in the second slot, rather than the first.
  	Works around Lenovo legacy GPT boot issue

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

_U  stable/10/
Comment 7 commit-hook freebsd_committer 2015-07-21 21:12:58 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

  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

_U  stable/10/
Comment 8 Allan Jude freebsd_committer 2015-07-21 21:14:33 UTC
This issue is now solved in FreeBSD 11.0-CURRENT and the fix will be included in the next stable/10 snapshot (10.2-BETA3 or 10.2-RC1)