Bug#716927: grub-efi-amd64: grub-efi doesn't support HFS+ EFI partitions
David Purton
dcpurton at marshwiggle.net
Mon Oct 19 13:33:00 UTC 2015
Those following this thread might be interested in my work around.
I use the method outlined by the OP to boot debian on my Macbook Air.
I'm basically resigned to things failing every time grub-efi-amd64 is
updated.
So now I let it fail, then run this shell script to fix things up and
make sure my machine is in a bootable state:
/boot/efi is a small HFS+ partition without a journal.
It's structure (when working) looks like this:
EFI
↳ debian
↳ grubx64.efi
mach_kernel
System
↳ Library
↳ CoreServies
↳ boot.efi
↳ SystemVersion.plist
.VolumeIcon.icns
Notes:
- grubx64.efi is hard linked to boot.efi
- .VolumeIcon.icns contains an icon for the volume (optional)
- mach_kernel is an empty file
- SystemVersion.plist contains:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>ProductBuildVersion</key>
<string></string>
<key>ProductName</key>
<string>GNU/Linux</string>
<key>ProductVersion</key>
<string>Sketch</string>
</dict>
</plist>
When grub-efi-amd64 is updated, everything gets borked up.
So after an unsuccessful update, I run this shell script to fix things up:
#!/bin/bash
# Workaround for grub-install's failure to work properly with hfsplus
# partitions.
#
# Use a loopback vfat partition to install on, then copy updated
# grubx64.efi to the actual hfsplus parition.
rm -rf /boot/efi/EFI/debian/System
umount /boot/efi
fsck -t hfsplus UUID=86734cde-d4c8-3eef-bae0-abefba3c2332
mount -t hfsplus -o force,rw -U 86734cde-d4c8-3eef-bae0-abefba3c2332 /mnt
mount -t vfat -o loop efiboot.img /boot/efi
grub-install
cp /boot/efi/EFI/debian/grubx64.efi /mnt/EFI/debian/
umount /boot/efi
umount /mnt
mount /boot/efi
Notes:
- efiboot.img is a small vfat image. It's file structure is as
follows:
EFI
↳ debian
↳ grubx64.efi
The logic of the above script is pretty simply. It fixes the damage done
to the HFS+ partition after a botched install. fscks the HFS+ partition
in case it was not cleanly unmounted (otherwise mounting rw causes
problems), mounts the vfat efi image, runs grub-isntall, copies the new
grubx64.efi to the HFS+ partition, then remounts things in the proper
place.
My question is:
Why can't grub install just treat the HFS+ partition in exactly the same
way as a vfat one? That way once the directory structure is set up,
grubx64.efi would just be upgraded and nothing else would change =>
system continues to boot fine.
Hope this helps,
David
--
David Purton
dcpurton at marshwiggle.net
For the eyes of the LORD range throughout the earth to
strengthen those whose hearts are fully committed to him.
2 Chronicles 16:9a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20151020/5d6ff1e2/attachment.sig>
More information about the Pkg-grub-devel
mailing list