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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel