Hi, > OK, I've just built and done a very quick test with an arm64 netinst > build.
Does it boot ? Are the partitions mountable ? > 3 313344 313343 0 bytes 0700 Gap1 This looks strange. What do you get from xorriso-1.3.9 -indev tmp.iso -report_system_area plain The name "Gap1" seems to stem from libisofs. These partitions are supposed to fill gaps in the partition layout of grub-mkrescue. But zero sized gaps are not really intended targets. > I've tried both with and without the "-partition_offset all" and it > (obviously) affects the partition alignments and the overall image > size, but otherwise the images produced *look* ok apart from the > odd-looking zero-sized 3rd partition. It's a cosmetic issue only, but > I'm curious why it's there. :-) I assume you mean -partition_cyl_align, not -partition_offset. It is a relict of MBR, its quirks, and its urban legends. SYSLINUX (resp. hpa) emphasizes that isohybrid images have their partitions aligned to full cylinders, preferrably to 64 heads of 32 sectors or to 255 heads of 63 sectors. It seems to be about assumptions made by older BIOSes. UEFI 2.4 does not have hard alignment requirements for partitions. But there are some "should" statements in 5.3.1 GPT Overview, which propose to align to physical block size (e.g. 4096) and state that alignment to 1 MiB fulfills this proposal with "most common physical block sizes and RAID stripe sizes". Currently the alignment granularity of xorriso -as mkisofs is controlled by -partition_hd_cyl and -partition_sec_hd which are subject to MBR restrictions. It has to be tested whether -partition_hd_cyl 64 -partition_sec_hd 32 keeps up the alignment for images larger than 1 GiB (1024 cylinders). Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1095563558780141...@scdbackup.webframe.org