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.

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.

Is your grub compiled with libdevmapper support

Do not use losetup with offset. Use kpartx instead

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?