Starting several months ago system updates typically break plymouth. This means that I get no GUI screen on which to enter the passphrase to my encrypted installation. Luckily I can still just type in the passphrase and hit enter and it mounts and finishes booting to a normal GUI.
I put up with the problem for a few months and then discovered that all I have to do to fix it is run dracut -f as root. The everything works ok, until another system update comes along and then breaks it…again.
Any advice as where I might look to fix this such that the updates don’t keep breaking plymouth?
Something seems not quite right with your install. The fact that the gui screen does not come up after an update but does seems to indicate maybe a needed package or script is out of sync with something. It seems to be something in your system since I have seen no messages from anyone else with a similar symptom, and the fact you report it has been happening for some time might indicate when and what happened to cause it.
You might try (in this order) sudo dnf upgrade --refresh sudo dnf distro-sync sudo dnf reinstall '*'
With each one pay attention to the messages and if errors occur then fix the error before going on. Reboot after each and see if the gui appears before doing the next.
If one of those fixes the problem there should be no need to continue the remainder.
It sounds like everything is installed and configured correctly then.
My hunch would be that it is an SELinux permissions issue. When you run a command manually like that from the command line, it runs “unconfined” (most SELinux restrictions are bypassed). However, when the update is triggered from a system service, it runs in a specially crafted SELinux context that can only access files with the proper “label”. The first thing I would try is sudo fixfiles -F onboot. Then reboot your computer and it should fix any incorrect file labels during the boot. If that doesn’t work, I would try sudo dnf reinstall plymouth* to reinstall all the plymouth-related packages.
I might in fact have something out of shape in my SELinux… I chose fedora for kvm (since I understood that Red Hat absorbed the group that created it…). So, when I was trying to sort out some issues surrounding running Windows 10 with gpu passthrough and also file-sharing, it is possible I left something awry with the security earmarks…
Ok, no major complaint for upgrade --refresh and distro-sync. I am a little reluctant to go for reinstalling everything (I think there is a humorous parallel to a Dali-Lama ordering a pizza in there) since I assume there will be a whole lot of re-booting? That will become quite a chore since I can’t seem to get it to complete booting every time due the issue in question.
I think I will try Gregory’s advice first and see what that does. I also changed my kernel retention limit to 5 in the hopes it will keep my one working kernel…
Then when you update the kernel and/or the nvidia modules, the modules will be built after the initrd has been run. Thus, the nvidia module is not available when dracut is asking for the luks password.
This must be a common issue, or I have to be wrong here.
I think it might be related to initrd? I ran dracut -f after I successfully booting up 6.0.12. Then rebooted and found it is now no longer working too… I had tried the solar theme and I am now wondering if that is the issue? Unfortunately I didn’t figure this until after I tried rebuilding it in the only ‘working’ kernel left and now it is also not giving me the luks query. SO I am now investigating how to log in with graphics in the hope that will let me tinker with this further…
When I install the nvidia driver, or when I upgrade the kernel the modules are built immediately by akmods without waiting for a boot. Thus even though the new kernel is installed and the older kernel is still active the modules are built for the newer kernel at install time. I don’t know the timing, but I think that the new modules are available within the new intramfs image that is built at that time. The new boot is certainly able to use the new modules.
I run with secure boot active and akmods signs the modules so they can load. I do not use luks, so how that interacts with luks I have no clue.
Hmm. Whish I could check on any of this but right now all my kernels are refusing to show video. I am not familiar with how to get my system loaded from grub2 when kernels don’t normally load. I put a help request on the Fedora Discord but either I did not frame my request correctly or nobody is on who knows what to do either… I know the system is still alive though because if I remove the options in grub to blacklist nouveau (so it can load as a fallback) then I can see system messages as usb devices are plugged/unplugged. Can’t do anything with it though. Whatever happened to being able to ctrl+alt+Fx into a terminal shell? Also, when I hit ctrl+alt+del I am taunted by a glimpse of the plymouth solar theme right before the system restarts…
Any idea how I can log into my machine now that the normal kernel images are all yielding no video?
Adding rd.break=mount should drop you to a rescue shell in the initramfs with your system’s root filesystem mounted at /sysroot. From there, you should be able to run, for example, chroot /sysroot dracut -f.
BTW, I know it is a little late for this, but you could have been using dracut -f /boot/$(</etc/machine-id)/<some-older-kernel-version>/initrd <some-older-kernel-version> to rebuild older kernels and test them rather than risking corrupting your last good kernel.
The timing is that first the kernel is installed including building the initrd. Then a systemd job is queued to start building the akmod modules as rpm packages and installing them. If the new kernel module is needed in the initrd environment, you will need to build the initrd a second time.
journalctl -b should show the failure of loading the module if it is needed and missing.
I did the math and realized I hadn’t used my Windows VM in quite some time, all the things I wanted to do with it were past. So I pulled the extra GPU. Then I ran the cleanup/synchronize and reinstall that Jeff V suggested above. I could now reboot reliably, but with a black screen for typing in my LUKS passphrase.
Then it was just a matter of changing the grub argument “nvidia-drm.modeset” from “=0” to “=1”.
I am still interested in running a Windows VM with GPU acceleration; but I will hold off until I do some more research.