Package: debian-cd Severity: minor When I write the image debian-13.5.0-amd64-netinst.iso via dd to an USB stick and boot the Supermicro server it only boots in legacy mode. If I force UEFI in the BIOS the USB stick is not detected at all. Booting in UEFI mode works, if I boot from a virtual media via IPMI (means a virtual CD). Hardware: Supermicro Server AS -8125GS-TNHR Mainboard: H13DSG-O-CPU-D Firmware 01.08.02 Redfish Version 1.22.2 BIOS Firmware Version BIOS Date: 03/06/2026 Ver 3.9 Bios settings (force UEFI): "Legacy USB Support" selectedOption="Disabled "Boot Mode Select" selectedOption="UEFI" "LEGACY to EFI Support" selectedOption="Enabled" Supermicro says in two FAQs for different servers, that you must "format your USB drive in GPT partition scheme for UEFI." See https://www.supermicro.com/en/support/faqs/faq.php?faq=22149 and https://www.supermicro.com/en/support/faqs/faq.php?faq=41748 I will add more detailed tests with other ISOs, after I gott he bug number.
Here are my detailed tests with - debian-13.5.0-amd64-netinst.iso - grml-full-2026.04-amd64.iso - ubuntu-26.04-desktop-amd64.iso - ubuntu-26.04-live-server-amd64.iso ================================================================================ Test Debian 13.5 netinst - debian-13.5.0-amd64-netinst.iso mounted as virtual media (ISO) via IPMI This ISO then shows up as UEFI: ATEN Virtual CDROM YSOJ and boots in UEFI mode - debian-13.5.0-amd64-netinst.iso written via dd to USB stick This is shown after written the ISO to stick on my laptop: $ blkid /dev/sda1: BLOCK_SIZE="2048" UUID="2026-05-16-10-12-45-00" LABEL="Debian 13.5.0 amd64 n" TYPE="iso9660" PTUUID="605e893e" PTTYPE="dos" PARTUUID="605e893e-01" /dev/sda2: SEC_TYPE="msdos" UUID="DEB0-0001" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="605e893e-02" $ fdisk -l /dev/sda Disk /dev/sda: 476.94 GiB, 512110190592 bytes, 1000215216 sectors Disk model: TS512GESD310C Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x605e893e Device Boot Start End Sectors Size Id Type /dev/sda1 * 0 1546239 1546240 755M 0 Empty /dev/sda2 4112 11311 7200 3.5M ef EFI (FAT-12/16/32) This USB stick does not show up on the Supermicro server in the boot menu list (after pressing F11) -------- If I enter the BIOS and change the BIOS settings to "Legacy USB Support" selectedOption="Enabled" "Boot Mode Select" selectedOption="DUAL" (means UEFI aand legacy) "LEGACY to EFI Support" selectedOption="Enabled" the USB stick boots in legacy mode Inside the BIOS this USB stick is only shown in the Boot option list if Boot mode is legacy or DUAL, not if I choose there UEFI. ================================================================================ Now doing the same tests with different ISOs GRML test ========= writing grml-full-2026.04-amd64.iso via dd to USB stick $ fdisk -l grml-full-2026.04-amd64.iso Disk grml-full-2026.04-amd64.iso: 1.03 GiB, 1100675072 bytes, 2149756 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 $ blkid /dev/sda: BLOCK_SIZE="2048" UUID="2026-04-29-10-30-00-00" LABEL="grml-full-amd64 2026.04" TYPE="iso9660" PTTYPE="dos" In boot menu list it shows as UEFI OS (< and description of USB stick>) and boots fine into linux with UEFI mode ================================================================================ Now doing the same tests with different ISOs Test Ubuntu desktop ISO ======================= ubuntu-26.04-desktop-amd64.iso via dd to USB stick $ fdisk -l ubuntu-26.04-desktop-amd64.iso Disk ubuntu-26.04-desktop-amd64.iso: 6.07 GiB, 6518974464 bytes, 12732372 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 2FDF80BE-E145-40C5-AA53-61A53AB5282E Device Start End Sectors Size Type ubuntu-26.04-desktop-amd64.iso1 64 12721411 12721348 6.1G Microsoft basic data ubuntu-26.04-desktop-amd64.iso2 12721412 12731707 10296 5M EFI System ubuntu-26.04-desktop-amd64.iso3 12731708 12732307 600 300K Microsoft basic data $ blkid /dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="ESP" LABEL="ESP" UUID="172C-47F7" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Appended2" PARTUUID="2fdf80be-e145-40c5-aa51-61a53ab5282e" /dev/sda3: PARTLABEL="Gap1" PARTUUID="2fdf80be-e145-40c5-aa50-61a53ab5282e" /dev/sda1: BLOCK_SIZE="2048" UUID="2026-04-23-02-18-51-00" LABEL="Ubuntu 26.04 amd64" TYPE="iso9660" PARTLABEL="ISO9660" PARTUUID="2fdf80be-e145-40c5-aa52-61a53ab5282e" In boot menu list it shows as UEFI OS (< and description of USB stick>) and boots kernel but no grpahics (maybe because it's a server, nodesktop) ================================================================================ Now doing the same tests with different ISOs Test Ubuntu server ISO ====================== ubuntu-26.04-live-server-amd64.iso via dd to USB stick $ gdisk -l /dev/sda GPT fdisk (gdisk) version 1.0.10 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 1000215216 sectors, 476.9 GiB Model: TS512GESD310C Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 18602C22-4F22-4F06-9B9F-D3276CFC7EAB Partition table holds up to 248 entries Main partition table begins at sector 2 and ends at sector 63 First usable sector is 64, last usable sector is 5700324 Partitions will be aligned on 8-sector boundaries Total free space is 1 sectors (512 bytes) Number Start (sector) End (sector) Size Code Name 1 64 5689427 2.7 GiB 0700 ISO9660 2 5689428 5699723 5.0 MiB EF00 Appended2 3 5699724 5700323 300.0 KiB 0700 Gap1 $ blkdid /dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="ESP" LABEL="ESP" UUID="F211-6A7E" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Appended2" PARTUUID="18602c22-4f22-4f06-9b9d-d3276cfc7eab" /dev/sda3: PARTLABEL="Gap1" PARTUUID="18602c22-4f22-4f06-9b9c-d3276cfc7eab" /dev/sda1: BLOCK_SIZE="2048" UUID="2026-04-20-18-23-36-00" LABEL="Ubuntu-Server 26.04 amd64" TYPE="iso9660" PARTLABEL="ISO9660" PARTUUID="18602c22-4f22-4f06-9b9e-d3276cfc7eab" $ fdisk -l ubuntu-26.04-live-server-amd64.iso Disk ubuntu-26.04-live-server-amd64.iso: 2.72 GiB, 2918598656 bytes, 5700388 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 18602C22-4F22-4F06-9B9F-D3276CFC7EAB Device Start End Sectors Size Type ubuntu-26.04-live-server-amd64.iso1 64 5689427 5689364 2.7G Microsoft basic data ubuntu-26.04-live-server-amd64.iso2 5689428 5699723 10296 5M EFI System ubuntu-26.04-live-server-amd64.iso3 5699724 5700323 600 300K Microsoft basic data In boot menu list it shows as UEFI OS (< and description of USB stick>) and boots fine into linux with UEFI mode
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
317c319
< -append_partition 2 0xef $scratch/efiboot.img \
---
The fixed call of xorriso in my script is now:
xorriso -report_about HINT -as mkisofs -iso-level 3 \
-iso_mbr_part_type 00 \
-full-iso9660-filenames \
-volid "$vname" -appid "$aname" \
-eltorito-boot boot/grub/bios.img \
-no-emul-boot -boot-load-size 4 -boot-info-table \
--eltorito-catalog boot/grub/boot.cat \
--grub2-boot-info \
--grub2-mbr $NFSROOT/usr/lib/grub/i386-pc/boot_hybrid.img \
-eltorito-alt-boot -e EFI/efiboot.img -no-emul-boot \
-append_partition 2 0xef $scratch/efiboot.img \
--exclude $tmp/cow \
-o $isoname -graft-points \
--sort-weight 0 / --sort-weight 1 /boot \
"$tmp" \
/boot/grub/bios.img=$scratch/bios.img \
/EFI/debian/grub.cfg=$scratch/grub.cfg \
/EFI/efiboot.img=$scratch/efiboot.img || die 12 "xorriso failed."
A detailed list of the partitioning info of this ISO will follow.
Hi, Thomas Lange wrote: Then Supermicro is not obeying the EFI specs which mention MBR partition type 0xef as valid way to mark an EFI System Partition. 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.----------------------------------------------------------------------- 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 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
These are the infos for the FAI ISO created by the patched fai-cd script after writing it to an USB stick (/dev/sda). The script uses -appended_part_as_gpt -append_partition 2 0xef $scratch/efiboot.img In the boot menu list it shows as UEFI OS (< and description of USB stick>) and boots fine into linux with UEFI mode $ blkid /dev/sda2: SEC_TYPE="msdos" UUID="B3E0-35D0" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Appended2" PARTUUID="99298f2b-1c15-41c1-ac2a-655adae72156" /dev/sda3: PARTLABEL="Gap1" PARTUUID="99298f2b-1c15-41c1-ac2b-655adae72156" /dev/sda1: PARTLABEL="Gap0" PARTUUID="99298f2b-1c15-41c1-ac29-655adae72156" $ fdisk -l /dev/sda GPT PMBR size mismatch (848223 != 1000215215) will be corrected by write. The backup GPT table is not on the end of the device. Disk /dev/sda: 476.94 GiB, 512110190592 bytes, 1000215216 sectors Disk model: TS512GESD310C Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 99298F2B-1C15-41C1-AC28-655ADAE72156 Device Start End Sectors Size Type /dev/sda1 64 835559 835496 408M Microsoft basic data /dev/sda2 835560 847559 12000 5.9M EFI System /dev/sda3 847560 848159 600 300K Microsoft basic data $ gdisk -l /dev/sda GPT fdisk (gdisk) version 1.0.10 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 1000215216 sectors, 476.9 GiB Model: TS512GESD310C Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 99298F2B-1C15-41C1-AC28-655ADAE72156 Partition table holds up to 248 entries Main partition table begins at sector 2 and ends at sector 63 First usable sector is 64, last usable sector is 848160 Partitions will be aligned on 8-sector boundaries Total free space is 1 sectors (512 bytes) Number Start (sector) End (sector) Size Code Name 1 64 835559 408.0 MiB 0700 Gap0 2 835560 847559 5.9 MiB EF00 Appended2 3 847560 848159 300.0 KiB 0700 Gap1
Hi, Thomas Lange wrote: We are sliding off-topic. But for the case that debian-cd ever considers to switch to neat GPT: Other than MBR partitioning, GPT does not allow a partition to start at block 0. Therefore above partition Gap0 covers most of the ISO 9660 filesystem but is not mountable, because it does not cover the first 64 blocks. /dev/sda1 becomes mountable if you use xorrisofs option -partition_offset 16 This produces a second superblock and a second directory tree which begin at 512-byte-block 64 of /dev/sda and point to the same data file contents as the superblock and tree which begin at block 0 of /dev/sda. xorriso will then name the first partition "ISO9660" instead of "Gap0". The larger the directory tree, the higher the price for this. In case of Debian 13 netinst it would be ~2 MB more of .iso size. Another hint for potential future appended partitions in debian-cd: For El Torito it is not ncessary to have the EFI boot image as data file in the ISO 9660 system. fai-cd could save a few MB by replacing -e EFI/efiboot.img by the magic (but documented) invocation -e --interval:appended_partition_2:all:: which lets the El Torito boot catalog entry for EFI point to the same range that is marked by appended partition 2. To get the saving, it is necessary to keep EFI/efiboot.img out of the ISO filesystem. I.e. the xorriso run for FAI would have to omit this argument: /EFI/efiboot.img=$scratch/efiboot.img Have a nice day :) Thomas
Hi,
* Thomas Schmitt <scdbackup@gmx.net> [260527 11:45]:
our (grml) xorriso command line is (stripped for build paths and
taken from a daily build):
xorriso -as mkisofs \
-V 'grml-full-amd64 d20260527b718' \
-publisher 'grml-live | grml.org' \
-l \
-r \
-J \
-b boot/grub/i386-pc/eltorito.img \
-no-emul-boot \
-boot-load-size 4 \
-boot-info-table \
--grub2-boot-info \
--grub2-mbr
<output_dir>/grml_chroot/usr/lib/grub/i386-pc/boot_hybrid.img \
-eltorito-alt-boot \
-e boot/efi.img \
-no-emul-boot \
-isohybrid-gpt-basdat \
-o <output_dir>/grml_isos/grml-full-daily20260527build718testing-amd64.iso
Maybe this is suboptimal. Any feedback appreciated!
Best,
Chris
Hi,
Chris Hofstaedtler wrote:
grub-mkrescue combines this with option
This option would have caused a MBR partition table and an invalid
GPT as is done for Debian amd64 ISOs. But it belongs to the ISOLINUX
bootloader option -isohybrid-mbr .
So i assume that GRML in the past gave up ISOLINUX for BIOS in favor
of GRUB and that since then there is no partition table.
You may re-enable this kind of partition table by adding option
-part_like_isohybrid
to the xorriso -as mkisofs run.
This yields a valid MBR partition table and an invalid GPT as in
debian-13.5.0-amd64-netinst.iso. The ISO fileystem is mountable as
MBR partition 1. The EFI partition is inside the ISO partition.
If you want specs-compliant GPT with mountable ISO 9660 partition, then
you have to go the way of appended EFI partition, like FAI and Ubuntu
do. GPT does not allow to mark the data file efi.img as partition
inside the partition of the ISO 9660 filesystem.
Consider to explore other bootable ISOs by
xorriso -indev "$iso" -report_el_torito as_mkisofs
to get a guess from xorriso about which -as mkisofs options could be
used to replay the boot equipment. E.g.:
-V 'Ubuntu 24.04.3 LTS amd64'
--modification-date='2025080518202600'
--grub2-mbr --interval:local_fs:0s-15s:zero_mbrpt,zero_gpt:'ubuntu-24.04.3-desktop-amd64.iso'
--protective-msdos-label
-partition_cyl_align off
-partition_offset 16
--mbr-force-bootable
-append_partition 2 28732ac11ff8d211ba4b00a0c93ec93b --interval:local_fs:12383488d-12393647d::'ubuntu-24.04.3-desktop-amd64.iso'
-appended_part_as_gpt
-iso_mbr_part_type a2a0d0ebe5b9334487c068b6b72699c7
-c '/boot.catalog'
-b '/boot/grub/i386-pc/eltorito.img'
-no-emul-boot
-boot-load-size 4
-boot-info-table
--grub2-boot-info
-eltorito-alt-boot
-e '--interval:appended_partition_2_start_3095872s_size_10160d:all::'
-no-emul-boot
(That's the moment to read man xorrisofs or to ask me at
bug-xorriso@gnu.org.
The "--interval:localfs" pseudopaths pick data from the original ISOi
image instead of reading them from hard disk.
"--interval:appended_partition_2" points to the emerging appended
partition. The further text "_start..." is informational and ignored
by xorriso.)
The bootability assessment by libisofs which led xorriso to that guess
can be seen by:
xorriso -indev "$iso" -report_el_torito plain \
-report_system_area plain
Have a nice day :)
Thomas