Hi, i wrote: > > So i propose the change as fine tuning of the original developer's > > intention. (Vladimir will correct me if i'm wrong.)
Daniel Kiper wrote: > After some thinking I have an itching to add the "-k" option to the > mformat. I am not courageous enough to go that far. > So, I would suggest to make this as a known issue and fix > it after the release. Does it make sense? Sure. There is a workaround, after all. > > https://savannah.gnu.org/users/alainknaff > > Maybe he still can remember why he added the partition entry. > Could you ask him about that? Please keep grub-devel in the loop. Will do. > > I was not happy with Vladimir's decision to use GPT instead of MBR partition > > table. (Because of non-mountable partitions and the GPT backup, which needs > > to be relocated after copying the ISO onto USB stick.) > I am not sure I understand. Which GPT do you refer to? The GPT in the grub-mkrescue ISO, which xorriso creates according to the options sent from grub-mkrescue. An ISO made by grub-mkrescue on Debian with "i386-efi", "i386-pc", and "x86_64-efi" in /usr/lib/grub gets this partition table $ /sbin/fdisk -l output.iso ... Disklabel type: gpt Disk identifier: 8E0B9F07-AB1F-4B0B-BA12-764F83FF76EC Device Start End Sectors Size Type output.iso1 64 339 276 138K Microsoft basic data output.iso2 340 6099 5760 2.8M EFI System output.iso3 6100 34131 28032 13.7M Apple HFS/HFS+ output.iso4 34132 34731 600 300K Microsoft basic data Partitions 1 and 4 are fillers. Not mountable. Whether partition 3 is mountable depends on the kernel's capability to work with HFS+ block size 2048. It is supposed show a HFS+ version of the ISO's file tree. But i am not sure whether this was ever challanged. The ISO is only mountable via the base device (start 0). The fillers are necessary because the EFI partition image is a file inside the ISO filesystem. Number 1 protects vital parts of the ISO from being claimed by user-made partitions. Number 4 protects cargo cult padding to prevent the TAO CD Linux read-ahead bug caused by ambiguous specs for SCSI command READ CAPACITY ... whew, without breathing. I prefer this layout Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type output.iso1 * 64 28695 28632 14M 83 Linux output.iso2 28696 34455 5760 2.8M ef EFI (FAT-12/16/32) It gets achieved by export MKRESCUE_SED_MODE=mbr_hfs grub-mkrescue --xorriso=./grub-mkrescue-sed.sh -o output.iso minimal \ -partition_offset 16 -iso_mbr_part_type 0x83 where "minimal" is a dummy directory with a dummy file. The pseudo-xorriso moves the EFI image out of the GRUB-prepared tree (e.g. /tmp/grub.Q98DOe) and replaces the xorrisofs options for EFI-in-ISO and GPT by options for EFI-appended and MBR partition table. The options in the second line get forwarded by grub-mkrescue as xorrisofs options. Partition 1 is mountable as ISO 9660 filesystem. This run produces HFS+ and Apple Partition Map. The HFS+ range is not represented in the MBR partition table, because it is inside the ISO range. ---------------------------------------------------------------------- History and motivation: Back in 2012, xorriso offered no way to put an El Torito image outside the ISO filesystem's range. So the choice was to have two EFI images or to have the EFI partition inside the ISO's data file range. I am not aware how much Vladimir considered the duplication. His wishes were for the EFI partition inside the ISO. Since a while, xorriso can point by an El Torito catalog entry to an appended partition. So the EFI image can be stored outside the ISO's claimed range and a mountable ISO partition does not have to overlap with the EFI partition. There remains the problem that tools inquire the ISO's claimed size to determine the size of the overall ISO+EFI image, but the partition's filesystem must not claim more than the partition's size. Other tools hate the start LBA 0 of the mountable ISO partition. Both can be solved at the cost of a second ISO superblock and directory tree which match a partition start at 64 * 512 bytes. That's the job of -partition_offset 16 It creates an ISO superblock for the whole device, which claims the whole ISO+EFI image as its range. The second superblock claims only the ISO partition as its range. We had an example of an EFI implementation, which hated any MBR partition table type except 0x00 and 0xef. So grub-mkrescue-sed.sh uses type 0x00 by default. Nevertheless, for the purpose of grub-mkrescue plus data partition on a USB stick, it is better to have a non-zero MBR partition type. So my above example uses -iso_mbr_part_type 0x83 ---------------------------------------------------------------------- Have a nice day :) Thomas _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
