Finding a kernel (and a distro) that works with 5k iMacs

[fox]

If you were following my thread on Ubuntu 20.04 beta, you will know that I was having problems running it nicely on my 5k late 2015 iMac. I don't know what it is about this computer. Linux runs very well on most Macs, but this one is an exception. I'm assuming that it has to do with the video card (AMD Radeon m9 390x), the video configuration (is there an on-board video card as well?), or the resolution (it's 5k in MacOS through some OS trickery, but Windows and Linux see its native resolution as 3k). At any rate, the bottom line is that on any of the newer kernels, it takes 2 1/2 - 4 minutes to boot to a working desktop, about as much time to shut down, and even several minutes to wake from sleep. The problem is related to the kernel itself because the older kernel, version 4.15, retained after an upgrade from Ubuntu 18.04, works fine in 20.04. But its end of life is April 2023, vs April 2025 for the Ubuntu 20.04 default 5.4 LTS kernel.

I decided to do an experiment booting up a bunch of live distros with different kernel versions to see if any kernel in the 5 series or newer would work properly. Here are the live distros and kernels I tried:

• Sparky Linux 2020.03 - kernel 5.4.19
• Solus 4.1 - kernel 5.4.12
• Peppermint 10 - kernel 5.0
• PCLinuxOS 2020.03 - kernel 5.5.10
• Manjaro 2020-04-07 stable - kernel 5.6rc7
• Nitrux 2020.03.27 - kernel 5.5.13
• Fedora 32 beta - kernel 5.6

All of these except Peppermint booted slowly, though some were slower than others. Peppermint booted in about a minute, suggesting that 5.0 might be all right if there was any reason to use it. (It isn't an LTS kernel and it isn't clear how long Peppermint itself would support it.) The next best performance was Manjaro, which took about 1 1/2 minutes to boot. It had the newest kernel, potentially suggesting that newer future kernels might work well with my 5k iMac. Except that Fedora 32 beta with the 5.6 kernel was much worse, so maybe it was the Manjaro setup. All other distros and kernels that I tried worked poorly, taking anywhere from 2 1/2 - 3 1/2 minutes to boot.

This leaves me with a bit of a dilemma. The 5k iMac used to be my office computer, but I brought it home since I won't be going to the office for awhile. It is 4 years newer than the old 2k iMac that is my home computer, but that older iMac works well with everything I have tried on it, including the live Ubuntu 20.04 usb. I would prefer to be using the newer, faster computer, but it could mean that I will be stuck having an unsupported operating system (whether Ubuntu or Mint) in 3 years when the 4.15 kernel is no longer supported. Yeah I know that 3 years is a long time and the Manjaro test suggests that the problem will eventually be fixed. What would you do?

FYI, I have looked for solutions online and have found nothing so far. You might think that Ubuntu Forums would be the best place to find a solution, but they have nothing relevant in the Apple Forum and not a lot of activity there. I haven't found anything useful in their other forums, either.

[buster]

"But its end of life is April 2023"

That's about 102 weeks. You'd better hurry and solve this Mike. 

[Jason]

Isn't that 156 weeks, Buster? I know you were the math teacher but...

I don't know but would expect that the problem will be fixed assuming that this is a popular device to run Linux on. So I'd just wait and see what happens. They haven't even frozen the kernel yet, the final version may be different. Also, did you try hitting <esc> to see any boot-up messages? It's probably some driver (kernel-related) or service that is hanging on startup. If you'd really like a challenge you can compile your own kernel and remove anything that is causing the problem if it's kernel-related. I remember doing that back in the day. It was a fun project but not something I'd want to do on a regular basis.

Now, if this device actually lasts the 3 years, you can get support past 5 years, you just have to pay for it.

[buster]

"Isn't that 156 weeks, Buster? I know you were the math teacher but..."

My father, who was the last remaining descendant of the Corribander Tribe other than my brother and myself, taught and used it in our house the 10 or 11 day week of his ancestors. Certain seasons, such as for hunting, fishing, planting and harvesting were 11 days each, and winter, mid summer and festive seasons were 10 day weeks. So it works out to 104 weeks for my tribe. I keep forgetting no one else uses this system anymore since brother died 6 years ago.

[Jason]

You're yanking my chain, right?

[buster]

"You're yanking my chain, right?"

Me???

[fox]

.... It's probably some driver (kernel-related) or service that is hanging on startup. If you'd really like a challenge you can compile your own kernel and remove anything that is causing the problem if it's kernel-related.
....

It has to be kernel-related in that the delay doesn't happen on the earlier kernel. I looked at the grub menus for both and they are identical except for the kernel they point to.

And yes, services are hanging this up. You can see it from runs of "systemd-analyze blame". For the 4.15 kernel I get:
8.009s logrotate.service                                   
6.888s snapd.seeded.service                                 
6.819s systemd-logind.service                               
6.801s snapd.service                                       
2.549s dev-sdc3.device                                     
1.716s man-db.service                                       
1.476s virtualbox.service                                   
1.069s dev-loop8.device                                     
1.028s dev-loop10.device                                   
968ms dev-loop13.device                                   
958ms dev-loop11.device                                   
954ms dev-loop9.device                                     
947ms dev-loop14.device                                   
941ms dev-loop15.device                                   
919ms dev-loop12.device                                   
916ms dev-loop16.device                                   
894ms dev-loop17.device                                   
892ms udisks2.service                                     
836ms dev-loop2.device                                     
835ms dev-loop4.device                                     
780ms e2scrub_reap.service                                 
735ms dev-loop1.device                                     
730ms dev-loop6.device

From the 5.4 kernel I get:

2min 2.295s gpu-manager.service                                 
    54.063s snapd.service                                       
    39.915s udisks2.service                                     
    39.660s NetworkManager-wait-online.service                   
    13.442s apport-autoreport.service                           
    13.177s virtualbox.service                                   
    13.112s kerneloops.service                                   
    10.659s systemd-logind.service                               
     2.470s dev-sdc3.device                                     
     1.705s dev-loop8.device                                     
     1.563s dev-loop10.device                                   
     1.554s dev-loop9.device                                     
     1.505s dev-loop12.device                                   
     1.495s dev-loop13.device                                   
     1.477s dev-loop11.device                                   
     1.462s dev-loop6.device                                     
     1.445s dev-loop7.device                                     
     1.437s dev-loop4.device                                     
     1.420s dev-loop2.device                                     
     1.417s dev-loop3.device                                     
     1.400s dev-loop15.device                                   
     1.390s dev-loop0.device                                     
     1.390s dev-loop5.device   

I also noted during the boot sequence of 5.4 kernel, that jobs were running for login.service and networkmanager.service, and there was another error on "detect available GPU".

AMD does have a driver for my GPU, but it isn't available yet for Ubuntu 20.04. I tried installing the latest proprietary driver available, but it wouldn't install on 20.04. This might solve the problem when it is available.

[Jason]

You mentioned it must be kernel-related because it doesn't happen on the previous kernel. But aren't these distros that are using new kernels also using newer versions of various services that startup? Or are you specifically choosing to just use a newer kernel on the older release of the distro?

Are you using wireless or a cable connection?  I'm wondering if that's why network manager is talking so long to load. It still shouldn't take that long but just curious. You might try googling each of the services exactly as they're named something like "snapd.service takes too long to load" or something alone those lines.

You must be looking at the same website I am for the systemd.analyze blame bit. Is it this? If so, you probably noticed in the article where it talks about how to disable certain services at boot time. I'm not sure if they will start themselves afterward but you can try it just to see if it affects boot time and always re-enable it later. I don't think you can permanently disable snapd for example, or you won't be able to run snapd software and if you look at your installed apps, there are quite a few snapd programs and there will be more in the future.


It's a curious problem. But I'm sure you'll figure it out before 2023. ;-)

[ssfc72]

Happy festavous day! :-)

