After the last couple of updates of Tumbleweed (I’m at 20220916 now running on a Ryzen-based system) I’ve found that I’m unable to reboot following the update process. I would typically issue:
sync; sync; sync; shutdown -r now
but when I do that, a slew (10 or so) these messages appear:
“block device autoloading is deprecated and will be removed”
Those are followed with a message about “callbacks” (being suppressed; I’d have to take a photo of the console for the precise wording as I haven’t seen it in any logs) followed by more deprecation warnings and callback messages. I’ve found that deprecation message appearing in /var/log/warn going back to June but recently (the last few updates) the system will stay in a loop issuing that pair of messages seemingly forever until I, eventually, take manual action.
After manually halting the system (pressing and holding the power button) and it’s powered back up, because the system had to be abruptly killed, it will force me to go into maintenance mode. The recovery process has been:
df (and note that, hmm... no btrfs filesystems got mounted)
cat /etc/fstab (to see what btrfs filesystems are defined
mount each unmounted btrfs filesystem by hand
sync; sync; sync
shutdown -h now
power cycle and, happily, the system comes up without any problems
Since this started happening, my quick-n-dirty workaround is to, post-update, simply issue the "sync"s and “shutdown -h now” commands as rebooting with “shutdown -r now” seems to be broken.
Questions:
What, if any, device is causing this message to be displayed? There is nothing in the message itself nor in any logs AFAICT noting the device involved.
Is there a system configuration setting that I’ve somehow missed making following a prior update that’s causing the reboot failure?
What other information might be helpful for me to post to help to resolve this problem?
Well… that systemctl command worked though I’ll probably never be certain that it wasn’t because of something included in the most recent set of updates. I didn’t try “shutdown -r now” this time as I didn’t want to spend the time running through the workaround I’d been using had that been necessary. I’ll try “shutdown -r” next time and see. Maybe poking around in the systemd directories will show what is being done when using the “reboot” option.
After the latest batch of updates I installed, I went ahead and used “sync; sync; sync; shutdown -r now” with no ill effects. The previous update session likely included something that corrected the problem I initially reported. I’m calling this one solved. Cheers…