this post was submitted on 07 May 2025
9 points (90.9% liked)

Linux

10286 readers
56 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 2 years ago
MODERATORS
MigratingtoLemmy@lemmy.world
9
Anybody running Kinoite having problems booting the 6.14.5-300 kernel? (lemmy.world)
submitted 3 days ago by somethingsomethingidk@lemmy.world to c/linux@lemmy.world
13 comments fedilink hide all child comments
 

When I last updated Kinoite (1-2 days ago), the only packages that were updated were kernel related things. Going from 6.14.4-200 to 6.14.5-300.

When I try to boot into the new deployment, the system just hangs on the plymouth boot screen and I have to do a hard reset on the computer. No logs are generated, so I'm either not getting out of grub or I'm stuck in the iniramfs stage (but that usually prints some errors and drops you into a rescue shell). It's so weird. It just sits there.

My old deployment works fine though. Anybody else experienced something similar? Or know of a way I can get some more info out of the system?

you are viewing a single comment's thread
view the rest of the comments
[–] HayadSont@discuss.online 1 points 3 days ago* (last edited 3 days ago) (1 children)

No Nvidia, just intel integrated graphics. Its a dell ispiron 7500.

Yeah, that shouldn't cause any pecularities.

LayeredPackages: alacritty bat btop distrobox fish flatpak-builder kpeoplevcard light lsd mako neovim parallel python3-neovim shellcheck swaybg swayfx swayidle swaylock syncthing tailscale tmux virt-manager waybar wlogout wlsunset wofi

Hmm..., nothing too outrageous, I think; still, consider rpm-ostree reset to at least rule out the possibility that any of the layered packages are to be blamed. If you're afraid of losing your working deployment, ensure to evoke the sudo ostree admin pin 1 command to pin it. (ASSUMING THAT THERE ARE ONLY TWO DEPLOYMENTS WHEN YOU DO THIS). After you've done the pinning, ensure that you pinned the correct one by checking this with rpm-ostree status; the deployment you wish to pin should state the fact that it's pinned.

journalctl shows nothing. That’s what I meant by no logs, I should have been clearer. It’s not even getting that far. It’s like it’s stuck in grub, but only when I try the new kernel.

Perhaps I had to be more clear and explicit, boot twice:

  • first, into the now broken deployment, wait until the time your system should have booted otherwise. Then, hard reset.
  • secondly, to your still working deployment, then evoke the journalctl -b -1 command. This should, unless something is wrong with how systemd is setup on your system, show you the logs of the previous boot. You could even compare it with your current boot (which can be accessed with journal -b) and see where it diverges, though looking at the logs of the corrupt boot sequence should suffice.

The only deviation from the vanilla kargs have been for troubleshooting this and I did it in the grub editor so they aren’t persistent. I tried removing rhgb changed quiet to verbose and debug and loglevel=7 just to see if anything would happen. It still just hangs

Aight. Thank you for putting in the work so we can rule that out!

[–] somethingsomethingidk@lemmy.world 1 points 3 days ago (1 children)

Perhaps I had to be more clear and explicit, boot twice So yeah it's not showing anything from the "first" broken deployment. Just to be empirical,

  • I ran date > time.txt && reboot
  • Tried to boot the new deployment, waited about 10 min
  • reset and booted into working deployment
  • ran journalctl -b -1 and the last entry was 2 seconds after the date output in step one.

It is not even getting to systemd.

I tried uninstalling the packages, and rebasing to silverblue. Nothing changed. I think I'm going to just put a pin in it and hope that the next update fixes something haha

speaking of pins

If you’re afraid of losing your working deployment, ensure to evoke the sudo ostree admin pin 1 command to pin it.

This is so important and the first thing I did. I got screwed a few years ago when I first tried silverblue. Everyone talks about how you can just rollback, no one ever mentions that you can lose your last working deployment hahah thanks though

[–] HayadSont@discuss.online 1 points 3 days ago (1 children)

I'm pretty clueless at that point. Never seen something like it. Apologies for not actually being able to help out. Hopefully it will be resolved soon, though.

This is probably not the advice you'd like to hear, but I wonder if rebasing to uBlue's Kinoite would make any difference. Regardless, wish you the best!

[–] somethingsomethingidk@lemmy.world 1 points 3 days ago (1 children)

I’m pretty clueless at that point. Never seen something like it. Apologies for not actually being able to help out. Hopefully it will be resolved soon, though.

Right? It's super strange. On a normal system I would try reinstalling GRUB and maybe manually generating the initramfs, maybe compile a new kernel, but idk if I can do that here.

This is probably not the advice you’d like to hear, but I wonder if rebasing to uBlue’s Kinoite would make any difference. Regardless, wish you the best!

That's actually really interesting, maybe getting away from the fedora ecosystem would help. I do think uBlue is downstream. But it wouldn't hurt

[–] HayadSont@discuss.online 1 points 3 days ago* (last edited 3 days ago)

I do think uBlue is downstream

It's indeed downstream~ish. But perhaps just different enough to actually make a meaningful change.