Re: [Bug-xorriso] ISO installer image: GPT versus MBR partitions

[Danny Milosavljevic]

Hi Thomas,

On Thu, 25 Apr 2019 18:22:11 +0200
"Thomas Schmitt" <address@hidden> 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.

pgplXty1LPqs0.pgp
Description: OpenPGP digital signature