Darryl Gregorash composed on 2024-01-22 00:49 (UTC-0500):
If the kernel update somehow did not complete properly, then I doubt dracut/mkinitrd will resolve the issue.
Maybe it would, maybe it wouldn't. It's a troubleshooting step. We don't yet know what the issue causing the failure is. If the problem was just an error in creating the initramfs file, then dracut or mkinitrd alone should work. If there was an error somewhere else in the kernel update, running either of those would not succeed, and actually might make things worse.
Assuming that Marc cannot simply do a system rollback, would it make sense to a) boot into the previous kernel b) do an unconditional update on the following packages: kernel-default kernel-default-extra kernel-default-optional c) reboot ?
Looks like a longer, more complicated series of steps to me, which I'm in no position to test. /If/ he's on an recent installation, or is otherwise using btrfs and snapshotting, whether or not he accepted the partitioning defaults or otherwise configured btrfs and snapshotting, /then/ it's a path he could try. What What I just suggested there has nothing to do with the file system on /. Read the opening clause there, please. What I am suggesting is booting into the previous kernel, then doing an unconditional update -- nothing else -- on the new kernel packages. Then we can be assured that the kernel would be installed from beginning to end, including re-creating the initramfs (it's in the post-install
I suggested would work or not regardless his / filesystem, and whether or not snapshotting is available to him. Your way will require he reinstall all updates or wait for some of those to be installed again, plus new. My way he keeps all the updates unrelated to kernel and existing initrd. Both ways he's using the older kernel and doesn't know what went wrong until he does some troubleshooting. These describe options, not demands. What is "my way"? I suggested 2 ways, in fact -- one I know enough about to make a suggestion, _if_ the pre-conditions are satisfied (they're not, so we can forget about rollbacks now, yes?) The second method I had in mind actually was to roll back the kernel using the Yast snapper module. THAT I agree is a process that would take some work to get the job done. That is one reason I never went into it in more detail. Since then, a third method occurred to me -- as a result of your suggestion to use dracut or mkinitrd, in fact. As I have suggested, if
On 2024-01-22 00:37, Felix Miata wrote: scripts, after all). That would actually save a lot of time, as I rather imagine Marc would have quite a bit of work to do to learn how to use either dracut or mkinitrd in this situation. I know I would. Why not let the system do all that for you? there is a problem with the new kernel other than just an errant intitramfs, using either of those would be useless at best, problematic at worst. So why not force a refresh of those 3 kernel packages (they're the only ones involved in that update), and make sure it all gets done properly?
I'm wild-guessing his problem is either kernel backporting introduced a problem with his quite youthful CPU that escaped QA, or more likely, a backport introduced a need for NVidia driver update that has yet to become available, if even recognized.
If a kernel refresh/reboot fails to resolve the issue, then, yes, it becomes necessary to look beyond the kernel for problems.