From mboxrd@z Thu Jan 1 00:00:00 1970 From: "pelzflorian (Florian Pelz)" Subject: Re: ISO installer image: GPT versus MBR partitions Date: Sun, 21 Apr 2019 13:10:12 +0200 Message-ID: <20190421111012.llwafpzqutueuge3@pelzflorian.localdomain> References: <20190421075847.ka4aeseg6kgfufz4@pelzflorian.localdomain> <452567273172162940@scdbackup.webframe.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:38131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIAMV-0003IA-FX for guix-devel@gnu.org; Sun, 21 Apr 2019 07:10:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hIAMU-0008Rk-Hx for guix-devel@gnu.org; Sun, 21 Apr 2019 07:10:19 -0400 Content-Disposition: inline In-Reply-To: <452567273172162940@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 On Sun, Apr 21, 2019 at 11:35:49AM +0200, Thomas Schmitt wrote: > Ok, now for the last experiment. Just for curiosity, as i believe it > is not a good solution (and mformat -k isn't either): > Does start LBA 1 of partition 1 prevent the endless loop, too ? >=20 > So please write to byte 446 (dec) to 461 (dec) of the FAT image: >=20 > 80 00 02 00 01 01 12 4f 01 00 00 00 3f 0b 00 00 >=20 > In the FAT image treated by the "dd" above, these bytes are all 00. > In the original FAT image they are: >=20 > 80 00 01 00 01 01 12 4f 00 00 00 00 40 0b 00 00 > =3D=3D =3D=3D =3D=3D =3D=3D >=20 Why is 0b underlined? OK, so I just wrote the Guix git master with ludo=E2=80=99s reproducibili= ty patches to a USB drive (boot gets stuck again) and then did: sudo dd if=3D/dev/sdc2 of=3Dmysdc2.img When I open it with ghex, I find at position 446: 80 00 00 04 01 24 4f 00 00 00 00 80 16 00 00 00 Strange. I write the guixsd-install-0.16.0.x86_64-linux.iso to /dev/sdc (boot gets stuck) and repeat sudo dd if=3D/dev/sdc2 of=3Dmysdc2.img I find: 80 00 01 00 01 01 12 4f 00 00 00 00 40 0b 00 00 This matches what you wrote. I change it to 80 00 02 00 01 01 12 4f 01 00 00 00 3f 0b 00 00 I dd the changed mysdc2.img back to /dev/sdc2. Now it boots. :) Strangely, I now have only one entry =E2=80=9CGRUB 2.02= =E2=80=9D in the boot selection, but =E2=80=9CEFI Boot=E2=80=9D (or what it was called= ) is gone. > Nevertheless, start LBA 1 is less desirable than no partition table > entry at all, because LBA 1 causes a partition that is not mountable. > So an option for mformat would be of interest, which writes an MBR > (other than with -k) but does not create a partition entry. >=20 This raises the question what should be done in Guix. Is it a good idea to add -k to mformat in grub-mkrescue for the upcoming Guix 1.0 release (even though you don=E2=80=99t like it)? Could it break install = on other machines? Or should mformat be patched instead? Could any of this be upstreamed? What about your MBR repacking? I=E2=80=99m sure Lud= o has an opinion on these things too. I just doing what I=E2=80=99m told, but = I don=E2=80=99t quite understand what I=E2=80=99m doing here. Regards, Florian