On Sat, Apr 18, 2015 at 10:13:52AM +0200, Thomas Schmitt wrote: >Hi, > >> OK, I've just built and done a very quick test with an arm64 netinst >> build. > >Does it boot ?
Yes. >Are the partitions mountable ? The first two are, yes. >> 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 tack:~/iso$ ~/debian/xorriso/xorriso-1.3.9/xorriso/xorriso -indev tmp.iso -report_system_area plain GNU xorriso 1.3.9 : RockRidge filesystem manipulator, libburnia project. xorriso : NOTE : Loading ISO image tree from LBA 0 xorriso : UPDATE : 1238 nodes read in 1 seconds xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded Drive current: -indev 'tmp.iso' Media current: stdio file, overwriteable Media status : is written , is appendable Boot record : El Torito , MBR cyl-align-off GPT Media summary: 1 session, 77824 data blocks, 152m data, 29.2g free Volume id : 'Debian testing arm64 1' System area options: 0x00000a00 System area summary: MBR cyl-align-off GPT ISO image size/512 : 311296 Partition offset : 16 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0xee 1 313407 GPT : N Info GPT disk GUID : ecd273256b45754da0f3da94b2713406 GPT entry array : 2 248 separated GPT lba range : 64 313344 313407 GPT partition name : 1 490053004f003900360036003000 GPT partname local : 1 ISO9660 GPT partition GUID : 1 ecd273256b45754da0f0da94b2713406 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1000000000000001 GPT start and size : 1 64 311232 GPT partition name : 2 41007000700065006e006400650064003200 GPT partname local : 2 Appended2 GPT partition GUID : 2 ecd273256b45754da0f1da94b2713406 GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b GPT partition flags: 2 0x0000000000000000 GPT start and size : 2 311296 2048 >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. ACK. >> 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. No, explicitly -partition_offset. I'd added -partition_cyl_align already as you said. >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". Yup. >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). -- Steve McIntyre, Cambridge, UK. [email protected] Who needs computer imagery when you've got Brian Blessed? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
