bugGNU GRUB - Bugs: bug #63127, failure to correctly read BPB...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitter:  Milan Durovic <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
Open/Closed:  Open Release:  other
Release:  Reproducibility:  Every Time
Planned Release:  None

Jump to the original submission

Tue 04 Oct 2022 04:36:16 AM UTC, comment #8: 

correction: partprobe not partproble below :-)
comment #7:

> Ok, got it working! Mind you, I still don't understand which low level detail was the stumbling block, or why it didn't work originally. The key help came from this article:
>
> https://blog.heckel.io/2017/05/28/creating-a-bios-gpt-and-uefi-gpt-grub-bootable-linux-system/
>
> the part that describes how to install on EFI systems. The key difference is that after the creation of FAT32 filesystem as EFI system partition, I detached the loop device and then reattached it using the following:
>
> LOOPDEV=$(sudo /usr/sbin/losetup --find --show ./uefi.img)
> sudo /usr/sbin/partproble $LOOPDEV
> sudo /bin/mount ${LOOPDEV}p1 /mnt
>
> Now, when I copied files and ran grub-install (I ended up using grub-mkstandalone, but still the same) GRUB started normally and I finally ended up in the GRUB shell.

Milan Durovic <milan_789>
Tue 04 Oct 2022 04:34:47 AM UTC, comment #7: 

Ok, got it working! Mind you, I still don't understand which low level detail was the stumbling block, or why it didn't work originally. The key help came from this article:

https://blog.heckel.io/2017/05/28/creating-a-bios-gpt-and-uefi-gpt-grub-bootable-linux-system/

the part that describes how to install on EFI systems. The key difference is that after the creation of FAT32 filesystem as EFI system partition, I detached the loop device and then reattached it using the following:

LOOPDEV=$(sudo /usr/sbin/losetup --find --show ./uefi.img)
sudo /usr/sbin/partproble $LOOPDEV
sudo /bin/mount ${LOOPDEV}p1 /mnt

Now, when I copied files and ran grub-install (I ended up using grub-mkstandalone, but still the same) GRUB started normally and I finally ended up in the GRUB shell.

Milan Durovic <milan_789>
Mon 03 Oct 2022 10:46:01 PM UTC, comment #6: 

I came across this article:
https://superuser.com/questions/130955/how-to-install-grub-into-an-img-file

and interestingly, the author, instead of mounting loop0p1, uses losetup over loop0p1 like:

losetup /dev/loop1 /dev/mapper/loop0p1

in order to overcome grub-install confusion with device mapper devices. So, I followed the steps and this time I didn't get grub-install to complain about "volume group" - it completed successfully. Unfortunately, I still get the original problem, ie. when GRUB tries to read BPB parameters, it does that from the wrong location.

I tried adding the device.map as suggested in the quoted article, but it obviously had no effect. I'm not sure it's even used in EFI/GPT situation?
comment #5:

>
> comment #4:
> > Is your grub compiled with libdevmapper support
>
> I didn't specify it explicitly. Now I added --enable-device-mapper option when running configure script, rebuilt grub, reinstalled it, and tried everything again. Still the same outcome, same messages. I did everything twice from scratch, just in case I overlooked something or made a mistake, but the result and messages were identical.

Milan Durovic <milan_789>
Thu 29 Sep 2022 09:23:46 PM UTC, comment #5: 


comment #4:

> Is your grub compiled with libdevmapper support


I didn't specify it explicitly. Now I added --enable-device-mapper option when running configure script, rebuilt grub, reinstalled it, and tried everything again. Still the same outcome, same messages. I did everything twice from scratch, just in case I overlooked something or made a mistake, but the result and messages were identical.

Milan Durovic <milan_789>
Thu 29 Sep 2022 12:23:23 PM UTC, comment #4: 

Is your grub compiled with libdevmapper support

Vladimir Serbinenko <phcoder>
Group administrator
Thu 29 Sep 2022 07:01:59 AM UTC, comment #3: 


comment #2:

> Do not use losetup with offset. Use kpartx instead


I've just tried, but it seems there's still some kind of a problem that grub-install is not happy with. Here's the session log:

mk7@linux-xmpl:~/development/milan/uefi> sudo /usr/sbin/kpartx -avg ./uefi.img
add map loop0p1 (254:0): 0 91669 linear 7:0 2048
mk7@linux-xmpl:~/development/milan/uefi> sudo /sbin/mkfs.fat -F 32 /dev/mapper/loop0p1
mkfs.fat 4.2 (2021-01-31)
mk7@linux-xmpl:~/development/milan/uefi> sudo mount /dev/mapper/loop0p1 /mnt
mk7@linux-xmpl:~/development/milan/uefi> 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/mapper/loop0p1
Installing for x86_64-efi platform.
Found EFI device: /dev/mapper/loop0p1
  Volume group "loop0p1" not found
  Cannot process volume group loop0p1
  Volume group "loop0p1" not found
  Cannot process volume group loop0p1
/usr/local/sbin/grub-install: error: disk `lvm/loop0p1' not found.
mk7@linux-xmpl:~/development/milan/uefi>

Milan Durovic <milan_789>
Thu 29 Sep 2022 06:32:13 AM UTC, comment #2: 

Do not use losetup with offset. Use kpartx instead

Vladimir Serbinenko <phcoder>
Group administrator
Thu 29 Sep 2022 06:18:58 AM UTC, comment #1: 

... just to add on the previous report: I'm launching GRUB from EFI shell by providing the path EFI\GRUB\grubx64.efi. It tries to mount the ESP, but then goes into "grub rescue>" prompt.

I also added diag messages to grub-core/disk/efi/efidisk.c, the function make_devices. It reported that it found 3 handles, and I printed ldp->type, ldp->subtype, ldp->length towards the end of the function, and got these value sets:

3, 1, 8
3, 1, 8
4, 1, 42

I have no idea what these numbers mean, but if it helped, I thought it may be a good idea to share them.

Milan Durovic <milan_789>
Thu 29 Sep 2022 02:34:28 AM UTC, original submission:  

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?

Milan Durovic <milan_789>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by milan_789 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code