Stan, I found the cause of my particular problem. A few days ago I reran the "mkswap /dev/sda3" command... which, apparently, re-generated the UUID of that device. I did not put the new uuid into the grub.cfg file which has a line with this content "GRUB_CMDLINE_LINUX="resume=UUID=28cc21c5-3545-43c3-821a-653244b9493a nomodeset quiet net.ifnames=0 biosdevname=0 kernel.task_delayacct=1" Apparently dracut et. al. doesn't handle this situation very well or the message gets lost in the "clutter" the boot process generates. I fixed the file and reran the "grub2-mkconfig -o /boot/grub2/grub.cfg" command... then booted the system. Poof! It worked. It's strange to note that the 5.18 system booted just fine... even with this error condition present... apparently no strange messages or behavior either... It seems to me that this kind of error should get a lot more attention than it does currently. I appreciate your help and your time so THANKS for that. Best regards and STAY SAFE! George... On Sunday, October 23, 2022 at 08:01:24 AM PDT, stan <upaitag@xxxxxxxx> wrote: On Sat, 22 Oct 2022 21:51:07 +0000 (UTC) George R Goffe via test <test@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > Stan, > > Thanks for responding to this request for help. > > Here's my"ls -n" results. The 5.18 kernels all work and the 6.1 > kernel fails. The size doesn't necessarily mean that there aren't > libraries missing though. > > The smaller 5.18 initramfs file was created by my manual invocation > of dracut to build it but it STILL BOOTS. I suspect that the compression algorithm for the system created initramfs is different than the compression algorithm of the one you created manually. For what it is worth, I turned off compression of the initramfs to remove a variable during troubleshooting. And left it off as it only saves a few megs of drive space. Once, that was important, but in the days of terabytes, well, I don't think that is so important. Maybe for a raspberry pi? Or android? Internet of things? > As I stated, my "hang"is in dracut-pre-mount hooks processing. I > don't know enough about dracut to trouble shoot this any further. I'm > eager to learn though. Pointers to docs would be helpful. Is there a > ldd lookalike for initramfs? I could unpack the boot and bad > initramfs files and compare the libraries in both. This might give a > clue as to what's going on. If you look at man dracut , there are instructions on how to have dracut put out debug information. As I said, that produced nothing in my case because there wasn't a dracut error, just an initramfs build error. I'm not aware of an ldd for the initramfs. What I did is run ldd on libsystemd, libsystemd-core, and libsystemd-share to find what libraries were essential in order for systemd to start. Once systemd starts, it has the installed libraries of the system to use, and so it doesn't need anything else from the initramfs. If you want a quick and dirty method, just run a grep as follows on the two initramfs you are comparing to create two files, and then edit them side by side. Should be all on one line, email client wrapped it. grep -e 'lib*' initramfs[specification] > initramfs[specification]_libs.txt > > Around the point of this failure are what looks like something is > writing a script... just a few lines but zfs is referenced though. If you get debug output from dracut, that might illuminate the cause of that. > > I don't have this problem with a F38 VM (VirtualBox). Also, I do NOT > see any strange messages during system upgrade although dnf > apparently runs something that uses ALL memory or somehow triggers an > OOM kill event that kills the window manager and logs me off the > system. I wonder, if you are using f38, I've been seeing that dnf5, the new version of dnf written in c++(?), might be there. So it could be you are finding a bug. > I have only one system here... sigh... Is there no other way to get a > console that one could copy the output into a regular file? The debug instructions for dracut should accomplish this. > Any thoughts or suggestions would be appreciated. It is for this reason that I always have two versions of fedora installed. The current version and the previous one. When things like this happen, I have recourse to the previous version to debug the issue, and not lose access to a working system for other things. _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-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/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
