Hi, i wrote: > > ... 3f 0b > > ... 40 0b > > ... == ==
Florian Pelz wrote: > Why is 0b underlined? Too much enthusiasm on my side. > OK, so I just wrote the Guix git master with ludo’s reproducibility > patches to a USB drive (boot gets stuck again) and then did: > sudo dd if=/dev/sdc2 of=mysdc2.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 = 2,147,483,648. Block count is 0x16 = 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 = 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 “GRUB 2.02” in > the boot selection, but “EFI Boot” (or what it was called) 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’t 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’m told, but I > don’t quite understand what I’m 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/boot_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
