On Mon, 22 Apr 2019, 01:42 Thomas Schmitt, <scdbac...@gmx.net> wrote:
> Hi, > > this is about how exactly to solve a diagnosed and worked-around problem. > > Guix is one of the few distros which make their installation ISOs by > help of grub-mkrescue. The EFI boot manager of an old Macbook got stuck > when such an ISO was presented on USB stick. I.e. it not only did not > boot the ISO but showed no other EFI partitions either. > > A Debian Live 9 ISO does not impose such a problem. > The same Guix ISO on DVD rather than USB stick works well, too. > > The owner of the machine is Florian Pelz (Cc'ed). He characterizes it as: > MacBook Pro (13-inch, Mid 2010) > MacOS Yosemite reports: > Model Name: MacBook Pro > Model Identifier: MacBookPro7,1 > Boot ROM Version: MBP71.003F.B00 > SMC Version (system): 1.62f7 > > During a longish bug hunt it turned out that the decisive difference > is the first block of the FAT filesystem image which Debian creates by > mkfs.fat whereas grub-mkrescue creates it by mformat. > > The mformat-made image has an MBR partition table entry which claims the > whole image as partition 1: > > Device Boot Start End Sectors Size Id Type > /mnt/iso/efi.img1 * 0 2879 2880 1.4M 1 FAT12 > > If this partition entry is zeroed, then the EFI boot manager works even > when the USB stick with this modified ISO is plugged in. > > Actually it suffices to change the start LBA from 0 to 1, so that the > partition does not start by the partition table. (I count this as proof > of an endless loop in EFI while it is exploring something like > extended partitions. Strange is that the main MBR partition 1 of the > Debian ISO points to that main MBR, too. So it seems to harm only in > sub partition tables. We repacked the Guix ISO to MBR rather than GPT. > Still stuck.) > > The EFI FAT image in Debian Live 9 has no partition table entry in block 0. > > Production of the partition entry can be suppressed by mformat option -k. > But then block 0 of the result is not marked as MBR and also causes > program "file" to give out a very sparse characterization: > > DOS floppy 2880k > > Here is the "file" report about an image made without -k: > > DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "MTOO4018", > sectors/cluster 2, root entries 240, sectors 5760 (volumes <=32 MB) , > sectors/FAT 9, sectors/track 36, > serial number 0x6c528b1f, unlabeled, FAT (12 bit), followed by FAT > > An image made by a modified grub-mkrescue with mformat option -k > worked well for Florian Pelz. > > --------------------------------------------------------------------------- > > Questions: > > 1: Is there any use for the partition entry in the EFI partition of a > grub-mkrescue ISO ? > Nope. An artefact of mformat that we don't really want. I just didn't know about -k (or maybe it didn't exist back then) > > 2: Is there any use for the information which mformat does not insert > if option -k is set ? > Probably no > > If the partition entry is not needed but the other MBR-like bytes are > needed: > > 3: Is there a good example in GRUB util sources about how to open a file, > seek to its byte 446, and write 16 zero bytes starting there ? > (I'd like to propose a patch for grub-mkrescue.c which zeros the > partition entry directly after the mformat run.) > I don't think so. > > --------------------------------------------------------------------------- > > > Have a nice day :) > > Thomas > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
