I’ve recently invoked run0 dnf5 upgrade --refresh --offline -y && run0 dnf5 offline reboot -y, as I have countless times. However, after the OS reinitialised, the update has ceased to progress past “Relabelled [locations]”:
Long shot, but try hitting Esc a couple of times to go in and out of graphical boot mode.
I had a similar scenario recently (not identical, it wasn’t after an offline upgrade) where the system seemed to be stuck at relabelling on reboot, and that was enough to nudge it back to life for me.
@pg-tips, that just worked! What the heck?! I presume that I should report this to Plymouth…? Evidently, if you’ve also experienced it, it’s somewhat pervasive.
Apparently so! Yours is the first report I’ve seen of it - I must admit to not investigating mine very deeply, I just told myself I’d do so if it happened again.
Yes, it feels like something is up with the handon / handoff to the graphical boot, but I don’t have clear ideas on exactly where the fault is. Maybe start off with an RHBZ ticket against the Plymouth component?
@pg-tips, I know that that’s what I should do, but do you actually have any RHBZ tickets responded to? The sole ones that I ever see triaged are abrt tickets for SEGVs of gdb, and sealert tickets…
I saw this again today. In my case it was on the first reboot following a (“normal”, non-offline) dnf update which brought in a new version of selinux-policy and selinux-policy-targeted.
Again, hitting the Esc key twice got things moving.
I’ll add this to your bug to demonstrate that it’s not only offline updates that can trigger the issue.
For me, just hitting the Return key works. My systems are in multiple buildings so I often run sudo dnf5 offline reboot in an ssh session and have to go outside (in Canadian winter!) if a system doesn’t come up after a reasonable time.