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 16:59:49 +0200 Message-ID: <20190425165949.57fd4eba@scratchpost.org> References: <20190425094537.3t2e6vkamq7d46fy@pelzflorian.localdomain> <20531677679849119589@scdbackup.webframe.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/3Chq8bixbQxZvhPIMZBvVL8"; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:58236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJfqy-0001iy-U9 for guix-devel@gnu.org; Thu, 25 Apr 2019 11:00:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJfqx-0001gU-Aq for guix-devel@gnu.org; Thu, 25 Apr 2019 11:00:00 -0400 In-Reply-To: <20531677679849119589@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_/3Chq8bixbQxZvhPIMZBvVL8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > How comfortable is the Guix patching system ? :)) Very comfortable. But we'd like not to diverge from upstream too much. We are all in this together, so I'd like upstream to eventually converge on a solution. I'm fine with carrying a patch if it's coordinated by people w= ith knowledge about the matter at hand. For multiple projects, we already carry patches while they are being actively reviewed upstream in order to fix bug= s. If the problem is not too bad, I'd like the change to take the normal path instead of us interfering with upstream. But here, you *are* upstream so it's really up to you whether we should patch xorriso or not. As for people testing possible avenues by patches in Guix, that's easy to d= o. > This is quite contrary to the expectations of partition editors, though. > I deem this EFI's behavior a much clearer bug than the Macbook EFI's. > So i stay with my proposal of native xorriso command > -boot_image any iso_mbr_part_type=3D0x83 > or mkisofs emulation option > -iso_mbr_part_type 0x83 >=20 > (To my knowledge, the Guix xorriso run switches from mkisofs emulation > to native commands by "--". So -boot_image would be the one to use > if it gets appended to the other arguments.) >=20 >=20 > > Add an option to =E2=80=9Cguix system disk-image=E2=80=9D to select whi= ch > > grub-mkrescue-sed.sh environment variables to enable? =20 >=20 > This would be great. Since grub-mkrescue-sed.sh is part of xorriso, it's easy to get it to where it needs to be (gnu/build/vm.scm) from where xorriso is refererred to (gnu/system/vm.scm). (Just pass the package as argument) I can do that part. The patches would then go into the xorriso package definition we carry (gnu/packages/cdrom.scm) and modify grub-mkrescue-sed.sh in its output (the patching part would require no Guile knowledge, they are just ".patch" files we distribute and automatically apply). 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. Basically they would just be something that we'd tell users which have problems booting the Guix iso to use. Even that is a lot to ask from normal users--building a new installer ISO for the sake of installing Guix. > (I was brought up with HP BASIC and never was able to solve the Lisp > puzzles in german magazine Bild der Wissenschaft of the 1980s. > So i cannot help much with translating the usage gestures or even > the script itself from shell to Guile.) Oh, I see. It's fine if it's in a shell script. We aren't opposed to shell scripts--sometimes (in initrd etc) we already ha= ve Guile there and don't want to bloat the image by shells and shell utils. But in this case, we would be patching the iso generator which requires a lot of the system anyway, so who cares if we pull in the shell and 20 small utils? Also, we try very hard to keep packages modular. But if no care is taken, shell scripts take stuff from the global environme= nt and thus are very difficult to predict and isolate for modularity. Think of what happens when someone replaces the "test" binary in $PATH, or "sed". It will unintentionally potentially completely change the output depending on what the user has installed (it's definitely not what the user intended to happen). As a first countermeasure, we build inside isolated build containers, which makes the problem less bad. 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? (For that matter, think of what happens when another xorriso is somewhere in $PATH and we use --xorriso=3D.../grub-mkrescue-sed.sh). (I see that you already take care to use a "closer" xorriso--but these kind of problems pop up in shell scripts for almost every term used in there. It's kinda difficult to get them to behave) What's more, shell scripts don't fail on error. For example in grub-mkrescue-sed.sh there's no "-e" in the shebang, which means that if some command in there has an error, the shell will happily continue anyway. I'm not blaming you, that's just the culture with shell scripts. Even with "-e", if a command in a pipeline fails, it will sometimes still not fail the shell script. For that, you need "set -o pipefail" which is a bash feature and not necessarily available on other shells (dash etc). Guile, on the other hand, will just fail the script on error (usually). --Sig_/3Chq8bixbQxZvhPIMZBvVL8 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzBy2UACgkQ5xo1VCww uqWmUAf9H6ImySi+4OrcKoTZjQWuFQbi1hkUxEsKlHDK4Cnof+23Lv8uRBPXosyy fmUYjtf5fslGMmx9sFuiqFwvveI+N9fS0s4gepuAE/I+nLN6gdvzwFp6QzZVqmY6 kOtvWr8mICDPtYZe7yY4iOeZxEtiH3hn84IIaRoH8PCumC8kQpSlals8c1PNpARI C9LNTtN3JS1vKzTY4JOsDhw8e88bF6PdrHC0w7dInhezQx7YbmCfET4HUTBgE/4o 5IzEDdHvAONyD6Rn+/i9kujTS6F2uDz4aI3E7osW3TKLR2493H1+G2HN06hE8jC5 M1JmO/HJE9uX5s+hjMni0Gu2AHjj6A== =l4a7 -----END PGP SIGNATURE----- --Sig_/3Chq8bixbQxZvhPIMZBvVL8--