From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas Schmitt" Subject: Re: ISO installer image: GPT versus MBR partitions Date: Sun, 21 Apr 2019 14:27:10 +0200 Message-ID: <36026727461461023450@scdbackup.webframe.org> References: <20190421115606.7mi6rrawp2spziev@pelzflorian.localdomain> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:48486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIBWj-0004g1-VK for guix-devel@gnu.org; Sun, 21 Apr 2019 08:24:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hIBWi-0005bR-JR for guix-devel@gnu.org; Sun, 21 Apr 2019 08:24:57 -0400 In-Reply-To: <20190421115606.7mi6rrawp2spziev@pelzflorian.localdomain> 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: bug-xorriso@gnu.org Cc: guix-devel@gnu.org Hi, i wrote: > > ... 3f 0b > > ... 40 0b > > ... =3D=3D =3D=3D Florian Pelz wrote: > Why is 0b underlined? Too much enthusiasm on my side. > OK, so I just wrote the Guix git master with ludo=E2=80=99s reproducibil= ity > 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 Pinching eyes ... Bootable flag is set. Start C/H/S is 4/0/0. (x/y/1 is usual) Partition type is 1. End C/H/S is 1/36/15. Start LBA is 0x80000000 =3D 2,147,483,648. Block count is 0x16 =3D 22. So what ever did you do to this mysdc2.img ? > 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. :) Start C/H/S is 0/0/2. Partition type is 1. End C/H/S ... i'm getting too old for decoding MBR C/H/S bit fields. Start LBA is 1. Block count is 0x0b3f =3D 2879. So Start LBA 0 is indeed the trigger of the problem. As soon as the partition entry does not point to its hosting block any more, the (now very probable) loop in EFI cannot happen. > 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 calle= d) is gone. What do you see if the partition entry is zeroized entirely ? (Elsewise i refer to the Futurama quote in my previous mail.) > 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)? We need to ask at grub-devel. I have begun to compose a mail. You will be Cc-ed. Does guix-devel want to be Cc-ed ? New mail: > MacBook Pro (13-inch, Mid 2010) > Model Name: MacBook Pro > Model Identifier: MacBookPro7,1 > Boot ROM Version: MBP71.003F.B00 > SMC Version (system): 1.62f7 I will put this into my mail to grub-devel. > Serial Number ... ... but this only if asked for. Back to old mail: > Or should mformat be patched instead? Could any of > this be upstreamed? That's why i asked Ludovic about our chances with mtools upstream. I would propose an option to write the usual pseudo-MBR but without that partition entry. (Well, maybe somebody there can even remember why a partition entry is made by default.) > What about your MBR repacking? I will create an option for zeroizing bytes 446 to 461 of the EFI image. When the dust has settled here, i will ask Ludovic for preparing the ISO production code for a run with libisoburn's wrapper script frontend/grub-mkrescue-sed.sh for MBR-only. At that occasion, the EFI image repairer could be tested, too. The script has a mode "original" which does not change the xorriso options submitted by grub-mkrescue. So it produces original GPT. (It's original purpose is spying on grub-mkrescue's xorriso options.) > I just doing what I=E2=80=99m told, but I > don=E2=80=99t quite understand what I=E2=80=99m doing here. We had a wild ride over boot sectors and partition tables. I collect my knowledge in libisofs file doc/boot_sectors.txt . At days when our web certificates are valid, it is available at https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/boot_sectors.= txt Hah. Bug #4. No doc/boot_sectors.txt in libisofs tarball. But it is in GNU xorriso's tarball: https://fossies.org/linux/misc/xorriso-1.5.1.tar.gz/xorriso-1.5.1/doc/bo= ot_sectors.txt For completeness, a reserve address for my grub-mkrescue-xorriso wrapper: https://sources.debian.org/src/libisoburn/1.5.0-1/frontend/grub-mkrescue= -sed.sh Have a nice day :) Thomas