[Bug 271794] boot1.efi hangs on a system with gjournaled partitions

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 02 Jun 2023 22:54:13 UTC

            Bug ID: 271794
           Summary: boot1.efi hangs on a system with gjournaled partitions
           Product: Base System
           Version: Unspecified
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: misc
          Assignee: bugs@FreeBSD.org
          Reporter: longwitz@incore.de

My ThinkPad L560 running FreeBSD 12.3-STABLE r371380 did not boot abruptly.
The output of boot1.efi was:

>> FreeBSD EFI boot block
   Loader path: /boot/loader.efi

   Initializing modules: ZFS UFS
   Load Path: \EFI\BOOT\BOOTX64.EFI
   Load Device:
   BootCurrent: 001a
   BootOrder: 0001 0010 0011 0012 0013 001b 0017 0018 0019 001a[*] 001c
   Probing 11 block devices...not supported
not supported
not supported
not supported
not supported
not supported
   ZFS found no pools
   UFS found 5 partitions

Nothing more, laptop hangs. I could not boot from disk anymore.
I use gmirror/gjournal, and gpart show gives

=>       40  500118112  mirror/gmnbsd  GPT  (238G)
         40     819200              1  efi  (400M)
     819240   16777216              2  freebsd-swap  (8.0G)
   17596456   16777216              3  freebsd-swap  (8.0G)
   34373672   16777216              4  freebsd-swap  (8.0G)
   51150888   16777216              5  freebsd-swap  (8.0G)
   67928104   16777216              6  freebsd-swap  (8.0G)
   84705320    4194304              7  freebsd-ufs  (2.0G)
   88899624   25165824              8  freebsd-ufs  (12G)
  114065448   67108864              9  freebsd-ufs  (32G)
  181174312  318943840             10  freebsd-ufs  (152G)

Partitions p3-p6 are the gjournals for the ufs partitions p7-p10.
The first "better" in the output of boot1.efi shows the problem:
boot1 mistankenly thinks the gjournal partition p5 is an ufs partition
and therfore tries to start loader.efi from this partition.

boot1 fails because the check for ufs is done with a simple compare to
FS_UFS_MAGIC and in a gjournal partition this data can be found. Of cource
this is a rarely event, but I had a hit. It would be much safer when
boot1.efi does a check for the partition type freebsd-ufs in the GPT, so
done in gptboot.

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