Hi, Pascal Hambourg wrote: > Tested with debian-12.6.0-amd64-netinst.iso on QEMU+OVMF and real hardware: > (proc) (memdisk) (cd0) (cd0,apple2) (cd0,apple1) (cd0,msdos2)
I wonder from where (cd0,apple2) comes. A Debian amd64 netinst ISO has a single APM partition which marks the EFI El Torito boot image which serves also as EFI system partition. The same is done by MBR partition 2. So (cd0,msdos2) is plausible. MBR partition 1 marks the whole ISO filesystem. It has type 0x00 because some software hates when partition 1 encloses partition 2. So it is plausible that (cd0,msdos1) is not shown. ISOs from grub-mkrescue for EFI have a different partition set: GPT partition 2 marks the EFI system partition (which also serves as boot image for El Torito). GPT partition 3 marks the range of the HFS+ personality of that ISO (the HFS+ tree shows the same files as the ISO 9660 tree, with case insensitive names). GPT partition 1 covers parts of the ISO filesystem up to the start of the EFI partition. It is not mountable because it does not begin at LBA 0 where the whole ISO begins. GPT partition 4 covers the traditional 300 KiB tail padding which protects aginst the traditional Read-Ahead-Bug of Linuxi with CDs burnt by write type TAO. APM partition 1 covers parts of the ISO filesystem up to the start of the HFS+ partition. APM partition 2 marks the the range of the HFS+ personality. APM partition 3 covers the range from the end of the ISO/HFS+ filesystem to the end of the ISO image. This includes the CD TAO tail padding. This partition layout was requested by Vladimir Serbinenko who also provided the HFS+ implementation for libisofs. I personally find those layouts preferrable where the EFI partition is not a file in the ISO 9660 filesystem. This makes it possible to mark the ISO 9660 filesystem as mountable partition 1 which is disjoint from the EFI system partition 2. Recent Ubuntu ISOs bear this layout with GPT partitions and a second ISO 9660 superblock for partition start at GPT LBA 64. Have a nice day :) Thomas
