[Bug 235206] Starting with a damaged GPT scheme under legacy BIOS

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Jan 25 21:37:39 UTC 2019


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235206

            Bug ID: 235206
           Summary: Starting with a damaged GPT scheme under legacy BIOS
           Product: Base System
           Version: 12.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: misc
          Assignee: bugs at FreeBSD.org
          Reporter: kmachine at free.fr

Created attachment 201403
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201403&action=edit
Patch to add an automatic GPT recovery feature to gptboot

pmbr is the protective MBR program used by the FreeBSD GPT implementation. It
allows to boot a GPT system disk under legacy BIOS. Its main task is to find a
"freebsd-boot" partiton, load its content and execute it. This content,
depending on the type of root file system, is either gptboot (UFS) or
gptzfsboot (ZFS).

pmbr has a nice feature: it can boot a disk even if its primary GPT header is
damaged, provided the backup header is healthy. To be clear, it only checks the
tag "EFI PART" at the beginning of the header. It does not verify the crc32 of
the header nor the one of the partition table.

The problem is that nor gptboot nor gptzfsboot handles correctly a damaged
primary header and, as a result, the boot process dies after pmbr.

To reproduce this issue (warning! This is destructive, don't do that unless you
don't care of the system you operate on):
    - Boot on a disc1.iso or a memstick image.
    - In the shell, identify the target disc.
    - For example, if the target disk is ada0, type: dd if=/dev/zero
of=/dev/ada0 seek=1 count=1 
    - Reboot (you need to start in legacy BIOS mode).

If the root file system is ZFS, you'll see something like this:
---------------
shortening read at 20971505 from 16 to 15
gptzfsboot: No ZFS pools located, can't boot
---------------

Or:
---------------
gptzfsboot: error 12 lba 20971505
gptzfsboot: No ZFS pools located, can't boot
---------------

This example is on a VM with a 10 GiB disk. It seems that the first error
occurs when the disk is "fixed" and the last if the disk is "dynamic".

If the root file system is UFS, you will get:
---------------
gptboot: invalid primary GPT header
gptboot: using backup GPT

BTX loader 1.00 BTX version is 1.02
Consoles: internal video/keyboard
BIOS drive C: is disk0
BIOS 639kB/3668928kB available memory

FreeBSD/x86 bootstrap loader, Revision 1.1
Startup error in /boot/lua/loader.lua:
LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory

can't load 'kernel'

OK _
---------------

I managed to bring a solution for gptboot. I thought that the base problem is
it does not mend the GPT scheme, despite it is aware of its corruption. It
could, though. This the reason why I wrote a patch for
/usr/src/stand/libsa/gpt.c. After applying this patch, gptboot recovers
automatically the GPT scheme in the scenario where the primary header/table are
damaged and the backup header/table are valid.

In such a case, with the patched gptboot you get:

gptboot: invalid primary GPT header
gptboot: trying to recover GPT...
gptboot: GPT recovering -> SUCCESS

And then, the boot process continue.

I have to look for a gptzfsboot solution but I feel it's more complex. It
doesn't use gpt.c apparently so I have to search deeper for this one.

PS : this is more or less the first time I propose a patch so be indulgent with
me as I don't know many things in FreeBSD programming. I tried to do my best.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list