"Isn't that 156 weeks, Buster? I know you were the math teacher but..."

My father, who was the last remaining descendant of the Corribander Tribe other than my brother and myself, taught and used it in our house the 10 or 11 day week of his ancestors. Certain seasons, such as for hunting, fishing, planting and harvesting were 11 days each, and winter, mid summer and festive seasons were 10 day weeks. So it works out to 104 weeks for my tribe. I keep forgetting no one else uses this system anymore since brother died 6 years ago.

[fox]

You mentioned it must be kernel-related because it doesn't happen on the previous kernel. But aren't these distros that are using new kernels also using newer versions of various services that startup? Or are you specifically choosing to just use a newer kernel on the older release of the distro?
....

I think that the 4.15 kernel I am using is the latest in that series from Ubuntu. It was inherited from the 18.04 version that I upgraded; it wasn't deleted in the upgrade to 20.04. I'm booting it in 20.04, so I would think it is using the same version of the services as the 5.4 kernel.

I found instructions on how to disable a service and tried that for snapd. It didn't make any difference in the startup time, but maybe it wasn't disabled in the reboot.

[Jason]

Using the 'service' command is probably better for disabling a service on boot like this:

Code Select Expand

sudo service snapd.service disable


To put it back in boot use 'enable' option instead of 'disable'.

