Using Arch, as soon as I try to update past 4.18-16, I get a bunch of errors in the dmesg log, and I lose the graphical target (SDDM/KDE) and have to change to anoither TTY. In that TTY, I have no network and cannot activate using nmtui. I can downgrade manually back to 4.18.16 and it will boot fine.

I spent a few minutes and installed another Arch install on another partition, and that upgrades and runs fine on 4.19.Y kernel.

Journalctl -xb output

Around line 1200 you'll see some very stack trace-y output, this shows up on the boot screen. As well, as I'm in TTY downgrading, those audit statements will pop up in the session.

Hi, Ikidd.

Bleeding edge kernel throwing a strop? The reason they call it 'bleeding edge' stuff is that you bleed there, mainly time and sweat & tears just to get back to where you were before. You're new enough on LQ; Are you new to Linux? If so, stay on a working kernel and shed your update fever.

Why update past 4.18.6? I'm running 4.14.55 here. If you have one box that will update, and one that won't, why not examine the differences between them. I haven't examined the file to scroll through 1200 lines to see a stack trace like output. I've seen enough stack traces, thank you. I'd like an error message or a dmesg log, if it gets that far. Otherwise, a shot of it's dying protests.

We're not there, so pretend we're dumb and clearly explain what you have installed, why you need this new kernel, and what error shows when you try to build it, boot on it, or whatever you're doing.

Wow. Why the snark? Just trying to save an install that I've had for 5 years, because I have 2 GPUs and 6 monitors that are horrible to set up again because of issues with Xrandr on multi-GPU. So I figure learning why this particular install doesn't want to upgrade to the current Arch build would be nice to do. Arch is hardly the only distro at 4.19-Y. I think even my Proxmox server runs at 4.15 and it's on Debian.

That journalctl output is the dmesg log with a hundred or so extra lines for service start reports. As for what I've installed, I've stepped through every kernel since 4.19.1 to 4.19.8 hoping that whatever it's conflicting with would make itself apparent or go away. I'm running on the latest stable version of Mesa, 18.2.6-1.

At this point I'm fairly certain it's a GCN generation issue, because if I force load of the radeon driver on the 7770 or use kernel switch amdgpu.dc=0, I can get it to load to a graphical target, with expected loss of features and speed of using Radeon on one of the cards. The drm_universal_plane_init is a debug for 4.19 as they've changed some things in the amdgpu kernel driver, and I'm starting to find bugzilla reports on GCN generation conflict issues on freedesktop.org.

The 'snark' because I presumed (in the lack of other information) that you were an over-updating newbie. You obviously aren't, but your post was so vague, and your stats and lack of clarity led me to that conclusion. My bad.

At 2 GPUs and 6 monitors I wish you well.

Hi ikidd,

Out of curiosity, what boot manager are you using ? Legacy BIOS or UEFI ?

I recently had similar issues with kernel upgrades on Arch on a system where I run RAID through mdadm and use rEFInd as a boot manager.

It eventually stopped occurring, but while it was, it had to do with whether the ESP (EFI System Partition) was mounted during system update (pacman -Syu). Downgrading to previous kernel version and then specifically upgrading the linux kernel (linux, linux-firmware, linux-headers .. etc. ..) while making sure the ESP was mounbted, did the trick as a workaround. The issue simply stopped occuring - I am on kernel 4.20.x at this point.

Let me know if this is not clear and if it is, whether it worked for you.

Cheers.