Bug 2067031

Summary: Fedora 36 hangs on boot after dnf upgrade
Product: [Fedora] Fedora Reporter: Yuto Nishiwaki <nishiwakiyuto.per>
Component: systemdAssignee: systemd-maint
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 36CC: dtardon, fedoraproject, filbranden, flepied, lnykryn, msekleta, nishiwakiyuto.per, ryncsn, ssahani, s, systemd-maint, tschweikle, yuwatana, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-10-25 15:21:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshot on hanging none

Description Yuto Nishiwaki 2022-03-23 05:56:30 UTC
Created attachment 1867683 [details]
screenshot on hanging

Description of problem:
I couldn't boot my fedora 36 (pre-release) after DNF update on 2022.03.23 05:00 (UTC). I updated two machines at the same time and they both went into this state.
On startup, after a splash screen, a blank screen appears without a logon screen; removing the "rhgb quiet" option in grub causes it to hang with the message in the attached image. Using the emergency target would not boot as well, and also the kernel list in grub only had one selection for 36, the others could not boot.
After the hang, I could not switch consoles such as ctrl+alt+f3, but I could reboot using ctrl+alt+delete (at which time the usual splash or shutdown logs appeared).
These machines were upgraded from fedora 35 a few days ago.

Version-Release number of selected component (if applicable):
(system version)
fedora 36 x86_64
kernel:5.17.0-0.rc7.116.fc36.x86_64

How reproducible:
Every time

Steps to Reproduce:
Booting graphical(normal) target or emergency target

Actual results:
normal target with rhgb quiet options: hangs after splash and turn into blank screen
normal target without these options / emergency target : stops and hangs on the message in the attached image 

Expected results:
Logon screen displayed

Additional info:

Comment 1 David Tardon 2022-08-25 08:02:30 UTC
The boot failed because some services (e.g., dbus-broker.service or NetworkManager.service) failed to start. Seening that this happened after an update, I suspect wrong selinux label(s) on some file(s). Does it help if you boot with selinux=0? If it does not, you can boot with systemd.debug-shell: you'll get a shell at tty9 from which you can check the logs to (hopefully) get some information about why the failures happened.

Comment 2 Thomas Schweikle 2022-10-22 10:30:24 UTC
It is the same her. And there are two reasons why it hangs:
1. selinux. while booting dnf is not allowed to access the downloaded files
2. dnf likes to ask for confirmation -- but you'll never notice in graphical mode. And: it does not mater what you type. dnf will not receive any input.

Solution to 1: turn off selinux giving selinux=0 on kernel commandline
Solution to 2: turn off graphical mode by deleting "quiet" and "rh*" commands from kernel commandline. The confirmation is not requested then.

Comment 3 Zbigniew Jędrzejewski-Szmek 2022-10-25 15:21:37 UTC
Hmm, if selinux labelling failed, this would be an explanation. But I don't think we can fix it now.
In the future, please report the AVCs (journalctl -b<n> where <n> is -1 or -2 or so) would
be useful.

> Solution to 2: turn off graphical mode by deleting "quiet" and "rh*" commands from kernel commandline. The confirmation is not requested then.

No, this explanation doesn't make sense. The only way that dnf is called during upgrade
is with "offline upgrades", but in that case dnf is invoked so that no questions are asked.
And even if dnf wanted to ask questions, "quiet" and "rh*" on the kernel commandline wouldn't
affect dnf behaviour.

--

I'll close this bug as CANTFIX… If the issue occurs again, please reopen with logs. The more the better.