I would recommend using timeshift to backup the system to another drive before doing this kind of thing as it could potentially break a system. Timeshift takes a while for the initial backup but is quicker on subsequent backups unless the system changes are extensive. I don't think this service will but some of the others like udisk might. If the system won't boot up after turning one of these off, you can use the usb drive too boot the system and timeshift to restore it. Be default timeshift only backups the system, not home folders and I'd leave it that way.

You could use another backup program that backs up the entire system though. At the very least, you should have a backup of your /home partition.

[fox]

I have a great system for trying things. I have two installations of 20.04, one from a live usb and the other an upgrade from 18.04. I try stuff on the first and would only use it on the second if it works well.

As I recall, I used the command you recommended to disable snapd, but I think that the real issue is the GPU, not snapd or network service.

[Jason]

If you used that command, it won't start again at boot.

With the gpu as the real issue, are you referring to this in your list?

Code Select Expand

gpu-manager.service

That is also a service you can disable. But it may very well be a driver that is associated with the new kernel that is somehow different and the service starting is bringing up that driver, too. The generic driver would probably work, too, but it'd likely be laggy on that size of screen. Worth a shot to disable it first. Didn't realize that was the time just for it, 2 minutes and change. Wow, thought it was just the total time for all the services.

[fox]

How would I disable the service in a way that lasts through a reboot?

Never mind, I found out how. When I disabled gpu-manager, it did speed up the boot, but it doesn't show in "analyze blame". Where it speeds things up is after you log in, and I think that the delay from login to working desktop doesn't show in blame. Disabling the gpu-manager didn't seem to have any negative effect - all resolutions are still shown in settings and window resizing seems to work the same.

When I looked at blame after disabling the gpu-manager, the three items with the most added boot time were: resolved (31 sec), timesyncd (26 sec) and snapd (21 sec).

[Jason]

How would I disable the service in a way that lasts through a reboot?

It was in a comment I made before the last one. The 'disable' option to the 'service' command.

When I looked at blame after disabling the gpu-manager, the three items with the most added boot time were: resolved (31 sec), timesyncd (26 sec) and snapd (21 sec).

Make sure you try using a feature that requires those services to make sure they work. In this case, check that you have the correct time and that any snap packages you might have work. I'm guessing the service will be loaded when you need it for each item. I don't know what resolved does but I'm sure you can look it up. I think that Firefox is installed as a snap package but you can look in your install applications list (using Discover) and look at the bottom for another snap package.

So what's your boot time like now?

That just made me realized a potential drawback of not using discover and using 'apt full-upgrade' or synaptic. Programs in snap or flatpak form won't be updated. And before one of you guys exclaim boastfully, "I don't use any", look in your installed programs. If you're using a Ubuntu-based distro, there's likely a few you are using and didn't know it.