Re: arm64 and isohybrid
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. steve@einval.com
Who needs computer imagery when you've got Brian Blessed?
Reply to: