It is possible to boot Debian on a Mac with the Apple Firmware if the EFI
partition is HFS+ and follows some rules. See http://glandium.org/blog/?p=2830
for my own setup.

But grub-install from the grub-efi package rejects the EFI partition because
it is not FAT and I have to modify the script each time it is upgraded.

Hello,

Now the situation is even worst. With last updated package, grub-install is not
anymore a script but a binary... So there is no way to change this (at least
that you recompile the package with the desired change I imagine).


Isn't there any way to add a conditional to detect the hfsplus the exfat
partition to continue?.

This is the error I get:

 ✘ muammar@ihacku ⮀ ~ ⮀ sudo apt-get dist-upgrade
 [sudo] password for muammar:
 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 Calculating upgrade... Done
 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 1 not fully installed or removed.
 After this operation, 0 B of additional disk space will be used.
 Do you want to continue? [Y/n]
 Setting up grub-efi-amd64 (2.02~beta2-7) ...
 Installing for x86_64-efi platform.
 grub-install: error: Can't create file: No such file or directory.
 dpkg: error processing package grub-efi-amd64 (--configure):
  subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   grub-efi-amd64
   E: Sub-process /usr/bin/dpkg returned an error code (1)


Thanks,

Actually, it works, but requires the mach_kernel file to be in
/boot/efi/EFI/debian. Once you're past that, all chances are you get an
unbootable system. At least that's the state mine is right now.

Mike

/boot/efi/EFI/debian conflicts with my previous hack. Once I purge
/boot/efi/System, and rerun grub-install, I can finally get a bootable
system.

On the other hand, there are two downsides:
- The debian item "title" uses a different font than the other items in
  apple firmware.
- The debian item doesn't show up in OSX settings for startup.

So, to me, there are at least two different bugs in the version in
unstable:
- Using EFI/debian on hfs volumes.
- Failing with an obscure error message when mach_kernel doesn't exist.

Mike

Hi Mike,


So finally, I had a time to test what you have written.

That's correct. After placing the mach_kernel file in /boot/efi/EFI/debian the
system gets in an unbootable state even if grub-install says everything is ok.
still unbootable.

I also tried the following:  with a  bootable system in efi mode using grub
2.00-22 with your hack, I purged grub completely (apt-get --purge remove grub*).
Then I started the procedure from scratch using this latest version but this
didn't work either for me

So for the moments, I have just gotten back to grub-efi-amd64 version 2.00-22.
I marked as in hold: grub-common grub-efi grub-efi-amd64 grub-efi-amd64-bin
grub2-common. I find your hack very convenient (many things work better in efi
mode in my macbook). So I prefer to stay with this old version more time to see
if I get it working than use grub-pc.


Regards

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

This has been fixed upstream since commit b8765fa0 (2013-12-17)
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=b8765fa0824aab891a28b728f9b7309cbe5c6ba2

Excerpt from util/grub-install.c:

      efidir_is_mac = 0;

      if (grub_strcmp (fs->name, "hfs") == 0
          || grub_strcmp (fs->name, "hfsplus") == 0)
        efidir_is_mac = 1;

      if (!efidir_is_mac && grub_strcmp (fs->name, "fat") != 0)
        grub_util_error (_("%s doesn't look like an EFI partition"), efidir);

(Prior to that, in commit cd46aa6c (2013-11-16), the grub-install shell script was reimplemented altogether in C.)