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: 0x0a00 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 TypeStart Blocks MBR partition : 1 0x00 0xee1 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 0x1001 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 0x 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.st...@einval.com Who needs computer imagery when you've got Brian Blessed? -- 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/20150420171027.gc...@einval.com
Re: arm64 and isohybrid
On Sat, Apr 18, 2015 at 11:45:16AM +0200, Thomas Schmitt wrote: Hi, the third, zero sized partition Gap1 gets indeed produced by libisofs. xorriso command -report_system_area does not show it, though. ACK, I can see that. I am investigating. You may assume that this partition will not be produced in future xorriso versions. Cool. I'll be honest, there's no rush for this for me. The earlier image format using an appended msdos partition rather than GPT is working fine for now, and is what I'm going to use for the Jessie release this coming weekend. I might be tempted to switch to GPT later for this, but it's just too close to release to be playing with this kind of change... :-) If the Gap1 partition entry is suspected to disturb anything, you may create the intended state of GPT by dd if=/dev/zero of=tmp.iso conv=notrunc bs=1 seek=1280 count=128 (Actually one would have to zeroize the entry in the backup GPT, too. Its position is 62 blocks before the backup header block + 256 bytes. The header block number is given by xorriso -report_system area as third number in line GPT lba range. E.g with GPT lba range : 64 266240 266303 the backup entry of partition 3 is at byte (266303 - 62) * 512 + 256. ) Right. The Gap1 partition doesn't seem to cause any problems on the one device I've got handy for testing, anyway. -- Steve McIntyre, Cambridge, UK.st...@einval.com This dress doesn't reverse. -- Alden Spiess -- 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/20150420171435.gd...@einval.com
Re: arm64 and isohybrid
Hi, i wrote: The name Gap1 seems to stem from libisofs. The cause was found and a fix is being tested meanwhile. Steve McIntyre wrote: The Gap1 partition doesn't seem to cause any problems on the one device I've got handy for testing, anyway. In any case it looks clueless. (The stupid gap filler wanted to cover the backup GPT by a partition, whereas the less stupid partition writer truncated it to the permissible range.) Steve McIntyre wrote: I've tried both with and without the -partition_offset all I assume you mean -partition_cyl_align, not -partition_offset. No, explicitly -partition_offset. I'd added -partition_cyl_align already as you said. -partition_offset expects a block number as argument. all is read as 0. Without -partition_offset 16, the first GPT partition is supposed to be not mountable. So some riddling remains on my side ... i wrote: 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). Currently libisofs enlarges the cylinder size if the number of cylinders exceeds 1024. But i am testing a change now, which allows an unlimited number of cylinders for GPT. So -partition_hd_cyl 64 -partition_sec_hd 32 -partition_cyl_align all will ensure alignment to 1 MiB, if desired. I'll be honest, there's no rush for this for me. This will leave more time for my tests. My best wishes for Jessie's scheduled birth and all her proud parents. 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/9923563113283909...@scdbackup.webframe.org
Re: arm64 and isohybrid
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
Re: arm64 and isohybrid
Hi, the third, zero sized partition Gap1 gets indeed produced by libisofs. xorriso command -report_system_area does not show it, though. I am investigating. You may assume that this partition will not be produced in future xorriso versions. If the Gap1 partition entry is suspected to disturb anything, you may create the intended state of GPT by dd if=/dev/zero of=tmp.iso conv=notrunc bs=1 seek=1280 count=128 (Actually one would have to zeroize the entry in the backup GPT, too. Its position is 62 blocks before the backup header block + 256 bytes. The header block number is given by xorriso -report_system area as third number in line GPT lba range. E.g with GPT lba range : 64 266240 266303 the backup entry of partition 3 is at byte (266303 - 62) * 512 + 256. ) 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/32682563547280315...@scdbackup.webframe.org
Re: arm64 and isohybrid
On Tue, Apr 14, 2015 at 08:41:35PM +0200, Thomas Schmitt wrote: Hi, i wrote back in february: I am still hunting a bug in the pending changeset to enable production of a UEFI compliant protective MBR plus GPT layout with -append_partition. [...] This proposal will look like xorriso-1.3.9 -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -e boot/grub/efi.img -no-emul-boot \ -append_partition 2 0xef arm64-efi.img \ -appended_part_as_gpt \ -partition_offset 16 \ /mnt/iso Steve McIntyre wrote today: Right. If you're still working on this I'd be very interested in testing it! Well, the changesets are committed, meanwhile. But when i now tested above proposal (before bragging), it turned out that production of a true protective MBR partition table works only with isohybrid MBR. (I wonder what use case i tested 10 weeks ago ...) ... Now above sketch works. The risk of regression by my last minute change is low. Nevertheless have a sharp look at i386 and amd64 results when this version of xorriso produces them. I did not make any Jigdo tests with -append_partition yet. As said: -partition_offset 16 is essential for a mountable GPT partition 1 with the ISO filesystem. -- The current GNU xorriso development snapshot has the new -as mkisofs option -appended_part_as_gpt, which lets the ISO and the appended partition appear in GPT, with UEFI compliant protective MBR. http://www.gnu.org/software/xorriso/xorriso-1.3.9.tar.gz MD5 9577c69da2591c683ca2cf84d29e6191 Version timestamp : 2015.04.13.172501 OK, I've just built and done a very quick test with an arm64 netinst build. This gives me the following: $ gdisk -l iso/tmp.iso GPT fdisk (gdisk) version 0.8.5 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk iso/tmp.iso: 313408 sectors, 153.0 MiB Logical sector size: 512 bytes Disk identifier (GUID): 2573D2EC-456B-4D75-A0F3-DA94B2713406 Partition table holds up to 248 entries First usable sector is 64, last usable sector is 313344 Partitions will be aligned on 64-sector boundaries Total free space is 1 sectors (512 bytes) Number Start (sector)End (sector) Size Code Name 1 64 311295 152.0 MiB 0700 ISO9660 2 311296 313343 1024.0 KiB EF00 Appended2 3 313344 313343 0 bytes 0700 Gap1 (using the command line options: ~93sam/xorriso-1.3.9/xorriso/xorriso -as mkisofs -r \ -checksum_algorithm_iso md5,sha1,sha256,sha512 \ -V 'Debian testing arm64 1' -o tmp.iso \ ($jigdo_opts) \ -J -joliet-long -cache-inodes -e boot/grub/efi.img -no-emul-boot \ -append_partition 2 0xef CD1/boot/grub/efi.img \ -partition_cyl_align all \ -appended_part_as_gpt -partition_offset 16 CD1) 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. :-) We would have to change the CD FAQ about verification of ISOs, because this advises to determine the exact amount of image bytes from the ISO filesystem size. Ah, yes. But with above layout there is a neat disk-like situation where the ISO filesystem ends before the EFI System Partition begins. So one will rather have to checksum up to the end of the second partition (as inquired by gdisk or alike). Best would be if the Debian checksum lists would be accompanied by length lists, which simply tell the original size of the images by which the MD5s were computed. Maybe, yes. snip Maybe not by us directly, but I think a fair number of Debian users like the ability to extend/modify images later and we have docs telling them how to add partitions once an image is written to a USB stick, for example. As soon as the image is on a block device with inquirable size, the partition editors should offer an option to move the backup GPT to the end of the device. That would be the first step before installing further partitions. The docs need to be checked whether they are updated for GPT. ACK. -- Steve McIntyre, Cambridge, UK.st...@einval.com ...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver. -- Daniel Pead -- 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/20150417235852.ga1...@einval.com
Re: arm64 and isohybrid
Hi Thomas! I said I'd get back to you *ages* ago. Sorry. :-/ On Wed, Feb 04, 2015 at 06:06:45PM +0100, Thomas Schmitt wrote: Hi, -isohybrid-mbr null.mbr \ -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \ This may look valid, but gdisk and other code I've used don't cope well with the PMBR being broken. But that's not the fault of the NUL-bytes in null.mbr. The isohybbrid --gpt layout does not comply to UEF/GPT. Either there must be a protective MBR with a single partition of type 0xee, reaching from LBA 1 up to the backup GPT. In that case, GPT represents the partitions, which must not overlap. Right. Or there may be a Legacy MBR with non-overlapping partitions of which one needs to have type 0xef and marks the EFI system partition with the FAT filesystem. OK. When i plug the USB stick with the resulting image into my olde Linux, it probably uses the MBR to create a mountable /dev/sdb2 with efi/boot/bootaa64.efi in it. Further my Linux tolerates that partition 2 is located inside partition 1. That's the sin of overlapping. -efi-boot-part --efi-boot-image \ neither Gap0 nor Gap1 are usable That's a known disadvantage of grub-mkrescue partition layout. It complies to UEFI but the ISO can only be mounted by the base device. Especially udev and blkid do not handle this well. They happily let partition 1 inherit the filesystem identification of the base device. Yup. I think that may be the problem I'm seeing in fact - we're using blkid etc. in debian-installer. (On the other hand, who needs udev to find a CD or USB stick when the freshly booted kernel is the own well known one ? The list of possible device files is very finite.) I guess I see what you've done, Urm. Blame Vladimir Serbinenko for that layout. He has good arguments for it. I have questioned it several times but he always staid firm. :-/ However, this isn't helpful for the Debian installer which now can't find the rest of the installer on any partition. Depending on udev early ? Your findings match the reasons why Legacy MBR won in my discussion of mini.iso https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776317#75 The waste of 1 MB for an appended external partition seems worthwhile. Right, I don't think it's a major problem. Stripping down my best proposal from BIOS+EFI to EFI-only: mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso # Get a copy of the El Torito EFI system partition cp /mnt/iso/boot/grub/efi.img arm64-efi.img # Append that copy as MBR partition of type 0xef xorriso -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -e boot/grub/efi.img -no-emul-boot \ -append_partition 2 0xef arm64-efi.img \ -partition_cyl_align all \ /mnt/iso This yields a non-overlapping UEFI compliant Legacy MBR MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x00 0x830 262144 MBR partition : 2 0x00 0xef 262144 2048 The NUL-bytes in the MBR are no problem because of UEF 2.4 5.2.1 The boot code on the MBR is not executed by UEFI firmware. UEFI 2.4, table 13 shows that it needs at least one partition table entry and the magic 0x55 0xaa at bytes 510 and 511. The only effect of omitting option -isohybrid is that the type of partition 1 is 0x83 rather than 0x17. Right. I honestly don't think that's an issue to worry about. - I am still hunting a bug in the pending changeset to enable production of a UEFI compliant protective MBR plus GPT layout with -append_partition. This would be the second best proposal from bug=776317#75. Disadvantages in comparison to above winner: You get a mountable ISO partition only if you use -partition_offset 16 The backup GPT makes mini.iso production postprocessing cumbersome. (This might be no problem with netinst.iso because no postprocessing shall happen in debian-cd anyway.) Maybe not by us directly, but I think a fair number of Debian users like the ability to extend/modify images later and we have docs telling them how to add partitions once an image is written to a USB stick, for example. This proposal will look like the above one, with additional novel option -appended_part_as_gpt and partition offset 16: xorriso-1.3.9 -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -e boot/grub/efi.img -no-emul-boot \ -append_partition 2 0xef arm64-efi.img \ -appended_part_as_gpt \ -partition_offset 16 \ /mnt/iso will yield: ISO image size/512 : 264192 ... MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x00 0xee1 265023 GPT: N Info GPT disk GUID : 95a21034fca5864bbf6738ff7f0c9a04 GPT entry array: 2 248 separated GPT lba
Re: arm64 and isohybrid
Hi, i wrote back in february: I am still hunting a bug in the pending changeset to enable production of a UEFI compliant protective MBR plus GPT layout with -append_partition. [...] This proposal will look like xorriso-1.3.9 -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -e boot/grub/efi.img -no-emul-boot \ -append_partition 2 0xef arm64-efi.img \ -appended_part_as_gpt \ -partition_offset 16 \ /mnt/iso Steve McIntyre wrote today: Right. If you're still working on this I'd be very interested in testing it! Well, the changesets are committed, meanwhile. But when i now tested above proposal (before bragging), it turned out that production of a true protective MBR partition table works only with isohybrid MBR. (I wonder what use case i tested 10 weeks ago ...) ... Now above sketch works. The risk of regression by my last minute change is low. Nevertheless have a sharp look at i386 and amd64 results when this version of xorriso produces them. I did not make any Jigdo tests with -append_partition yet. As said: -partition_offset 16 is essential for a mountable GPT partition 1 with the ISO filesystem. -- The current GNU xorriso development snapshot has the new -as mkisofs option -appended_part_as_gpt, which lets the ISO and the appended partition appear in GPT, with UEFI compliant protective MBR. http://www.gnu.org/software/xorriso/xorriso-1.3.9.tar.gz MD5 9577c69da2591c683ca2cf84d29e6191 Version timestamp : 2015.04.13.172501 (I finely mistyped the date when faking the timestamp.) -- We would have to change the CD FAQ about verification of ISOs, because this advises to determine the exact amount of image bytes from the ISO filesystem size. But with above layout there is a neat disk-like situation where the ISO filesystem ends before the EFI System Partition begins. So one will rather have to checksum up to the end of the second partition (as inquired by gdisk or alike). Best would be if the Debian checksum lists would be accompanied by length lists, which simply tell the original size of the images by which the MD5s were computed. -- The backup GPT makes mini.iso production postprocessing cumbersome. (This might be no problem with netinst.iso because no postprocessing shall happen in debian-cd anyway.) Maybe not by us directly, but I think a fair number of Debian users like the ability to extend/modify images later and we have docs telling them how to add partitions once an image is written to a USB stick, for example. As soon as the image is on a block device with inquirable size, the partition editors should offer an option to move the backup GPT to the end of the device. That would be the first step before installing further partitions. The docs need to be checked whether they are updated for GPT. 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/31582562590819864...@scdbackup.webframe.org
Re: arm64 and isohybrid
On Wed, Feb 11, 2015 at 03:48:07PM +0100, Thomas Schmitt wrote: Hi, Steve McIntyre wrote: partition 2 seems broken and I can't mount it. If I specify -c isolinux/boot.cat too, that fixes it. Is there any new insight in this mystery ? Hi Thomas, Apologies, no - I've been busy at a conference for a week and now I'm away on vacation down in Australia for several weeks. If I try to spend any time hacking on this stuff on holiday, my wife will hurt me... :-) I'll carry on looking when I'm back... -- Steve McIntyre, Cambridge, UK.st...@einval.com When C++ is your hammer, everything looks like a thumb. -- Steven M. Haflich -- 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/20150219234610.gk12...@einval.com
Re: arm64 and isohybrid
Hi, Steve McIntyre wrote: partition 2 seems broken and I can't mount it. If I specify -c isolinux/boot.cat too, that fixes it. Is there any new insight in this mystery ? If it is reproducible, then my understanding of partitions is in deep trouble. I'd need to investigate and compare an ISO with usable partition against one with unusable partition. - Only remotely related: I found a new compliant partiton layout in the web. It could avoid the duplication of the EFI partition at the cost of a second ISO superblock and directory tree, if one would develop it further. openSUSE-13.1-NET-x86_64.iso has a mountable ISO filesystem in MBR partiton 2 and on the base device: MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x00 0xef 280 8192 MBR partition : 2 0x80 0x17 8472 573160 MBR partition path : 1 /boot/x86_64/efi Both ISO directory trees share most data files in the ISO. Only their files /boot/x86_64/efi are located in different content blocks. If i get it right, then https://github.com/openSUSE/kiwi/blob/master/modules/KIWIIsoLinux.pm lets mkisofs produce a first ISO with EFI FAT as first data file. The head of this ISO is cut off after the content of the EFI FAT. The rest (rump) of the first ISO is thrown away. The harvested ISO head is then brought as data file into the second, final ISO. There it is stored as second file after the EFI FAT, where partition 1 ends and partition 2 begins. (It gets hidden from the directory tree in the second ISO, but that's not really needed for the trick.) Because both mkisofs runs sort the other data file blocks to the same sequence, the ISO head gets retransplanted to an identical copy of its old rump. So partiton 2 becomes mountable as ISO 9660. This layout is still as wasteful as xorriso appended partition plus partition offset 16. But it should be possible to substitute the duplicate FAT image file in the second ISO by a missing FAT image file in the first ISO. The first ISO is only for mounting as partition 2. The El Torito boot image and FAT partition 1 are needed in the second, outer ISO. - 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/25391545144987796...@scdbackup.webframe.org
Re: arm64 and isohybrid
Hi, If I specify -c isolinux/boot.cat too, that fixes it. That's surprising. Can you surely switch forth and back between mounatble and unmountable by this option ? Option -c just gives the El Torito catalog a file name. The catalog file is not involved in booting from USB-stick or in the hard-disk-like partitioning of the image. efi.img is being modified otherwise, it seems? El Torito boot images get modified only if options -boot-info-table or --grub2-boot-info are present. You can check this by comparing boot/grub/efi.img of the ISO with boot/grub/efi.img in the input file tree on hard disk. 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/24263544702434404...@scdbackup.webframe.org
Re: arm64 and isohybrid
Hi, -isohybrid-mbr null.mbr \ -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \ This may look valid, but gdisk and other code I've used don't cope well with the PMBR being broken. But that's not the fault of the NUL-bytes in null.mbr. The isohybbrid --gpt layout does not comply to UEF/GPT. Either there must be a protective MBR with a single partition of type 0xee, reaching from LBA 1 up to the backup GPT. In that case, GPT represents the partitions, which must not overlap. Or there may be a Legacy MBR with non-overlapping partitions of which one needs to have type 0xef and marks the EFI system partition with the FAT filesystem. When i plug the USB stick with the resulting image into my olde Linux, it probably uses the MBR to create a mountable /dev/sdb2 with efi/boot/bootaa64.efi in it. Further my Linux tolerates that partition 2 is located inside partition 1. That's the sin of overlapping. -efi-boot-part --efi-boot-image \ neither Gap0 nor Gap1 are usable That's a known disadvantage of grub-mkrescue partition layout. It complies to UEFI but the ISO can only be mounted by the base device. Especially udev and blkid do not handle this well. They happily let partition 1 inherit the filesystem identification of the base device. (On the other hand, who needs udev to find a CD or USB stick when the freshly booted kernel is the own well known one ? The list of possible device files is very finite.) I guess I see what you've done, Urm. Blame Vladimir Serbinenko for that layout. He has good arguments for it. I have questioned it several times but he always staid firm. However, this isn't helpful for the Debian installer which now can't find the rest of the installer on any partition. Depending on udev early ? Your findings match the reasons why Legacy MBR won in my discussion of mini.iso https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776317#75 The waste of 1 MB for an appended external partition seems worthwhile. Stripping down my best proposal from BIOS+EFI to EFI-only: mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso # Get a copy of the El Torito EFI system partition cp /mnt/iso/boot/grub/efi.img arm64-efi.img # Append that copy as MBR partition of type 0xef xorriso -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -e boot/grub/efi.img -no-emul-boot \ -append_partition 2 0xef arm64-efi.img \ -partition_cyl_align all \ /mnt/iso This yields a non-overlapping UEFI compliant Legacy MBR MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x00 0x830 262144 MBR partition : 2 0x00 0xef 262144 2048 The NUL-bytes in the MBR are no problem because of UEF 2.4 5.2.1 The boot code on the MBR is not executed by UEFI firmware. UEFI 2.4, table 13 shows that it needs at least one partition table entry and the magic 0x55 0xaa at bytes 510 and 511. The only effect of omitting option -isohybrid is that the type of partition 1 is 0x83 rather than 0x17. - I am still hunting a bug in the pending changeset to enable production of a UEFI compliant protective MBR plus GPT layout with -append_partition. This would be the second best proposal from bug=776317#75. Disadvantages in comparison to above winner: You get a mountable ISO partition only if you use -partition_offset 16 The backup GPT makes mini.iso production postprocessing cumbersome. (This might be no problem with netinst.iso because no postprocessing shall happen in debian-cd anyway.) This proposal will look like the above one, with additional novel option -appended_part_as_gpt and partition offset 16: xorriso-1.3.9 -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -e boot/grub/efi.img -no-emul-boot \ -append_partition 2 0xef arm64-efi.img \ -appended_part_as_gpt \ -partition_offset 16 \ /mnt/iso will yield: ISO image size/512 : 264192 ... MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x00 0xee1 265023 GPT: N Info GPT disk GUID : 95a21034fca5864bbf6738ff7f0c9a04 GPT entry array: 2 248 separated GPT lba range : 64 264960 265023 GPT partition name : 1 490053004f003900360036003000 GPT partname local : 1 ISO9660 GPT partition GUID : 1 95a21034fca5864bbf6438ff7f0c9a04 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1001 GPT start and size : 1 64 264128 GPT partition name : 2 41007000700065006e006400650064003200 GPT partname local : 2 Appended2 GPT partition GUID : 2 95a21034fca5864bbf6538ff7f0c9a04 GPT type GUID : 2 28732ac11ff8d211ba4b00a0c93ec93b GPT
Re: arm64 and isohybrid
On Wed, Feb 04, 2015 at 03:12:30PM +, Steve McIntyre wrote: On Sat, Jan 31, 2015 at 10:24:17AM +, Steve McIntyre wrote: On Thu, Jan 29, 2015 at 11:41:57AM +0100, Thomas Schmitt wrote: After reading its /.disk/mkisofs, i re-pack it by # A dummy MBR template as substitute for isohdpfx.bin dd if=/dev/zero bs=432 count=1 of=null.mbr mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso xorriso -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -isohybrid-mbr null.mbr \ -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \ /mnt/iso Omitted options: all Jigdo options -eltorito-alt-boot is a separator which is needed only if already a boot image was defined by -b, -e, or alike Added options: -isohybrid-gpt-basdat works only if -isohybrid-mbr is present -isohybrid-mbr gets as input the dummy MBR template. So SYSLINUX is not needed. OK. This may look valid, but gdisk and other code I've used don't cope well with the PMBR being broken. I can mount partition 1 fine for the normal ISO contents, but partition 2 seems broken and I can't mount it. Maybe an offset bug(?), or things are being too confused by the GPT-MBR disconnect here. In fact, no. If I specify -c isolinux/boot.cat too, that fixes it. efi.img is being modified otherwise, it seems? -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there? -- 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/20150204164205.gc11...@einval.com
Re: arm64 and isohybrid
On Sat, Jan 31, 2015 at 10:24:17AM +, Steve McIntyre wrote: On Thu, Jan 29, 2015 at 11:41:57AM +0100, Thomas Schmitt wrote: After reading its /.disk/mkisofs, i re-pack it by # A dummy MBR template as substitute for isohdpfx.bin dd if=/dev/zero bs=432 count=1 of=null.mbr mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso xorriso -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -isohybrid-mbr null.mbr \ -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \ /mnt/iso Omitted options: all Jigdo options -eltorito-alt-boot is a separator which is needed only if already a boot image was defined by -b, -e, or alike Added options: -isohybrid-gpt-basdat works only if -isohybrid-mbr is present -isohybrid-mbr gets as input the dummy MBR template. So SYSLINUX is not needed. OK. This may look valid, but gdisk and other code I've used don't cope well with the PMBR being broken. I can mount partition 1 fine for the normal ISO contents, but partition 2 seems broken and I can't mount it. Maybe an offset bug(?), or things are being too confused by the GPT-MBR disconnect here. The result shows nested partitions in MBR and GPT. This is the mjg layout, which partition editors dislike heavily but seems to work well in the amd64 netinst ISOs. It offers three entry points for booting: El Torito, MBR, GPT. El Torito catalog : 832 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 UEFI y none 0x 0x00768 833 El Torito img path : 1 /boot/grub/efi.img System area options: 0x0900 System area summary: MBR cyl-align-on GPT ISO image size/512 : 262144 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x000 262144 MBR partition : 2 0x00 0xef 3332 768 MBR partition path : 2 /boot/grub/efi.img GPT: N Info GPT disk GUID : 8822d6a0aadcde40a8afcd569dc28802 GPT entry array: 2 248 overlapping GPT lba range : 64 262080 262143 GPT partition name : 1 490053004f00480079006200720069006400 GPT partname local : 1 ISOHybrid GPT partition GUID : 1 8822d6a0aadcde40a8adcd569dc28802 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1001 GPT start and size : 1 0 262080 GPT partition name : 2 490053004f004800790062007200690064003100 GPT partname local : 2 ISOHybrid1 GPT partition GUID : 2 8822d6a0aadcde40a8accd569dc28802 GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 2 0x1001 GPT start and size : 2 3332 768 GPT partition path : 2 /boot/grub/efi.img Right. Of course it is odd to use ISOLINUX related xorriso commands with pure GRUB2 boot equipment. Especially since Vladimir Serbinenko puts much emphasis on a neat partition table. Let's try an option which was introduced for grub-mkrescue xorriso -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -efi-boot-part --efi-boot-image \ -e boot/grub/efi.img -no-emul-boot \ /mnt/iso Added options: -efi-boot-part with special argument --efi-boot-image marks the first EFI El Torito boot image as partition in GPT. Only a protective MBR emerges, which complies to GPT specs. (Other than a multi-partition MBR.) Woo. :-) Bugger. After more testing, this is not working well for me. It's generating 3 partitions: Number Start (sector)End (sector) Size Code Name 1 643867 1.9 MiB 0700 Gap0 238684635 384.0 KiB EF00 EFI boot partition 34636 365891 176.4 MiB 0700 Gap1 where neither Gap0 nor Gap1 are usable for mounting. I guess I see what you've done, just slicing up the image to make the EFI boot partition work. However, this isn't helpful for the Debian installer which now can't find the rest of the installer on any partition. It's used to looking for things in a normal isohybrid manner where it can mount the main ISO contents as a partition too. I tried to force the efi.img file to tne end of the media to make Gap0 functional, but that doesn't seem to help at all. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe.
Re: arm64 and isohybrid
On Sat, Jan 31, 2015 at 06:59:44PM +0100, Thomas Schmitt wrote: Hi, *grin* You're not selling this very much... :-) Do you complain about losing an item from your todo list ? Certainly not. :-) How about you replace it by the intent to fix bug 776317: amd64 mini.iso : BIOS or EFI boot from CD or USB stick, with the complication to keep the firmware partition digestible for partition editors. I am preparing a conclusion post with lengthy considerations, xorriso novelties, and proposals. An excellent candidate for being way behind with deciding and implementing it. (It will pass through this list. Bystanders be warned.) OK! I spoke briefly to Ian Campbell about this last night (we're both at FOSDEM) and I see he's responded in that bug# too... -- Steve McIntyre, Cambridge, UK.st...@einval.com Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast. Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html -- 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/20150201152334.gp8...@einval.com
Re: arm64 and isohybrid
On Sat, Jan 31, 2015 at 01:24:39PM +0100, Thomas Schmitt wrote: Hi, Steve McIntyre: I'm also *way* overdue on switching all of debian-cd over to using xorriso and using native xorriso options totally rather than the -as-mkisofs stuff equivalents. But that's a topic for another day... You will be a trailblazer. Nobody else does this, except me, when testing the new feature to generate commands from the analyzed boot equipment of ISOs. The -as mkisofs command is an offcial part of xorriso. You may well stay with it as long as there are no demands which cannot be fulfilled with its option interface. (E.g. it is not very suitable for multi-session and allows few file manipulations inside the ISO.) One may question the beauty of -boot_image any efi_boot_part=--efi-boot-image -boot_image any cat_path='/boot.catalog' -boot_image any efi_path='/boot/grub/efi.img' relative to -efi-boot-part --efi-boot-image -c '/boot.catalog' -e '/boot/grub/efi.img' -no-emul-boot *grin* You're not selling this very much... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com sladen I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying Paul: This fridge and fittings are the correct way around and do not need altering -- 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/20150131151038.ge8...@einval.com
Re: arm64 and isohybrid
Hi, *grin* You're not selling this very much... :-) Do you complain about losing an item from your todo list ? How about you replace it by the intent to fix bug 776317: amd64 mini.iso : BIOS or EFI boot from CD or USB stick, with the complication to keep the firmware partition digestible for partition editors. I am preparing a conclusion post with lengthy considerations, xorriso novelties, and proposals. An excellent candidate for being way behind with deciding and implementing it. (It will pass through this list. Bystanders be warned.) 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/360454369975663...@scdbackup.webframe.org
Re: arm64 and isohybrid
On Thu, Jan 29, 2015 at 11:41:57AM +0100, Thomas Schmitt wrote: Hi, Hi Thomas! i wonder why my mail of Thu, 29 Jan 2015 08:14:08 +0100 does not show up in debian-cd mailing list. It reported about a preliminary experiment with amd64 mini.iso. Easy; you just sent it to me directly, not to the list(s)... :-) Meanwhile it is quite outdated by my new experiments with an arm64 ISO. - I downloaded http://cloudfront.debian.net/cdimage/jessie_di_beta_2/arm64/iso-cd/debian-jessie-DI-b2-arm64-netinst.iso of 2014-10-03. Inspection yields: Volume id: 'Debian jessie-DI-b2 arm64 1' El Torito catalog : 832 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 UEFI y none 0x 0x00768 833 El Torito img path : 1 /boot/grub/efi.img xorriso : NOTE : No System Area was loaded This looks like amd64 mini.iso without the BIOS stuff. That's as we'd expect, yes. We support arm64 booting off CD/USB via UEFI; there's nothing like the BIOS boot. After reading its /.disk/mkisofs, i re-pack it by # A dummy MBR template as substitute for isohdpfx.bin dd if=/dev/zero bs=432 count=1 of=null.mbr mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso xorriso -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -isohybrid-mbr null.mbr \ -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \ /mnt/iso Omitted options: all Jigdo options -eltorito-alt-boot is a separator which is needed only if already a boot image was defined by -b, -e, or alike Added options: -isohybrid-gpt-basdat works only if -isohybrid-mbr is present -isohybrid-mbr gets as input the dummy MBR template. So SYSLINUX is not needed. OK. The result shows nested partitions in MBR and GPT. This is the mjg layout, which partition editors dislike heavily but seems to work well in the amd64 netinst ISOs. It offers three entry points for booting: El Torito, MBR, GPT. El Torito catalog : 832 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 UEFI y none 0x 0x00768 833 El Torito img path : 1 /boot/grub/efi.img System area options: 0x0900 System area summary: MBR cyl-align-on GPT ISO image size/512 : 262144 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x000 262144 MBR partition : 2 0x00 0xef 3332 768 MBR partition path : 2 /boot/grub/efi.img GPT: N Info GPT disk GUID : 8822d6a0aadcde40a8afcd569dc28802 GPT entry array: 2 248 overlapping GPT lba range : 64 262080 262143 GPT partition name : 1 490053004f00480079006200720069006400 GPT partname local : 1 ISOHybrid GPT partition GUID : 1 8822d6a0aadcde40a8adcd569dc28802 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1001 GPT start and size : 1 0 262080 GPT partition name : 2 490053004f004800790062007200690064003100 GPT partname local : 2 ISOHybrid1 GPT partition GUID : 2 8822d6a0aadcde40a8accd569dc28802 GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 2 0x1001 GPT start and size : 2 3332 768 GPT partition path : 2 /boot/grub/efi.img Right. Of course it is odd to use ISOLINUX related xorriso commands with pure GRUB2 boot equipment. Especially since Vladimir Serbinenko puts much emphasis on a neat partition table. Let's try an option which was introduced for grub-mkrescue xorriso -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -efi-boot-part --efi-boot-image \ -e boot/grub/efi.img -no-emul-boot \ /mnt/iso Added options: -efi-boot-part with special argument --efi-boot-image marks the first EFI El Torito boot image as partition in GPT. Only a protective MBR emerges, which complies to GPT specs. (Other than a multi-partition MBR.) Woo. :-) This yields a more conventional partition layout. The range of the ISO filesystem is protected by the MBR partition and by three GPT partitions, of which the middle one points to the EFI boot filesystem in /boot/grub/efi.img. Only two boot entry points are provided: El Torito and GPT. El Torito catalog : 1024 1 El Torito cat path : /boot.catalog
Re: arm64 and isohybrid
Hi, Steve McIntyre: I'm also *way* overdue on switching all of debian-cd over to using xorriso and using native xorriso options totally rather than the -as-mkisofs stuff equivalents. But that's a topic for another day... You will be a trailblazer. Nobody else does this, except me, when testing the new feature to generate commands from the analyzed boot equipment of ISOs. The -as mkisofs command is an offcial part of xorriso. You may well stay with it as long as there are no demands which cannot be fulfilled with its option interface. (E.g. it is not very suitable for multi-session and allows few file manipulations inside the ISO.) One may question the beauty of -boot_image any efi_boot_part=--efi-boot-image -boot_image any cat_path='/boot.catalog' -boot_image any efi_path='/boot/grub/efi.img' relative to -efi-boot-part --efi-boot-image -c '/boot.catalog' -e '/boot/grub/efi.img' -no-emul-boot I had few clue of boot equipment when designing the -boot_image command. It is flexible enough to keep up with new demands. But it is far from being clear. The first parameter, which was intended to distinguish boot loaders, is mostly wasted. Actually i could need a new straighforward language to describe El Torito and the System Area. As said, i am working on a feature to tell commands from ISOs. There are still problems with commands which take as input data from outside the ISO filesystem. E.g.: -isohybrid-mbr or -append_partition. When this feature is completed, then it will be halfways usable as translator from -as mkisofs options to -boot_image commands. Just inquire some ISO that was produced by xorriso -as mkisofs. E.g. an amd64-netinst will yield: -boot_image isolinux system_area=...what.path.to.use.here.?... -boot_image isolinux partition_table=on -boot_image any partition_cyl_align=on -boot_image any partition_offset=0 -boot_image any partition_hd_cyl=64 -boot_image any partition_sec_hd=32 -boot_image any apm_block_size=2048 -boot_image any cat_path='/isolinux/boot.cat' -boot_image isolinux bin_path='/isolinux/isolinux.bin' -boot_image any platform_id=0x00 -boot_image any emul_type=no_emulation -boot_image any load_size=2048 -boot_image any boot_info_table=on -boot_image any next -boot_image any efi_path='/boot/grub/efi.img' -boot_image any platform_id=0xef -boot_image any emul_type=no_emulation -boot_image any load_size=458752 -boot_image isolinux partition_entry=gpt_basdat -boot_image isolinux partition_entry=apm_hfsplus This will still not be a no-brainer. One has to check each command whether one wants to fixely set its parameter or rather depend on xorriso defaults. E.g. the load_size=458752 is actually the size of efi.img and thus variable. So one better omits that command and lets xorriso use the data file size. On the other hand load_size=2048 is an important fixed parameter for ISOLINUX BIOS boot images. It corresponds to -as mkisofs -boot-load-size 4. (Ceterum censio partition_entry=apm_hfsplus is not appropriatum and esse delendam.) 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/21062543810235799...@scdbackup.webframe.org
Re: arm64 and isohybrid
Hi, i wonder why my mail of Thu, 29 Jan 2015 08:14:08 +0100 does not show up in debian-cd mailing list. It reported about a preliminary experiment with amd64 mini.iso. Meanwhile it is quite outdated by my new experiments with an arm64 ISO. - I downloaded http://cloudfront.debian.net/cdimage/jessie_di_beta_2/arm64/iso-cd/debian-jessie-DI-b2-arm64-netinst.iso of 2014-10-03. Inspection yields: Volume id: 'Debian jessie-DI-b2 arm64 1' El Torito catalog : 832 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 UEFI y none 0x 0x00768 833 El Torito img path : 1 /boot/grub/efi.img xorriso : NOTE : No System Area was loaded This looks like amd64 mini.iso without the BIOS stuff. After reading its /.disk/mkisofs, i re-pack it by # A dummy MBR template as substitute for isohdpfx.bin dd if=/dev/zero bs=432 count=1 of=null.mbr mount -o loop debian-jessie-DI-b2-arm64-netinst.iso /mnt/iso xorriso -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -isohybrid-mbr null.mbr \ -e boot/grub/efi.img -no-emul-boot -isohybrid-gpt-basdat \ /mnt/iso Omitted options: all Jigdo options -eltorito-alt-boot is a separator which is needed only if already a boot image was defined by -b, -e, or alike Added options: -isohybrid-gpt-basdat works only if -isohybrid-mbr is present -isohybrid-mbr gets as input the dummy MBR template. So SYSLINUX is not needed. The result shows nested partitions in MBR and GPT. This is the mjg layout, which partition editors dislike heavily but seems to work well in the amd64 netinst ISOs. It offers three entry points for booting: El Torito, MBR, GPT. El Torito catalog : 832 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 UEFI y none 0x 0x00768 833 El Torito img path : 1 /boot/grub/efi.img System area options: 0x0900 System area summary: MBR cyl-align-on GPT ISO image size/512 : 262144 Partition offset : 0 MBR heads per cyl : 64 MBR secs per head : 32 MBR partition table: N Status TypeStart Blocks MBR partition : 1 0x80 0x000 262144 MBR partition : 2 0x00 0xef 3332 768 MBR partition path : 2 /boot/grub/efi.img GPT: N Info GPT disk GUID : 8822d6a0aadcde40a8afcd569dc28802 GPT entry array: 2 248 overlapping GPT lba range : 64 262080 262143 GPT partition name : 1 490053004f00480079006200720069006400 GPT partname local : 1 ISOHybrid GPT partition GUID : 1 8822d6a0aadcde40a8adcd569dc28802 GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 1 0x1001 GPT start and size : 1 0 262080 GPT partition name : 2 490053004f004800790062007200690064003100 GPT partname local : 2 ISOHybrid1 GPT partition GUID : 2 8822d6a0aadcde40a8accd569dc28802 GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7 GPT partition flags: 2 0x1001 GPT start and size : 2 3332 768 GPT partition path : 2 /boot/grub/efi.img Of course it is odd to use ISOLINUX related xorriso commands with pure GRUB2 boot equipment. Especially since Vladimir Serbinenko puts much emphasis on a neat partition table. Let's try an option which was introduced for grub-mkrescue xorriso -as mkisofs \ -V 'Debian jessie-DI-b2 arm64 1' \ -r -o test.iso -J -joliet-long -cache-inodes \ -efi-boot-part --efi-boot-image \ -e boot/grub/efi.img -no-emul-boot \ /mnt/iso Added options: -efi-boot-part with special argument --efi-boot-image marks the first EFI El Torito boot image as partition in GPT. Only a protective MBR emerges, which complies to GPT specs. (Other than a multi-partition MBR.) This yields a more conventional partition layout. The range of the ISO filesystem is protected by the MBR partition and by three GPT partitions, of which the middle one points to the EFI boot filesystem in /boot/grub/efi.img. Only two boot entry points are provided: El Torito and GPT. El Torito catalog : 1024 1 El Torito cat path : /boot.catalog El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 UEFI y none 0x 0x00768 831 El Torito img path : 1 /boot/grub/efi.img System area options: 0x0201 System area summary: MBR protective-msdos-label
arm64 and isohybrid
Hi folks, I've been playing with the arm64 netinst build a little today, when installing a new machine. We *hadn't* been making them isohybrid thus far, and therefore when I simply dumped one onto a USB stick using dd it didn't work wonderfully. Due to the UEFI firmware being reasonably intelligent, I could boot the installer off the USB stick. But later on d-i failed to find and mount the cdrom so it bailed out - AFAICS this is because there weren't any partitions on the media. So... Next, I tried to add some xorriso isohybrid options to the build, starting with -isohybrid-gpt-basdat but that didn't have any noticeable effect on my build. (I don't know if that's expected!). Next, I bit my tongue and copied more of the amd64 build, using bits of syslinux to add: -isohybrid-mbr syslinux/usr/lib/syslinux/isohdpfx.bin and that makes a big difference - I then ended up with the normal-looking 2-partition image and d-i awas happy with this. So... Much as this image seems to work for me, it's bloody silly to be using bits out of syslinux for an arm64 image! Thomas: what exactly does xorriso need out of isohdpfx.bin to be able to make a *non* x86 bootable MBR etc. please? I'm *guessing* we just need a basic MBR-ony boot sector that xorriso can modify with a partition table, but I don't really know this area all that well. Can you give me some clues please? :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com C++ ate my sanity -- Jon Rabone -- 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/20150128230426.gi20...@einval.com
