2

I have after pulling teeth and hair installed Xubuntu 18.04 LTS on 2006 iMac 5,1 (ATI X1600 graphics).

I had to insert "nomodeset" in the installer to get graphics and complete installation. I have no other OS installed.

Now after installation, there are no graphics visible. I have removed "quiet" and inserted "nomodeset" and still no graphics are visible. Recovery mode options in GRUB also produce no graphics.

I have tried entering "echo" lines in grub after the images are loaded and can see those prints. Also, the HDD is all a flurry so boot is occurring, just no display.

It also is rejecting SSH connections so I am really stuck on how to get more information from the box as to what is going wrong.

EDIT: By blindly typing after Ctrl+Alt+F1 I have successfully got SSH installed so I can meddle with the box now.

FYI:

/var/log$ lspci -k | grep -EA2 'VGA|3D'
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV530/M56-P [Mobility Radeon X1600]
        Subsystem: Apple Inc. MacBook Pro
        Kernel modules: radeon

nomodeset is being obeyed, but still no graphics, not even console prints:

Apr 17 13:38:37 macbuntu kernel: [   17.486412] [drm] VGACON disable radeon kernel modesetting.
Apr 17 13:38:37 macbuntu kernel: [   17.486456] [drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!

Here are the prints when left to boot normally:

Apr 17 14:11:18 macbuntu kernel: [   19.829088] [drm] radeon kernel modesetting enabled.
Apr 17 14:11:18 macbuntu kernel: [   19.829180] radeon 0000:01:00.0: remove_conflicting_pci_framebuffers: bar 0: 0x40000000 -> 0x47ffffff
Apr 17 14:11:18 macbuntu kernel: [   19.829182] radeon 0000:01:00.0: remove_conflicting_pci_framebuffers: bar 2: 0x48400000 -> 0x4840ffff
Apr 17 14:11:18 macbuntu kernel: [   19.829185] radeon 0000:01:00.0: vgaarb: deactivate vga console
Apr 17 14:11:18 macbuntu kernel: [   19.829547] [drm] initializing kernel modesetting (RV530 0x1002:0x71C5 0x106B:0x0080 0x00).
Apr 17 14:11:18 macbuntu kernel: [   19.829594] radeon 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xa3a3
Apr 17 14:11:18 macbuntu kernel: [   19.829616] radeon 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x2323
Apr 17 14:11:18 macbuntu kernel: [   19.829668] [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM
Apr 17 14:11:18 macbuntu kernel: [   19.829672] radeon 0000:01:00.0: Fatal error during GPU init
Apr 17 14:11:18 macbuntu kernel: [   19.829675] [drm] radeon: finishing device.
Apr 17 14:11:18 macbuntu kernel: [   19.829676] [TTM] Memory type 2 has not been initialized
Apr 17 14:11:18 macbuntu kernel: [   19.829680] [drm] radeon: cp finalized

1 Answer 1

1

It's really time for a first answer. ;-) At the beginning it should be noted that this topic here is one of the most complex regarding the installation of K(U)buntu in native EFI mode.

The first big problem is that on these early Apple Intel computers the vBIOS is not really exposed in native EFI Mode. On these Apple models, the vBIOS is usually only continuously exposed when the legacy CSM Bios emulation mode (aka Boot Camp) is active. Under native EFI, the vBIOS is avaiable just for a very short time at power-on. To make it even more complex, there exist at the Apple iMac5,1, iMac5,2 and iMac6,1 models also a mismatch between the EFI version, which is 32bit and the CPU which is 64bit. This is the effective problem in that matter because it prevents almost fully the installation of a 64bit Linux version in native EFI mode on those 2006 iMac models.

Only an installation through the legacy CSM Bios emulation layer is possible. Unfortunately this gives several disadvantages like lesser RAM memory (only max. 3GB avaiable), super-slow UDMA133 speed at the SATA300 ports, and others stuff.

However, the whole situation has changed in 2021 somewhat because there exist since Linux kernel 5.7 a new feature called LOAD_X64_ON_IA32_ENABLE. This is nothing less then a (rudimental) mixed-mode 64bit CPU & OS support on 32bit EFI!

But to be clear, this is only the first part in the puzzle. That flag has to be set also at the Ubuntu Kernels which is as of 2021 unclear. This is confirmed officially only for newer Arch-Linux kernels.

Furthermore it looks that also the rEFInd bootloader must have some support for a mixed-mode 64bit OS on 32bit EFI operation. Also here, the current state is unclear.

In the end, the working principle will look as follow:

Apple EFI firmware => rEFInd => Linux kernel (EFISTUB with mixed-mode EFI support enabled)

The function of rEFInd is mainly that it extends the time in which the vBIOS information is avaiable under native EFI. It also hands-over that essential information to Linux, so that the kernel can find the vBIOS.

Long speak short, the whole matter here is nothing for beginners! ;-) More information can be found here: rEFInd & Linux kernel EFISTUB booting at Apple hardware, how to implement it?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .