sanboot GPT iscsi target (UEFI part. + NTFS part.) and grub4dos UEFI

[matteoguglielmi]

I am trying to sanboot a GPT iscsi target that has one EFI partition and one NTFS partition.

The ISCSI target was partitioned and formatted with Windows's diskpart tool.

grub4dos UEFI was installed into the EFI partition to map into memory a VHD Windows11 image.

Everything works when this is done on a real hard drive (d'oh), but when ipxe sanboots the iscsi target, grub4dos UEFI does not see the second partition and, therefore, can't load the large VHD into memory.

How is the GPT iscsi target presented to grub4dos UEFI by sanboot?

Is this a problem of sanboot, grub4dos or am I missing something basic here?

Thank you.

[NiKiZe]

When you say "does not see the second partition" what exactly do you see? And how have you booted this?

sanboot should expose the disk as EFI block device, it is up to firmware to deal with partitions and filesystems, sanboot can provide a filename of efi binary to boot.

Also remember that once a real kernel takes over, it will need to do handover for how the disk is accessed.

[matteoguglielmi]

Hi,

It means that whith the following grob4dos UEFI menu.lst file:

title WinPE
find --set-root /EFI/boot/winpe.efi
chainloader /EFI/boot/winpe.efi

title WinVHD
find --set-root /win11.vhd
map --mem --top /win11.vhd (hd)
chainloader (hd-1)

I can only boot WinPE because the winpe.efi file is located on the GPT target's EFI partition.

In other words,

the second find command of grub4dos UEFI can't find the win11.vhd file located on the second NTFS partition.

grub4dos, by default, tries to find the requested file in all filesystems... and it does succeed in finding win11.vhd on the second partition of a real drive, but it fails when when an "identical" iscsi target (virtual drive) is sanbooted.

EDIT: I need the secondary NTFS partition because of the 4GB file size limitation of the EFI (fat32) filesystem. The VHD is 20GB, also the client devices are UEFI and not LEGACY so I need grub4dos UEFI.

[NiKiZe]

Have you verified that you see both partitions on the iSCSI target? Have you tried booting to efi shell and verified the paths to the disk/partitions?

It sounds like there is something that prevents it from searching partitions on iSCSI, but you should verify that the partition is there before we should make that conclusion.

[matteoguglielmi]

I found the issue.

grub4dos UEFI could see both partitions but could not read the NTFS filesystem.

It turns out that changing the block size of the backing store device in the definition of the iscsi target in Linux from 4096 to the legacy value of 512 did the trick:

<target iqn.2024-04.net.vn:hdd>
  <backing-store /srv/disks/hdd.img>
    block-size 512
  </backing-store>
</target>

Using 512, grub4dos UEFI can now read the NTFS on the second partition, load the VHD, map it to memory, and boot from it.