[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Several GNU projects wondering about the reason for mformat partitio
Re: Several GNU projects wondering about the reason for mformat partition table
Sun, 02 Jun 2019 20:34:05 +0200
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
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()
which is used to look for a five year old option in the help text of xorriso:
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
> > - 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 :)