On Sat, 26 Aug 2023 13:02:12 +0100 Paul Smith <phhs80@xxxxxxxxx> wrote: > On Fri, Aug 25, 2023 at 4:23 PM stan via users > <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > I have been able to take a screen-shot: > > > > > > https://i.imgur.com/nAsE6i6.jpg > > > > This means that dracut was unable to start systemd in order to > > continue the boot once the initramfs was finished creating the > > bootstrap. I have had this happen, but not with stock kernels. I > > build custom kernels, and dracut was not building a complete > > initramfs when they were installed. I had to write a script that > > created a custom file that told dracut to include all missing > > libraries, and run dracut again after install to fix the problem. > > The missing libraries included some vital systemd libraries. > > Because library versions change, I run the script to be sure that > > the custom file includes the latest libraries. If this *is* the > > cause, it will be obvious in /boot. The failing initramfs size will > > be about half the size of an initramfs file that works. I could > > not find any reason that dracut wasn't working properly when it > > first installed the kernel; all the settings said it should have > > put those libraries in, but I just could not get it to do so. > > > > If it is your issue, post back and I'll attach the file of > > libraries and the directory to put it in, as well as the dracut > > command to run. They might not work for you, since the version has > > to be included. There is also a way to actually examine what is in > > the initramfs, so you could see if the systemd libraries were > > there. From the dracut man page, > > > > Inspecting the Contents > > To see the contents of the image created by dracut, you can > > use the lsinitrd tool. > > > > # lsinitrd | less > > > > To display the contents of a file in the initramfs also use > > the lsinitrd tool: > > > > # lsinitrd -f /etc/ld.so.conf > > include ld.so.conf.d/*.conf > > Thanks to all for your help! > > I have meanwhile been able to take photos from the > > journalctl -xb > > output, and I think that now the cause of the problem is isolated. > > I was hopeful that the new kernel update would fix the problem, but > it did not. > > The photos of the journalctl logs are at: > > https://i.imgur.com/NJAjOmN.jpg You didn't show the listing of the /boot directory. ls -n /boot/ or ls -n /boot/initramfs* Is the initramfs for the failing kernel smaller than the initramfs for the successful kernel? If you can still boot into an older kernel, you can try rebuilding the initramfs manually, to see if it will fix any problem. You have to run this within the /boot directory, as root or sudo. Your command should be something like the following. # /usr/bin/dracut -f -v --no-compress --no-uefi initramfs-6.4.11-200.fc38.x86_64.img --kver 6.4.11-200.fc38.x86_64 I use no compression and no uefi, but you can remove those if they don't fit your system. Once you have a new initramfs, run lsinitrd on it and redirect it into a file. Do the same for a working initramfs. Then run a diff on the two with the output piped to less. For example, lsinitrd /boot/initramfs-6.4.11-200.fc38.x86_64.img > new_initramfs.txt lsinitrd /boot/initramfs-6.4.8-200.fc38.x86_64.img > old_initramfs.txt diff old_initramfs.txt new_initramfs.txt | less There should be almost no differences if the initramfs is OK. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
