Skip Navigation
Linux @lemmy.world
somethingsomethingidk @lemmy.world

Anybody running Kinoite having problems booting the 6.14.5-300 kernel?

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?

13 comments

  • @somethingsomethingidk Lightdm stopped working for me on several machines with nVidia graphics after updating to 6.14.4 and 6.14.5, but machines with Intel UHD630 graphics continue to function in terms of their display.

  • Anybody else experienced something similar?

    FWIW, I just booted my laptop that runs a Fedora Atomic derivative -secureblue to be precise*- and updated to the 6.14.5-300 kernel. Afterwards, I rebooted and found a still functional system. Just so you know; GNOME is installed on my system instead of KDE Plasma, but I don't think it would have mattered.

    Regardless, your issue remains and is rather peculiar. Uhmm..., I'm just thinking out loud at this point, but have you considered the following:

    • Is this a system with Nvidia? If so, could it be somehow related?
    • How 'pristine' is your system? Have you layered a bunch of packages? If so, do you think the issue would persist after a rpm-ostree reset?
    • Beyond layering, I have experienced that kernel arguments could cause issues down the line. So, have you tinkered with any of that? If so, do you think the issue would persist if you would remove all user-added kernel arguments?

    Aside from the above, I don't really know what would cause an issue as such.

    Or know of a way I can get some more info out of the system

    Consider accessing systemd's journaling with journalctl. This should be (easily) accessible on a successfully booted system. In your case, that would be your working deployment.

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

      My system isn't pristine but it's not that bad, and I don't see how any of the packages would cause this problem. I can upgrade fine, there's no conflicts. I could see it messing up if I tried to layer a different bootloader but it's nothing like that. Here's my layered packages anyway

       
          
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

      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.

      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

      • 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!

13 comments