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 & Partition
Severity: Major
Priority: 5 - Normal
Item Group: Software Error
Status: None
Privacy: Public
Assigned to: None
Originator Name: Milan Durovic
Originator Email: milan.duro...@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/
