An offline update has not progressed past relebelling for PT15M

Context / The Problem

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]”:

Of note is that SELinux is persistently set to permissive, but has never been disabled.

Desired Advice

I’ve left it in this state, for now, so:

  1. Should I Alt + SysRq + REISUB?

  2. Should I re-attempt the update?

  3. Should I disable SELinux?! I hope not.

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.

1 Like

@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.

1 Like

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?

1 Like

@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…

Regardless, I have filed bugzilla.redhat.com/show_bug.cgi?id=2435819. If it’s left to EOL when F44 releases, I’ll re-report it upstream.

1 Like

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.

1 Like

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.

2 Likes

Good incentive for a purely headless workflow :cold_face: :grinning_face: