Re: A thread on grub-bug could need attention

[Thomas Schmitt]

Hi,

Michel Bouissou wrote:
> I would assume that I need to create a "minimal" directory with a
> "dummy" file inside like previously ?

Yes.
The experiment can well wait until you are back from travel.


> However, I don't have any "grub-mkrescue-sed.sh" file 

Get it from 
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/frontend/grub-mkrescue-sed.sh

It belongs to the upstream sources of xorriso, where i am developer.
The GNU xorriso tarball has it as demo in its ./frontend directory.
You can trust its good intentions as much as the ones of xorriso.
File operations only affect the grub-mkrescue temporary directory and
the /tmp directory. Files get moved, not deleted.
(The practical consequences of running it are subject to the usual
 risk of bugs, i fear.)

It works with xorriso-1.4.4 or newer. Best with current release 1.4.8.

If your installed xorriso tells an older revision when run without any
arguments, then consider to get xorriso and grub-mkrescue-sed.sh by the
tarball at
  https://www.gnu.org/software/xorriso/#download
This xorriso needs no installation but only a place where to unpack
and compile
  tar xzf xorriso-1.4.8.tar.gz
  cd xorriso-1.4.8
  ./configure && make
If you run its fellow ./frontend/grub-mkrescue-sed.sh then it will make
use of the compiled binary ./xorriso/xorriso.
Existing installed xorriso and its libraries will not be affected.

----------------------------------------------------------------------------
Lengthy motivation:

The purpose of grub-mkrescue-sed.sh is to modify the xorriso run underneath
grub-mkrescue to get other partition layouts.

The native layout as defined by Vladimir Serbinenko and implemented by me
obviously works fine. Its main disadvantage is that it shows at least
two not mountable GPT partitions (e.g. /dev/sdc1 and /dev/sdc4).
The ISO 9660 filesystem can only be mounted by the base device /dev/sdc.

GPT has the further disadvantage that it prescribes to have a backup
partition table at the end of the storage device. But when bootable ISOs
are made, it is not yet known how large the device will be. And even if so,
one would have to pad up the image to write that backup GPT.
So any ISO copied onto USB stick has its backup GPT at the wrong place
and any remnant backup GPT at the correct position would be in conflict
with the main GPT at image start.

The MBR partition table doesn't refer to the device end. UEFI specifies
that a MBR partition of type 0xEF shall be regarded as EFI System
Partition.

By some extra measures, the default mode of grub-mkrescue-sed.sh achieves
that all partitions are mountable and that no nested partitions emerge.
This partition table is fully acceptable to MBR partition editors like
fdisk which can then be used to add partitions and so give the rest of
the USB stick a life.
Because of the 64 block gap before partition 1, it is even possible to
install a new boot loader and use the ISO as read-only data partition
rather than as home of the operating system.

The same measures can help to make GPT with mountable ISO partition
(see description of "gpt_appended" in the script). But the problem of
misplaced backup GPT cannot be solved at the time when the ISO gets
produced.

Most modes avoid HFS+ partition and Apple Partition Map. Partition editors
and operating systems do not expect APM to be combined with MBR or GPT
by some hot x86 machine code stunt and an unusual APM block size. 


Have a nice day :)

Thomas