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