Hi Thomas, On Thu, 25 Apr 2019 18:22:11 +0200 "Thomas Schmitt" wrote: > Then do if you can make use of those two git commits. > They are the only ones to that file since release 1.5.0. Okay, I've picked them up. > > I'm not sure about amending "guix system disk-image" by options that > > aren't really end user options, but I guess it can't be helped. > > How about > > --file-system-type=iso9660[_$variation] > > with $variation being "gpt_hfs" (= "original"), "mbr_hfs", "mbr_only", > and "gpt_appended", defaulting to "gpt_hfs" ? I'm not sure yet. We have a lot of special-casing for iso9660 already. If anything, at that point, we could pass an arbitrary list of options or something (an "environment" if you will. Hah). > This translates quite straightforward to the proposed variations of > grub-mkrescue-sed.sh in > http://lists.gnu.org/archive/html/guix-devel/2019-04/msg00420.html > > The partition offset 16 and MBR partition type 0x83 would be ordered > only with "mbr_*" variations. > > The setting > export MKRESCUE_SED_IN_EFI_NO_PT=yes > should be used unconditionally. It gets applied to the EFI partition > block 0, only if it is marked with an MBR signature 55 aa. Then we may > safely assume that bytes 446 to 509 are MBR partition table, which is > of no use and maybe harmfull. Only then they get zeroed. Okay, that makes sense. > If the Guix download servers can afford two more ISOs, how about offering > "gpt_hfs" and "mbr_hfs" ISOs with the explanation that both should work > for booting and installing, but that "mbr_hfs" is more convenient when > the remaining capacity of a Guix ISO USB stick shall be used as partition > for a read-write filesystem. > (Moving the backup GPT is an expert option in fdisk. But without moving > it there is no room for a new partition.) I don't know these things. But someone on the list will know. > On the long run and if no negative results arise, i propose to switch the > default to "mbr_hfs". Yeah, I agree. > I tried hard to keep it conservative and am open for proposals to > make it more portable to older shells. The problem is that there were horrible security problems in bash and that made a lot of distributions switch to a more minimal shell ("dash") for scripts. I agree that that was a good move, but error handling is even worse there. > > But then grub-mkrescue will invoke > > grub-mkrescue-sed.sh at runtime, and who knows what the latter will pick up > > as the sed to use? > > grub-mkrescue runs the mformat program and the mcopy program before > it runs xorriso. Yeah, we patch grub-mkrescue to use an absolute path for mformat and mcopy in order to make them predictable. > > For example in grub-mkrescue-sed.sh there's no "-e" in the shebang > > Is it conservative enough to add it ? It will exit the shell when one of the toplevel commands has an exit status != 0. So as long as your script doesn't have toplevel commands return error status in normal operation it should be fine. Toplevel: $ grep foo bar Not toplevel: $ if grep foo bar (that won't fail the script even with "-e") Questionable: $ foo | bar If foo fails, should the script fail? Spoiler: It won't fail the script even with "-e". If bar fails, should the script fail? Spoiler: It will fail the script with "-e". But: $ set -e $ set -o pipefail $ foo | bar Now if foo or bar fails, the script will fail. > > Guile, on the other hand, will just fail the script on error (usually). > > That's why i brought a Guile re-write into consideration. > Firstly it would be the language of choice and secondly it would make > Guix independent of my ideas how it should be done. We're not trying to become iso bootloader experts ourselves :) >As said, the > script-in-the-middle gives substantial control over the stage of > grub-mkrescue when the prepared files are still not packed up in the ISO. > > (Or maybe it's time to re-write the script in C ... as was done with > grub-mkrescue when it became too complicated.) Yeah, we'll see. For now, let's try the shell script and make it more paranoid.