Tremendously excited about this new release - a big thanks to everyone who's been involved in making it happen, you guys rock! Keen to upgrade from ASCII and try out the new shiny things, but dist-upgrade wants to remove a bunch of critical packages:

The following packages will be REMOVED:
  clamav clamav-daemon clamav-freshclam cmake elogind gnome-themes-standard-data kicad libboost-python1.62-dev libboost-python1.62.0 libboost1.62-dev libclamav9
  libclang1-3.9 libcupscgi1 libcupsmime1 libcupsppdc1 libgsl2 libllvm3.8 libllvm3.9 libllvm3.9:i386 libmariadbclient18 libnomacscore3 libnomacsgui3 libnomacsloader3
  libpam-elogind libqalculate5-data libqalculate5v5 libreoffice-style-galaxy libsensors4 libsensors4:i386 libthunarx-2-0 network-manager network-manager-gnome
  network-manager-openvpn network-manager-openvpn-gnome nodejs-dev virtualbox virtualbox-ext-pack virtualbox-qt

This is on an up-to-date ASCII installation and the following atp/sources.list:

deb http://deb.devuan.org/merged beowulf main non-free contrib
deb http://deb.devuan.org/merged beowulf-updates main non-free contrib
deb http://deb.devuan.org/merged beowulf-security main non-free contrib
deb http://deb.devuan.org/merged beowulf-backports main non-free contrib

I could understand if things like Virtualbox might disappear, but cmake!? Something's clearly not right here, what could that be?

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.

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.

If I was paid the minimum wage for doing this I'd soon be able to buy a brand new iMac (or whatever they're called these days). Not that I ever would, of course. Get paid I mean. Or buy a Mac.

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:

This didn't work; the installer errored out saying I had to install the base system first. But I tried the "rescue mode" and that had the option to re-install grub. I did so, choosing /dev/sda this time, but no dice; the system still fails to boot with ALERT! UUID=9cb7fe29-135e-4471-8b2c-d3e08d6ad44f does not exist. I don't understand why this is so complicated

I'm not keen to go through the whole installation process again (what is it, the fift time?), so if there's a way to reconfigure grub so that the system will boot I'd be happy to hear about it!

I didn't delete anything, but manually configured Grub to install on /dev/sda1, just to try something different. Grub installed without error, but the result is the same; after boot the system cannot find the boot disk and (eventually) errors out to an initramfs prompt with Gave up waiting for root file system device and ALERT! UUID=9cb7fe29-135e-4471-8b2c-d3e08d6ad44f does not exist. This does not happen when I install to a GPT/EFI disk.

Thanks guys, giving that a whirl now!

This might be relevant: