Installing Devuan on a 2007(!) iMac

Lomax · 2019-09-18 22:46:51

Ok, so I found it in the electronics recycling bin, but it's soooo pretty, complete with original kbd & mouse. And it works too. I couldn't resist trying to put Devuan on it, and much to my amazement the installation zoomed along without error - and it started booting afterwards too. Started, but then it got to fb: switching to radeondrmfb from EFI VGA and just froze. At first I thoght this was a crash, but it isn't; it's the GPU that stops updating the display - I can still ssh in and the system is running. I rebooted, editing grub and adding nomodeset, and voila, a surprisingly snappy desktop - as long as you don't do anything which needs GPU acceleration, like well, almost anything.

CPU performace is not bad; this is a 2GHz Dore 2 Duo with 4Gb RAM (though I suspect only ~3Gb are usable) so not hopelessly... hopeless. I just need to get radeon to survive the modeset and it will make a sexy little DVD player / casual browser. It turns out there is a way to make it go: if I can get the iMac to boot in "BIOS Emulation Mode" then the video BIOS should work with radeon. But how? I tried re-installing a couple of times, manually creating an msdos partition table before partitioning, but the installer kept failing when it came time to install grub, and even if I got past that it would not boot. So I'm hoping I can get some help here - how should I configure the disk partitions during install so that

1) The iMac will boot into "BIOS Emulation Mode"
2) I can complete the installation of a bootloader
3) The machine will find the boot partition afterwards

The patron saint of abandoned technology will be forever grateful for any assistance.

Last edited by Lomax (2019-09-18 22:48:36)

ralph.ronnquist · 2019-09-19 00:06:51

Going on an assumption: I'd suggest that when you are at the "install grub" screen, you should shift to VT2 bmo C-A-F2, to log in; then rm -r /target/usr/share/locale/*.gmo. Then back to C-A-F1 (or maybe C-A-F5 if you're using the "graphical" installer), and continue.

bgstack15 · 2019-09-19 03:12:27

ralph.ronnquist wrote:

Going on an assumption: I'd suggest that when you are at the "install grub" screen, you should shift to VT2 bmo C-A-F2, to log in; then rm -r /target/usr/share/locale/*.gmo. Then back to C-A-F1 (or maybe C-A-F5 if you're using the "graphical" installer), and continue.

Is this related to the consolekit problem that somehow causes problems with the installation of the grub dpkg? I ran into that problem, and I think I solved it by installing grub-legacy. I wish I had thought to try your suggestion back then!

ralph.ronnquist · 2019-09-19 05:52:20

Yes. Specifically consolekit (of some version) didn't use gettext properly, and so ended up with locale directories named like br.gmo/ etc, for it's localizations. Then, grub-install attempts to copy all /usr/share/locale/*mo files into the boot partition, but can't handle these directories and bails out.

By removing those directories, one ends up with a consolekit without localizations, but it works otherwise.

The consolekit version in beowulf (and unstable) have been patched for this, so this particular problem won't arise for them.

Lomax · 2019-09-19 06:57:04

Thanks guys, giving that a whirl now!

Lomax · 2019-09-19 07:57:29

# rm -r /target/usr/share/locale/*.gmo
rm: can't remove '/target/usr/share/locale/*.gmo': No such file or directory

There are lots of .mo files though?

Lomax · 2019-09-19 08:10:56

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.

Last edited by Lomax (2019-09-19 08:11:40)

ralph.ronnquist · 2019-09-19 08:13:00

Ok, my guess was wrong. Ignore me.

Lomax · 2019-09-19 08:17:30

No worries - it was worth a try How do I recover from this though? It should be possible to get this to boot, no?

Lomax · 2019-09-19 08:21:48

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!

Last edited by Lomax (2019-09-19 08:22:02)

ralph.ronnquist · 2019-09-19 08:45:23

Well, I think it should be possible to get it to boot, yes. And I think you should make sure to install the boot loader on /dev/sda (the disk) rather than /dev/sda1 (the first partition).

afaui, grub's boot loader once installed, is directed to a partition with a /boot/grub/grub.cfg file declaring the available systems to boot up, but that file is found by the boot loader looking at a certain byte offset relative to itself rather than a kernel assisted file system access. It's grub itself that accesses the disk blocks of the file for digesting the boot declarations, and then it uses those to find the selected kernel and initrd (if any). So when the boot loader is "misplaced", it doesn't work.

Lomax · 2019-09-19 10:26:14

Thanks. So I have to re-run the install from scratch then? Only asking because it takes quite a while to install the whole desktop environment...

ralph.ronnquist · 2019-09-19 10:59:18

No, If you reboot the installer, but choose the "go back" option as soon as there is one, you'll drop down to the installer steps menu, where you can cherry pick the steps. In this case, it'd be the grub installation step (I've forgotten its exact name).

Or, after having a network up, you could go C-A-F2 and chroot into /target, which then is the previously installed file system, for running grub-install manually, followed by update-grub. If you choose this path, you'll also need some bind mounts before chroot; something like this

mount -o bind /dev /target/dev
mount -t proc proc /target/proc
mount -t sysfs sys /target/sys
chroot /target
grub-install /dev/sda
update-grub
exit
reboot

If you're lucky, that'll work

Lomax · 2019-09-19 12:24:41

ralph.ronnquist wrote:

No, If you reboot the installer, but choose the "go back" option as soon as there is one, you'll drop down to the installer steps menu, where you can cherry pick the steps. In this case, it'd be the grub installation step (I've forgotten its exact name).

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

Lomax · 2019-09-19 12:40:55

I launched a shell on /dev/sda1 from rescue mode, and it looks like it's all there. So why won't it boot!?

# fdisk -l /dev/sda
Disk /dev/sda: 465.8 GiB, 500107862016 byte, 976773168 sectors
Units: sectors of 1 * 512 = 512 byte
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbbbc4bda

Device         Boot     Start       End   Sectors Size Id Type
/dev/sda1      *         2048 966797311 966795264 461G 83 Linux
/dev/sda2           966797312 976771071   9973760 4.8G 82 Linux swap / Solaris

# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.9.0-6-686
Found initrd image: /boot/initrd.img-4.9.0-6-686
done

# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

This looked promising, so I rebooted. Alas, the error remains:

ALERT! UUID=9cb7fe29-135e-4471-8b2c-d3e08d6ad44f does not exist.

After another reboot to a rescue shell:

# less /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=9cb7fe29-135e-4471-8b2c-d3e08d6ad44f /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
#UUID=b10e083f-db41-40e4-ac56-13e66da6ee32 none            swap    sw              0       0
/dev/sr0       /media/cdrom    udf,iso9660 user,noauto       0       0

Yep, that's the right UUID. Let's go one level deeper.

# mount /dev/sda1 /mnt
# mount --bind /dev /mnt/dev
# mount --bind /proc /mnt/proc
# mount --bind /sys /mnt/sys
# chroot /mnt
# update-initramfs -u
# update-grub
# reboot

Boo!

ALERT! UUID=9cb7fe29-135e-4471-8b2c-d3e08d6ad44f does not exist.

Last edited by Lomax (2019-09-19 13:25:19)

Lomax · 2019-09-19 13:25:43

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:

I fired up GParted and created an MBR table and a FAT32 partition and ran the installer. It installed, rebooted, and now she has a fast, perfectly usable machine with full acceleration and everything works, even standby/sleep and WiFi.

Last edited by Lomax (2019-09-19 13:34:48)

HevyDevy · 2019-09-19 13:33:06

try wiping out the grub config file.

sudo rm /boot/grub/grub.cfg

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

Last edited by HevyDevy (2019-09-19 13:33:47)

Lomax · 2019-09-19 14:08:44

HevyDevy wrote:

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.

Last edited by Lomax (2019-09-19 14:10:18)

ralph.ronnquist · 2019-09-19 14:21:36

The core problem seems to be with the partition identifier for the root file system. At some time it was 9cb7fe29-135e-4471-8b2c-d3e08d6ad44f, and now it appears to be something else. But that identifier has got into /etc/fstab.

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.

fsmithred · 2019-09-19 14:43:07

Does your laptop normally boot in uefi mode, like the one in the article you posted? Have you tried installing with gpt and uefi? Do you know if it needs a 32-bit bootloader to do that? If so, there's a way to use the amd64 desktop-live iso to install on such a system.*

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.

_

Lomax · 2019-09-19 17:00:50

ralph.ronnquist wrote:

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?

ralph.ronnquist wrote:

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

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.

fsmithred wrote:

Does your laptop normally boot in uefi mode, like the one in the article you posted? Have you tried installing with gpt and uefi? Do you know if it needs a 32-bit bootloader to do that? If so, there's a way to use the amd64 desktop-live iso to install on such a system.*

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:

"Although it has a 64-bit processor, it has a 32-bit EFI and is not capable of booting into 64-bit mode."

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

fsmithred wrote:

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.)

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

Edit: Better photos below.

Last edited by Lomax (2019-09-19 18:29:44)

Lomax · 2019-09-19 18:29:02

Uncredibly inbelievable.

fsmithred · 2019-09-19 20:30:44

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.

Gave up waiting for root file system device

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.

Lomax · 2019-09-19 21:59:30

fsmithred wrote:

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

Provide the gptsync utility for creating hybrid MBRs. Note that rEFInd's version of gptsync is significantly updated compared to rEFIt's. Also, this tool should be used only on Macs that dual-boot with a BIOS-based OS, such as Windows; or very rarely on other computers.

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.

Last edited by Lomax (2019-09-19 22:09:05)

ralph.ronnquist · 2019-09-19 23:39:24

I think update-grub uses blkid information about partitions, not fstab. Therefore, it will install that uuid into grub.cfg regardless. Then upon boot, it's view of partitions fails to use those uuids, for whatever reasons.

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

The officially official Devuan Forum!

#1 2019-09-18 22:46:51

Installing Devuan on a 2007(!) iMac

#2 2019-09-19 00:06:51

Re: Installing Devuan on a 2007(!) iMac

#3 2019-09-19 03:12:27

Re: Installing Devuan on a 2007(!) iMac

#4 2019-09-19 05:52:20

Re: Installing Devuan on a 2007(!) iMac

#5 2019-09-19 06:57:04

Re: Installing Devuan on a 2007(!) iMac

#6 2019-09-19 07:57:29

Re: Installing Devuan on a 2007(!) iMac

#7 2019-09-19 08:10:56

Re: Installing Devuan on a 2007(!) iMac

#8 2019-09-19 08:13:00

Re: Installing Devuan on a 2007(!) iMac

#9 2019-09-19 08:17:30

Re: Installing Devuan on a 2007(!) iMac

#10 2019-09-19 08:21:48

Re: Installing Devuan on a 2007(!) iMac

#11 2019-09-19 08:45:23

Re: Installing Devuan on a 2007(!) iMac

#12 2019-09-19 10:26:14

Re: Installing Devuan on a 2007(!) iMac

#13 2019-09-19 10:59:18

Re: Installing Devuan on a 2007(!) iMac

#14 2019-09-19 12:24:41

Re: Installing Devuan on a 2007(!) iMac

#15 2019-09-19 12:40:55

Re: Installing Devuan on a 2007(!) iMac

#16 2019-09-19 13:25:43

Re: Installing Devuan on a 2007(!) iMac

#17 2019-09-19 13:33:06

Re: Installing Devuan on a 2007(!) iMac

#18 2019-09-19 14:08:44

Re: Installing Devuan on a 2007(!) iMac

#19 2019-09-19 14:21:36

Re: Installing Devuan on a 2007(!) iMac

#20 2019-09-19 14:43:07

Re: Installing Devuan on a 2007(!) iMac

#21 2019-09-19 17:00:50

Re: Installing Devuan on a 2007(!) iMac

#22 2019-09-19 18:29:02

Re: Installing Devuan on a 2007(!) iMac

#23 2019-09-19 20:30:44

Re: Installing Devuan on a 2007(!) iMac

#24 2019-09-19 21:59:30

Re: Installing Devuan on a 2007(!) iMac

#25 2019-09-19 23:39:24

Re: Installing Devuan on a 2007(!) iMac

Board footer