Hi,
i wrote:
> > I [...] wonder what mkisofs option -q might be supposed to do
René Rebe wrote:
> I did not re-research it right now, but it is possible that a decade ago the
> option was only -q or something like that, …
I'd say it was never official.
Antique mkisofs-1.12b3 accepts -q, -qu, qui, -quie, and -quiet like
genisoimage. But it lists only -quiet in its help text.
It stems from the time when maintainership changed from Eric Youngdale to
Joerg Schilling. Obviously Joerg changed this swampy behavior ionly after
genisoimage was forked from mkisofs in summer 2006. So genisoimage
inherited it and still shows it.
> EFI Grub 2 T2 [...]
> The ISO glue still needs to be updated for grub2 support.
Let me dump some info for that.
Expect to create a xorrisofs command like this from grub-mkisofs:
xorriso -as mkisofs \
-graft-points \
--modification-date=2017042506244800 \
-b boot/grub/i386-pc/eltorito.img \
-no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info \
--grub2-mbr \
/usr/lib/grub/i386-pc/boot_hybrid.img \
-hfsplus \
-apm-block-size 2048 \
-hfsplus-file-creator-type chrp tbxj \
/System/Library/CoreServices/.disk_label \
-hfs-bless-by i /System/Library/CoreServices/boot.efi \
--efi-boot efi.img \
-efi-boot-part --efi-boot-image \
--protective-msdos-label \
-r \
--sort-weight 0 / \
--sort-weight 1 /boot \
-o output.iso \
/tmp/grub.MWf3hz \
./payload
grub-mkrescue created the local disk tree /tmp/grub.MWf3hz. It contains
the HFS+ specific file tree ./System, the EFI System Partition image
./efi.img, and other GRUB 2 files.
The xorrisofs options are in part traditional mkisofs and in part they were
especially created for GRUB 2. One may ask me about the bytes they yield,
but not so much about their meaning inside GRUB 2.
https://www.gnu.org/software/xorriso/man_1_xorrisofs.html
Above yields a GPT with no mountable partition that leads to the ISO
filesystem. Only the EFI partition is mountable. Further there is an
Apple Partition Map for the HFS+ Macs. The HFS+ filesystem is implemented
as additional superblock and directory tree which represent the
directories and files of the ISO.
I have a wrapper script for xorriso, which manipulates the options in a
way that two mountable MBR partitions emerge. One for the ISO and one
for the EFI partition.
https://dev.lovelyhq.com/libburnia/libisoburn/blob/master/frontend/grub-mkrescue-sed.sh
No GPT means no backup GPT, which sits at the end of the device.
Since the end of the image is hardly end of device, its backup GPT becomes
immediately dislocated when the image gets onto the USB stick.
With MBR there is no such problem.
Together with xorrisofs option -partition_offset 16 one gets a
conventional partitioning of the USB stick with a gap before partition 1.
This should please partition editors when the user wants to add more
partitions.
My MBR based layout does not care for HFS+ (i.e. pre-EFI) Macs. Not even
the developers of GRUB 2 could tell me which Apple models exactly that
would be.
The options for that look be no means less frankensteinish than those
which grub-mkrescue uses:
xorriso -as mkisofs \
-graft-points \
--modification-date=2017042506244800 \
-b boot/grub/i386-pc/eltorito.img \
-no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info \
--grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img \
-eltorito-alt-boot \
-e --interval:appended_partition_2:all:: \
-no-emul-boot \
-iso_mbr_part_type 0x00 \
-no-pad \
-append_partition 2 0xef /tmp/grub-mkrescue-sed-efi-img.23861 \
-r \
--sort-weight 0 / \
--sort-weight 1 /boot \
-o output.iso \
/tmp/grub.MWf3hz \
./payload \
-partition_offset 16
My wrapper moved ./efi.img out of the tree that gets copied into the ISO.
efi.img gets appended after the range of the ISO filesystem. Thus it makes
both ready for being in disjoint partitions. Option -e --interval:... lets
the El Torito catalog point to it with platform id 0xEF. MBR partition type
0xEF marks it as EFI System Partition for the case that it is presented on
USB stick.
Option -partition_offset 16 creates a second ISO superblock and directory
tree which match an MBR partition start of 64 blocks of 512 bytes.
In summary:
$ xorriso -indev output.iso -report_el_torito plain -report_system_area plain
...
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 2040
El Torito boot img : 2 UEFI y none 0x0000 0x00 5760 6043
El Torito img path : 1 /boot/grub/i386-pc/eltorito.img
El Torito img opts : 1 boot-info-table grub2-boot-info
...
ISO image size/512 : 29932
...
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x80 0x00 64 24108
MBR partition : 2 0x00 0xef 24172 5760
...
Note that the ISO superblock at offset 0 claims the whole image as its
realm. The ISO superblock in partition 1 claims only up to the end of
partition 1.
MBR partition type 0x00 is unusual, but there was a report on grub-devel
mailing list that some EFIs offer the device for booting only if there
is only one partition of non-zero type.
Some BIOSes on the other hand want to see the boot flag 0x80 in some
MBR partition or else they do not execute the x86 code of the MBR.
(Neither GRUB nor SYSLINUX MBRs interpret the boot flag. But if they
don't get started by the BIOS they cannot even ignore it.)
SuSE Linux uses a similar MBR based layout for its EFI capable ISOs.
Difference is that their EFI partition is number 1 and the ISO partition
is number 2 with a larger offset than mine.
And of course their BIOS equipment is ISOLINUX rather than GRUB.
Have a nice day :)
Thomas
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[email protected] with a subject of: unsubscribe t2
