proper way to boot from a GPT drive with BIOS instead of uEFI ?

nacho Lariguet lariguet at gmail.com
Tue Sep 8 18:51:44 PDT 2020


Why ? I have a machine that right now panics booting on uEFI but not on BIOS, so I wish to install in a manner to avoid reinstalling everything when the uEFI boot sequence eventually gets fixed. 

I am already (and successfully) manually installing and booting on uEFI/GPT with the following layout:

set strDrive = '/dev/serno/whatever';
set strDriveSlice0 = "${strDrive}.s0"; ### intended to hold the ESP slice
set strDriveSlice1 = "${strDrive}.s1"; ### intended to hold the BSD slice

/bin/dd if='/dev/zero' of="${strDrive}" bs='32K' count='16'; ### cleaning-up partition data (if any)

/sbin/gpt destroy   "${strDrive}";
/sbin/gpt create -f "${strDrive}"; ### even destroying the MBR (if any) in order to create the GPT structure

/sbin/gpt add -i '0' -s '262144' -t  'efi' "${strDrive}"; ### ie: x#s0 for GPT EFI system slice @ 256 MB
/sbin/gpt add -i '1'             -t 'dfly' "${strDrive}"; ### ie: x#s1 for GPT BSD system slice filling the remaining drive space

/sbin/gpt label -i '0' -l 'sliceGPTasESP' "${strDrive}";
/sbin/gpt label -i '1' -l 'sliceGPTasBSD' "${strDrive}";

/bin/dd if='/dev/zero' of="${strDriveSlice0}" bs='32K' count='16'; ### cleaning-up partition data (if any)
/bin/dd if='/dev/zero' of="${strDriveSlice1}" bs='32K' count='16'; ### cleaning-up partition data (if any)

Thereafter I properly format both slices (0 and 1) as usual, manually install the OS, and so far so good: it works as expected booting with uEFI :)

Now, if I understood correctly the concepts, to boot a BIOS/GPT combo, requires:

- MBR on sector 0 (1 sector = 512 bytes) holding the boot0 code (GPT partition data starts on sector 1) (the MBR is useless for uEFI)
- boot0 on MBR configured to jump to boot1 on /dev/*s1b (the standard UFS boot partition for BSD on slice#1) (skipping the EFI partition on slice#0 which is useless for BIOS)

OK, here we go:

When executing: gpt show "${strDrive}"; ... it shows sector 0 as PMBR (nothing modified so far).
Then I assumed (for whatever reasons) boot0 is already on sector # 0.
When executing: boot0cfg "${strDrive}"; ... it show no compatible boot code found (or something like this).
So it seems there is no boot0 on the MBR after all.

How can I place boot0 on the MBR ?

The man page for boot0cfg says with: boot0cfg -B[v] /dev/whatever/ ### Install the boot0 boot manager. This option causes MBR code to be replaced, WITHOUT affecting the embedded slice table. (The default is /boot/boot0). It also states that the -s # switch should be used to point to the target slice which we want to boot (the one holding boot1 I guess) so boot0cfg -B -s 1 should do it right ?

Summarizing:

- MBR holds boot0 ... somehow should point to slice#1's boot UFS partition
- slice#1 is for the usual BSD partition being /boot/ the first one (holding /boot/boot1 and /boot/boot2)

It didn't work: rebooting on BIOS states something like nothing found to boot.

So I rebooted on uEFI and executed: boot0cfg -m 0x1 to temporarily disable the ESP slice (by way of just leaving the BSD slice enabled).

Rebooting on BIOS didn't work also.

So I rebooted on uEFI and attempted to clean my modifications with: dd if=/dev/zero/ of=/dev/whatever count=1; ### to clean the first sector; ie: 512 bytes exactly. Now gpt show /dev/whatever shows the first sector as "unused" instead of "PMBR". I supposed it didn't matter since the lacking of a MBR/PMBR while booting on uEFI should not affect anything. I were wrong. I can't boot on uEFI from now on. Should have backed-up the first 512 bytes before doing any modifications, my fault. I can't find anything on the handbook and/or the man pages to restore the PMBR. The gpt command does not seem to have anything related. The PMBR first appeared on my setup after running gpt destroy and then gpt create to begin with. Before that it was just a MBR.

On the other hand the man page for fdisk says with: fdisk -B /dev/whatever/ which did not solved anything at this point.

What am I doing wrong ?

boot0 is tiny code, very tiny, and boot1 which is the one which I am trying to chain is on UFS.
On second thought I guess there is no way 512-bytes of code could understand a UFS partition, period.
So I guess I should add a small third slice, containing some boot code, which actually points to slice#1's UFS boot partition.
When booting on uEFI slice#0 and slice#1 will be used.
When booting on BIOS slice#3 and slice#1 will be used.
When finally migrating to a fully-working uEFI machine I should delete slice#3, clear the MBR, and be done with it.

Am I on the right direction ?


More information about the Users mailing list