From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: ISO installer image: GPT versus MBR partitions Date: Thu, 25 Apr 2019 19:55:21 +0200 Message-ID: <20190425195521.4dd1ef5e@scratchpost.org> References: <20190425165949.57fd4eba@scratchpost.org> <198856777051031048477@scdbackup.webframe.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/FvLM=Nyr8P__C4zBwHXto6j"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:40997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJiat-00085D-94 for guix-devel@gnu.org; Thu, 25 Apr 2019 13:55:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJiar-0003dD-Tg for guix-devel@gnu.org; Thu, 25 Apr 2019 13:55:35 -0400 In-Reply-To: <198856777051031048477@scdbackup.webframe.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Thomas Schmitt Cc: bug-xorriso@gnu.org, guix-devel@gnu.org --Sig_/FvLM=Nyr8P__C4zBwHXto6j Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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. =20 >=20 > How about >=20 > --file-system-type=3Diso9660[_$variation] >=20 > with $variation being "gpt_hfs" (=3D "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 >=20 > The partition offset 16 and MBR partition type 0x83 would be ordered > only with "mbr_*" variations. >=20 > The setting > export MKRESCUE_SED_IN_EFI_NO_PT=3Dyes > 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 pic= k up > > as the sed to use? =20 >=20 > 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 =20 >=20 > Is it conservative enough to add it ? It will exit the shell when one of the toplevel commands has an exit status !=3D 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 ev= en with "-e". If bar fails, should the script fail? Spoiler: It will fail the script wit= h "-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).= =20 >=20 > 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.=20 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. >=20 > (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. --Sig_/FvLM=Nyr8P__C4zBwHXto6j Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzB9IkACgkQ5xo1VCww uqVBBAf7BnIP9Gt54ONblJ4KTLGfuorBnbbHBb2omNKx/O/WuXZ4H1BMm5KZWzmI ySCrjoblbwwFEoA3fMfGDIZdsTaRaHtIE2UhVMdk/STHg8IjNxoREjymKU0QACPM zUjCK7N+MkBr4q5tHlE7juwZFnIaDTMWZls8zDMji578dhlJGiS4Mj3yAwwsAh70 enWsmJknGd1KM4mZ+n9Jykm62vyFstw7YzRbE3DvgozGIlCUD+ajwZ/OTFqrucfl fBTC/CVfCaRkaeOyDNXpHLMytaS6c9LINuk22gODY45yeBIPo7CYnsft81JUIyYv lvkI/edbGHBeqe2SwNbQlfKbikR+pQ== =PFQM -----END PGP SIGNATURE----- --Sig_/FvLM=Nyr8P__C4zBwHXto6j--