Sorry I didn't see this for 20 days...
On Thu, Oct 2, 2025, at 3:57 PM, Paolo Galtieri wrote: > > Folks, > this is the second system since F40 that has become unusable after a power > cycle. What happened is thunderbird became unkillable so I chose to reboot my > system. After 10 minutes of waiting to reboot I decided to hit the power > button. I have done this before on F40 and earlier systems without problems. > This happened on an F42 system a while ago, but In this case it is an F41 > system. After restarting the system the first problem is I saw the following > message > > systemd[1] Freezing execution > > Again I had to power cycle the system. The second time it showed the login > prompt for maintenance mode. I put in the root password, but nothing happened > so I hit ctrl-d. I got this message > > reloading system manager configuration > > But after 10 minutes nothing happened and no feedback so again I power cycled > the system. Again this time it came up in maintenance mode and I put in the > root password and after several minutes I got a root prompt. However, > nothing I type is displayed. The video seems really messed up as can be seen > in the attached photo. > > At this point I'm not sure what to do to recover. I agree this is super annoying. We can't even get the rdsosreport.txt out in order to see what the problem is. For some reason now we don't drop to a dracut shell, as if the initramfs contains /etc/shadow Because the default is to not set a root password, if the shadow file is in the initramfs, it means systemd will enforce root only access when boot fails. But root password isn't set. So we can do nothing. Well except we can... In the kernel command line use rd.systemd.debug-shell and you will get a root login on tty9 And at least here you can extract the rdsosreport.txt to a USB stick. Often startup failure happens before switch root which means the directory and file tree isn't organized in a familiar way. You can mount the USB stick to an arbitrary directory you create in /run or you can just mount to /sysroot which is what I do (probably sloppy) And then copy the rdsosreport.txt file to the stick and then post it somewhere so we can look at it. Based on the reporting, my best guess is you're hitting a bug. It could be a drive firmware bug, in which it does out of order writes by not honoring flush or fua commands correctly. No matter the file system, the expected write order needs to be honored in order for the file system to be in a consistent state following a crash or power failure. It also could be a file system bug, but we need to see the kernel report for the failed boot. And then what? Well if it's btrfs someone can bug me on matrix and I'll look at it and see what's going on. -- Chris Murphy
-- _______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
