this post was submitted on 12 Dec 2023
11 points (92.3% liked)

Linux

8090 readers
27 users here now

Welcome to c/linux!

Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!

Rules:

  1. Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.

  2. Be respectful: Treat fellow community members with respect and courtesy.

  3. Quality over quantity: Share informative and thought-provoking content.

  4. No spam or self-promotion: Avoid excessive self-promotion or spamming.

  5. No NSFW adult content

  6. Follow general lemmy guidelines.

founded 1 year ago
MODERATORS
 

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.

top 7 comments
sorted by: hot top controversial new old
[–] [email protected] 1 points 11 months ago (1 children)

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.

[–] [email protected] 1 points 11 months ago (1 children)

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.

[–] [email protected] 1 points 11 months ago

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.

[–] [email protected] -1 points 11 months ago* (last edited 11 months ago) (1 children)

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.

[–] [email protected] 1 points 11 months ago

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.

[–] [email protected] -2 points 11 months ago (1 children)

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

[–] [email protected] 3 points 11 months ago

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