I’ve noticed that when 6.6.1 came out and it came time to reboot after it installed, I couldn’t boot into the OS anymore, it simply hangs on a black screen for about 10-15 minutes then reboots after selecting it. I’m currently on the LTS kernel which is 6.1.67-1-lts (64-bit) with no issues. I figured after updating to the latest one 6.6.6. things may be better but no. Each new kernel release, I test it with the same results.
CPU is CPU: quad core Intel Core i7-2600S (-MT MCP-) on Dell Optiplex 990 SFF PC with 16GB Ram in UEFI mode. Via either Grub or Systemd-boot. On one hand, I’m thinking that my computer’s time may have finally come up once the LTS moves to 6.6.1 but, until then, and I can procure a newer system, I’d like to see if anyone else has encountered such a thing.
I’d probably start by booting with nomodeset and in verbose mode and hope you can at least get some debug output. If you have Plymouth, obviously disable that. Anything that can give you some logs and possibly a crash dump to figure out what it’s doing when it dies.
It might also be worth running a quick memtest86+ just to rule this out, you may have dead RAM and memory aligns in a fatal way there with newer kernels and there’s nothing wrong with the kernel itself. There’s an open Arch bug report for 6.6.2 that suggests memory corruption as well, so it’s definitely worth a shot.
If you have another device, you could also have it send the logs there over the network, I think it can just send them out over UDP so it’s likely there’s an Android or iOS app that could receive the logs.
If this is Arch, bisecting might not be as hard as you think. Compiling kernels is not as horrible as it sounds, even on other distros. For the most part it’s more or less the same configure+make steps especially if you reuse the config of the currently running kernel, which it can use pretty much automatically.
Good project for this weekend. I depend on my system to work at home, so can’t do much during the week. What’s fun is I can boot this all day long in a KVM machine on the very same machine which doesn’t boot it, but I know it’s a different environment.
I’ll probably reset my BIOS as well just to start fresh on that end. And then go from there, when it hit my system a few months ago or whenever it was, I let it reboot for about an hour and it eventually gave me my desktop.
So I ran nomodeset during reboot (systemd-boot) and it booted with no errors, BUT - dual screens became one at something like 800x600 res if that and I couldn’t change that (KDE Desktop on Arch). So, I at least know it boots okay, just not where I want it to.
I mean, no, but this probably isn’t the way you want to go about dealing with it.
If you know how to build and install your own kernel out of git, and how to run a git bisect, you could go back and identify the exact commit to the kernel that introduced your problem, which would probably do a lot to help accelerate getting the problem fixed.
I’m not that good with building kernels, in fact have never done it. By LTS I mean “Long Term Support” as in a kernel which will not be unsupported for a few years yet.
The new kernel update fucked up my wifi which in turn fucked up KDE and I couldn’t even use my terminal. Wish it wasn’t rushed, and just left alone until after new years tbh
You still can access your terminal from other sessions using ctrl+alt+f1, f1 to f7, you should check cause usually session 1 and 7 are used by the desktop managers , but the others are free to login
