debian SQUEEZE not STRETCH was the best option at that time, alongside with debian wheezy and lubuntu.
ubuntu cd for some strange reason very often didn't get picked up by the apple machine for some reason or did not allow to boot.

Install the most basic debian wheezy possible - about 160 packages. No X no desktop no nothing.
dist-upgrade to stretch, clean up unneeded packages etc.
Then follow the instructions for changing from Debian Stretch to Devuan ASCII.
Then install X and whatever desktop and stuff you want.
I use LILO as the boot loader because I don't need any of the features of grub.

Have a read of https://forums.freebsd.org/threads/inte … ure.48596/ which documents my attempt to get FreeBSD installed and a bit more as well. I did it as a resource for anybody trying to get linux or bsd up and running an an old intel iMac.

The FreeBSD installer won't boot because it can't handle the 32bit EFI.
No derivatives of FreeBSD will boot for the same reason.
NetBSD and OpenBSD work well but no sound. There is a bug in the sound chip that linux fixed a decade or more ago but the BSDS never got around to it!
TinyCore linux boots.
Debian Wheezy boots.
Fedora 14 boots.

1. install the extlinux package

2. run its boot loader installer (which replaces grub's boot loader on MBR)

3. prepare the boot configuration for your system

Notionally it follows the same procedure as a grub boot; that the boot loader loads the configuration file, which points out where the kernel and initrd are found, and then it runs that kernel. The differences between them are probably plenty in the nitty-gritty, most of which I don't know anything about.

For your system, I think the configuration file /boot/extlinux/extlinux.conf could be along the lines of

DEFAULT Devuan
SAY Now booting Devuan using exlinux just like Ralph said...
LABEL Devuan
    KERNEL /vmlinuz
    APPEND ro root=/dev/sda1 initrd=/initrd.img vga=auto nomodeset

Check out https://wiki.syslinux.org/wiki/index.php?title=Config for details and extras. Note that I dropped in a nomodeset kernel boot parameter just for illustration.

extlinux and grub are alternative bootstrap solutions, and while you may have them both installed in the sense of their software and configurations residing on the file system, the one whose boot loader gets installed to MBR (i.e., disk block zero) is the ruling one, and you may as well purge the one you are not using. As always with these things, some people prefer the one and others prefer the other, and many people don't care either way as long as it works.

Final note: the installation disk probably uses extlinux.

ralph.ronnquist wrote:

I think update-grub uses blkid information about partitions, not fstab.

Ah, many thanks, that clears things up!

ralph.ronnquist wrote:

everything works like magic

Well... Considering I can't even get this thing to boot...

How is it that I can boot in rescue mode and chroot to /dev/sda1 but grub can't boot at all? The disk is clearly there, and it clearly has all the right bits on it. This should be a doddle, surely?

Did you modify /etc/default/grub as ralph mentioned? Then update-grub ?

I think update-grub uses blkid information about partitions, not fstab.

Ah, many thanks, that clears things up!

Well... Considering I can't even get this thing to boot...

How is it that I can boot in rescue mode and chroot to /dev/sda1 but grub can't boot at all? The disk is clearly there, and it clearly has all the right bits on it. This should be a doddle, surely?

A quick glance at man update-grub leads to man grub-mkconfig, which leads to info grub-mkconfig (it's always good to make documentation hard to find, isn't it ), which suggests that you should put GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub to avoid using uuid as partition identifications in grub.cfg, and instead use the "hardware path", which would be /dev/sda1 (i.e. grub refers to "where" the partition is, rather than via its content).

Then you need another update-grub to execute that wish, and everything works like magic

Gave up waiting for suspend/resume device

This one can often be fixed by adding RESUME=none to /etc/initramfs-tools/initramfs.conf and then running update-initramfs -u or my manually unpacking the initrd and removing the resume file before repacking it. I suppose it would also be valid to put the correct swap uuid in the resume file if you're planning to hibernate.

Good tips, thanks! I did notice it crashing on resume from suspend when I booted with nomodeset. At this stage though, just getting it to boot with GPU acceleration is my #1 concern. For which this might be the answer: https://www.rodsbooks.com/refind/features.html

Edit: I'm still curious though; where does it get the idea to try booting from a UUID when no such reference should be present any more? Doesn't fstab inform update-grub which partitions are available? Not that I think this would fix the problem (the UUIDs did match) but it's just not what I expected to see.

Gave up waiting for suspend/resume device

This one can often be fixed by adding RESUME=none to /etc/initramfs-tools/initramfs.conf and then running update-initramfs -u or my manually unpacking the initrd and removing the resume file before repacking it. I suppose it would also be valid to put the correct swap uuid in the resume file if you're planning to hibernate.

I don't know an initrd edit for this. You could try adding rootdelay=10 to the linux line in grub.cfg as suggested in the screen. If you know your way around grub command line, you could muck around there and see if you can find the root device yourself.

replace that to say /dev/sda1 instead.

I had the same thought, but first forgot to run update-grub after making the change, and was surprised to still see the same error. So I went back to the rescue shell, verified that fstab was still the same (with /dev/sda1 and /dev/sda2 instead of UUIDs), then I ran update-initramfs -u and update-grub. Guess what; I STILL GET THE SAME BLOODY MESSAGE! How can it complain about a missing UUID when none are present?

Ah yes, that was just a typo (in my post); the swap partition was always active - I had only commented it out prior to copying in order to change to /dev/sda2.

It's not a laptop, it's a white Core 2 Duo iMac. It normally boots in EFI mode (this machine is pre-UEFI), but the GPU stops working at modeset with EFI boot. As the thread on Reddit I linked to makes clear, those iMacs included a "BIOS emulation mode" for compatibility with BootCamp - and this is automatically activated when booting from a disk with a MBR/msdos partition table (there is no GUI for activating this). The GPU (Radeon) works under Linux in BIOS compatibility mode - and that's precisely why I'm battling with all this. As for AMD64 vs i386, from everymac.com:

It also cannot accept more than 4Gb of RAM, so no need for 64-bit addressing - or indeed even PAE.

Already done that; the UUIDs both match exatly what is was in fstab.

Edit: Better photos below.

It sounds like Ralph identified the problem. Get rid of that erroneous uuid, and it should work. (Run blkid to prove that the uuid doesn't exist, if you haven't already done that.)

* You would install the grub-efi-ia32 package that's in the root of the live system before you run the installer. When it asks about installing the bootloader, say No. Then run the installer, and when that asks about bootloader, let it install.
This was tested at least one time, on a macbook pro, by someone other than me.

_

So replace that to say /dev/sda1 instead.

And you would "activate" the swap space by replacing #UUID=b10e083f-db41-40e4-ac56-13e66da6ee32 (including the #) with /dev/sda2.

try wiping out the grub config file.

Isn't that what I've already done? Like three times by now? The result is exactly the same anyway.

sudo rm /boot/grub/grub.cfg

Then sudo update-grub or  sudo grub-mkconfig -o /boot/grub/grub.cfg

Edit: What's all this talk about a "hybrid" partition table anyway? Apparently the Macs use some kind of MBR within GPT PT, to allow dual booting with Windows or something like that - but I'll be damned if I had a clue how to create one! This guy didn't seem to need one: