[bug #63127] failure to correctly read BPB block in GPT/UEFI setting

[Milan Durovic]

URL:
  <https://savannah.gnu.org/bugs/?63127>

                 Summary: failure to correctly read BPB block in GPT/UEFI
setting
                 Project: GNU GRUB
               Submitter: milan_789
               Submitted: Thu 29 Sep 2022 02:34:28 AM UTC
                Category: Disk &amp; Partition
                Severity: Major
                Priority: 5 - Normal
              Item Group: Software Error
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Milan Durovic
        Originator Email: milan.durovic@aristocrat.com
             Open/Closed: Open
                 Release: other
                 Release: 
         Discussion Lock: Any
         Reproducibility: Every Time
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Thu 29 Sep 2022 02:34:28 AM UTC By: Milan Durovic <milan_789>
I'm trying to create a bootable disk image with GPT partitioning and UEFI
firmware support.

So, I'm using OpenSUSE as a development environment, but firmware running via
QEMU.
I've built GRUB (version 2.6) using the following options:

./configure \
            --disable-efiemu     \
            --enable-grub-mkfont \
            --with-platform=efi  \
            --target=x86_64  \
            --disable-werror
make

Next, I created an image of a GPT formatted drive like this:

dd if=/dev/zero of=./uefi.img bs=512 count=93750
sudo /usr/sbin/gdisk ./uefi.img <<EOF
o
y
n
1
2048
93716
ef00
w
y
EOF
# Create a block device over the image file
sudo /usr/sbin/losetup -b 512 --offset 1048576 --sizelimit 46934528 /dev/loop0
./uefi.img
# Create the FAT32 filesystem 
sudo /sbin/mkfs.fat -F 32 /dev/loop0

So now, I should have GPT partitioned drive, where the partition is of EF00
type (EFI system
partition), formatted as FAT32. I confirmed this when I mount /dev/loop0
easily.

Next, I tried to install GRUB 2 using the following:

sudo /bin/mount /dev/loop0 /mnt
sudo /usr/local/sbin/grub-install --bootloader-id=GRUB --disable-shim-lock
--efi-directory=/mnt --target=x86_64-efi --no-nvram \
        --boot-directory=/mnt --debug-image=all /dev/loop0

This installs GRUB binary into /EFI/GRUB/grubx64.efi and grub modules into
/grub directory on the EFI system partition - so far,
all as expected. AND NOW THE PROBLEM PART. I got extra information by adding
more error messages to work out what was happening,
but THE BOTTOM LINE IS THIS:

in the file grub-core/fs/fat.c, in the function grub_fat_mount, when the
function tries to read BPB, it gets all information
as zeros (I added a grub_printf, and rebuilt, so I know), like
bpb.bytes_per_sector, bpb.sectors_per_cluster, bpb.num_fats, etc. Just at the
start of the grub_fat_mount, I also printed the values
for disk->name and disk->log_sector_size and these came out as (hd0) and 9,
the second one clearly correct.

Now, I double checked BPB content on the FAT32 partition inside the image and
it's all good. After all, I could easily mount
the filesystem and it showed the correct content both then and when I ran EFI
shell.

So, what appears to me to be the problem is that it's trying to read BPB from
(hd0), instead of (hd0,gpt1), I think. I tried
tracing the calls upstream, but the only device that was ever given to GRUB
was (hd0). It looks like (hd0), as a device, is
the whole image, so GRUB erroneously reads the first sector of the drive,
rather than at 1MiB offset, where FAT32 filesystem
starts. And this may be because the device passed on is wrong. 

I traced it all the way up to kern/main.c and the function
grub_machine_get_bootlocation reports device and path as
hd0 and /efi/GRUB, respectively.

I don't know if maybe I'm running grub-install incorrectly, but even within
the code, disk parameters appear to have been
read correctly, but BPB, which is read from where FAT32 partition is, is
incorrect (all zeros).

Any ideas what may be wrong here?







    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63127>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/