NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

bin/51230: 'gpt biosboot' needs to mark protective mbr partition as 'active'

>Number:         51230
>Category:       bin
>Synopsis:       'gpt biosboot' needs to mark protective mbr partition as 'active'
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 09 12:25:00 +0000 2016
>Originator:     Hauke Fath
>Release:        NetBSD 7.0_STABLE
Technische Universitaet Darmstadt
System: NetBSD Gstoder 7.0_STABLE NetBSD 7.0_STABLE (MONOLITHIC) #1: Fri Apr 1 14:41:59 CEST 2016 hf@Hochstuhl:/var/obj/netbsd-builds/7/i386/sys/arch/i386/compile/MONOLITHIC i386
Architecture: i386
Machine: i386

	Because of disklabel's size limitations, NetBSD on inteloid
	hardware is migrating to the gpt partition format. Although
	gpt is also used by UEFI, we don't support that, and require
	machines to use the legacy mbr format. Our gpt-enabled mbr
	will then know how to use the gpt partition table.

	When gpt(8) creates a gpt table on a disk, it also writes a
	protective mbr partition table, to keep legacy tools from
	showing an empty disk.

	When 'gpt biosboot' prepares a bootable disk, it will install
	its custom mbr to block 0, and mark the indicated disk slice
	as bootable, but it will not update the protective mbr table.

	Some manufacturers
	(<>. as
	well as the HP Elitebook 2170p here) require all Ts crossed
	and Is dotted before recognizing a legacy mbr as
	bootable. They will especially not execute the mbr code unless
	the mbr table has a partition marked 'active', and present you
	with a terse "Boot Device Not Found" error.

	'gpt biosboot' should mark the protective mbr's partition
	'active', and does not.


	Get a newish laptop from HP, switch it to legacy boot,
	partition the disk with gpt(8), and install NetBSD. You will
	find the lapop boots with the disk on an external USB adapter,
	but not as an internal disk.


	Teach 'gpt biosboot' to set the 'active' flag on the
	protective mbr table's (sole) partition.

	Possible workarounds:

	(a) punt, and disklabel(8) the disk

	(b) 'gpt create <drive>', then 'fdisk -0 -a <drive>', then
	'gpt create <drive>' again, bedause the fdisk run will have
	stomped on the gpt. Interesting enough, the second 'gpt
	create' will leave the protective mbr intact. Then partition
	and make bootable with gpt(8), and install.

	(c) running 'fdisk -0 -a <drive>' against the protective mbr
	of an existing partition will trash the gpt. I tried this, and
	'gpt recover' did not find a backup gpt (that's a bug in its
	own right) - luckily I could re-create start and end of my
	installation's one partition from memory. The installation was
	bootable from internal disk afterwards.


Home | Main Index | Thread Index | Old Index