Hi,
Thomas Lange wrote:
> Supermicro says in two FAQs for different servers, that you must
> "format your USB drive in GPT partition scheme for UEFI."
Then Supermicro is not obeying the EFI specs which mention MBR
partition type 0xef as valid way to mark an EFI System Partition.
> Booting in UEFI mode works, if I boot from a virtual media via IPMI
> (means a virtual CD).
Booting from CD starts at the El Torito Boot Record, not at a partition
table. So the demand for GPT probably does not apply in this case.
-----------------------------------------------------------------------
> writing grml-full-2026.04-amd64.iso via dd to USB stick
> $ fdisk -l grml-full-2026.04-amd64.iso
> ...
> Disklabel type: dos
> ...
> boots fine into linux with UEFI mode
There is no partition table entry in the MBR.
So booting must quite surely have taken its way via El Torito, because
there is no other hint about the position of the EFI partition's
position and size.
You may bring debian-13.5.0-amd64-netinst.iso into a similar state by
erasing its MBR partition table:
cp debian-13.5.0-amd64-netinst.iso test.iso
dd if=/dev/zero conv=notrunc bs=1 seek=446 count=64 of=test.iso
There will still be debris from the invalid GPT of the Debian ISO.
If booting does not work after erasing the MBR partition table, then
you may remove the main GPT header block by:
dd if=/dev/zero conv=notrunc bs=512 seek=1 count=1 of=test.iso
and after determining the address of the last 512-block in the ISO by:
$ /sbin/fdisk -l test.iso
...
Disk test.iso: 755 MiB, 791674880 bytes, 1546240 sectors
...
you may remove the GPT backup header block by:
dd if=/dev/zero conv=notrunc bs=512 seek=1546239 count=1 of=test.iso
Additional to the invalid GPT there is also an Apple Partition Map with
an entry for the EFI partition.
If the result of above dd-operations still does not boot, you could
deface the fake APM Block 0 by:
dd if=/dev/zero conv=notrunc bs=1 count=16 of=test.iso
I'm not sure how legacy BIOS booting would react on zeros at the very
start of the MBR boot code. But there are already lots of zeros in the
first 32 bytes of the MBR. So it might be a harmless change.
In any case the first bytes of an MBR should not matter with EFI
booting.
-----------------------------------------------------------------------
> I have an own script to build my FAI ISO images (script called
> fai-cd). Those images had the same problem as the Debian netinst
> ISO. I could fix it with this change:
> 287d288
> < -iso_mbr_part_type 00 \
> 295a297
> -appended_part_as_gpt \
-appended_part_as_gpt is the decisive option to get GPT.
-iso_mbr_part_type 00 should then be insignificant, regardless whether
it stays in or not.
317c319
< -append_partition 2 0xef $scratch/efiboot.img \
---
> -append_partition 2 0xee $scratch/efiboot.img \
I think that MBR type code 0xee is not really correct here.
I once wrote in man xorrisofs:
-appended_part_as_gpt
...
Given MBR partition types get translated. 0xef becomes
C12A7328-F81F-11D2-BA4B-00A0C93EC93B, others become
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7.
The type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B is prescribed by EFI
specs to mark an EFI System Partition.
But EFI firmwares don't take this overly serious and are willing to
peek into any partition with a FAT filesystem whether there is a
\EFI\BOOT directory with a start program.
Nevertheless i advise to stay with 0xef, if it works for you.
(0xee as only partition entry marks an MBR as "protective" and is an
important part of the indication that a GPT is present. xorriso will
write such a 0xee partition into the MBR when it produces a GPT.)
Have a nice day :)
Thomas
