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.
