Hi, thanks a lot for the background info.
Alain Knaff wrote: > A platform that expects the disk to be unpartitioned would just ignore > this mini partition table. The EFI platform encounters the mformat-produced image in a partition. Nearly all implementations indeed ignore the MBR-ish table in the partition. But one wanted to be smart, obviously. (The disk device, a USB stick, was partitioned by GPT.) If you see any other potential problem with using a mformat image as content of a partition, then please tell. > In the next release I'll provide a new option to just skip this > partition table [...] > > If all goes well, I expect to make this new release by the end of the month Good move. ------------------------------------------------------------------------ I assume that grub-mkrescue will have to wait a while before it can unconditionally use a new option of mformat, or that it will need a function like check_xorriso() http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkrescue.c#n316 which is used to look for a five year old option in the help text of xorriso: http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkrescue.c#n608 The three alternatives for grub-mkrescue now look like this: > > - Keep the partition entry because its removal could break some other > > EFI firmware's boot process. No objections are known yet against partition table removal. Its purpose has nothing to do with the use case as EFI System Partition. I am out of ideas whom else to ask for an opinion. So i think grub-mkrescue should dare to choose one of the other two: > > - Overwrite the partition table in bytes 446 to 509 of the mformat result > > by zeros before populating it with files. If i am not mistaken, then this is equivalent to the new option of mformat. grub-mkrescue could anticipate this option by own postprocessing after the mformat run. > > - Use mformat option -k to avoid production of the partition table. Alain Knaff wrote about the new option probably in contrast to -k: > [...] but still initialize the other fields (jump at > beginning of boot sector, mformat "banner", 0xaa55 boot signature, > physdrive, mtools boot code, zeroing out unused bytes) None of the items in this list looks like it would be necessary for a partition image which gets created as new file. I assume that no non-zero bytes can sneak in, if the image file does not exist before it gets written by mformat. Have a nice day :) Thomas _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel