Bug 1977446
| Summary: | fresh install of 8.4 with luks volume fails to boot if /var is dedicated mount point | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | John Pittman <jpittman> |
| Component: | plymouth | Assignee: | Ray Strode [halfline] <rstrode> |
| Status: | CLOSED ERRATA | QA Contact: | Tomas Pelka <tpelka> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.4 | CC: | cbradsha, dtardon, hdegoede, msekleta, rmetrich, sbarcomb, systemd-maint-list, tpelka |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 8.5 | Flags: | pm-rhel:
mirror+
|
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | plymouth-0.9.4-10.20200615git1e36e30.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-09 18:52:26 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: | |||
|
Description
John Pittman
2021-06-29 18:39:38 UTC
I can reproduce at will, it's enough to have /var be on a dedicated partition and /home (or any other non-essential mount point) as a LUKS device. Booting with debug rd.debug systemd.debug-shell=1 on the kernel command line, I could collect the journal after switching to tty9 and I found this: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # grep "systemd-ask-password-plymouth" journal.txt.fail | cut -d' ' -f3,5- 11:28:15.795525 systemd[1]: systemd-ask-password-plymouth.path: ConditionVirtualization=!container succeeded. 11:28:15.795532 systemd[1]: systemd-ask-password-plymouth.path: ConditionPathExists=/run/plymouth/pid succeeded. 11:28:15.795546 systemd[1]: systemd-ask-password-plymouth.path: ConditionKernelCommandLine=!plymouth.enable=0 succeeded. 11:28:15.795575 systemd[1]: systemd-ask-password-plymouth.path: Changed dead -> waiting 11:28:15.795578 systemd[1]: systemd-ask-password-plymouth.path: Job systemd-ask-password-plymouth.path/start finished, result=done 11:28:16.183735 systemd[1]: systemd-ask-password-plymouth.path: Changed dead -> waiting 11:28:17.002991 systemd[1]: systemd-ask-password-plymouth.path: Got triggered. 11:28:17.002996 systemd[1]: systemd-ask-password-plymouth.service: Trying to enqueue job systemd-ask-password-plymouth.service/start/replace 11:28:17.003021 systemd[1]: systemd-ask-password-plymouth.service: Installed new job systemd-ask-password-plymouth.service/start as 271 11:28:17.003026 systemd[1]: systemd-ask-password-plymouth.service: Enqueued job systemd-ask-password-plymouth.service/start as 271 11:28:17.003031 systemd[1]: systemd-ask-password-plymouth.path: Changed waiting -> running 11:28:17.015320 systemd[1]: systemd-ask-password-plymouth.service: ConditionPathExists=/var/run/plymouth/pid failed. 11:28:17.015322 systemd[1]: systemd-ask-password-plymouth.service: Starting requested but condition failed. Not starting unit. 11:28:17.015326 systemd[1]: systemd-ask-password-plymouth.service: Job systemd-ask-password-plymouth.service/start finished, result=done 11:28:17.015330 systemd[1]: systemd-ask-password-plymouth.path: Got notified about unit deactivation. 11:28:17.015356 systemd[1]: systemd-ask-password-plymouth.path: Changed running -> waiting -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- From above, we can see that systemd-ask-password-plymouth.path starts watching the path used to request a passphrase. This ends up triggering systemd-ask-password-plymouth.service but the later fails, due to no having /var/run/plymouth/pid file. This happens because /var is a dedicated mount point, hence at the time switchroot happens, it's not mounted, hence /var/run which is a symlink to /run doesn't exist yet: it's created by systemd-tmpfiles-create.service which didn't execute yet since it will execute only once file systems are mounted. The solution here is to amend systemd-ask-password-plymouth.service unit to rely on /run/plymouth/pid instead, which can be done by creating a unit override: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # sed "s#^ConditionPathExists=/var/run/plymouth/pid#ConditionPathExists=/run/plymouth/pid#" /usr/lib/systemd/system/systemd-ask-password-plymouth.service > /etc/systemd/system/systemd-ask-password-plymouth.service -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- For users installing manually and not through a kickstart, they can use the following workaround to boot, then apply the sed command above: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- plymouth.enable=0 -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Minimal reproducer: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- ignoredisk --only-use=vda # Partition clearing information clearpart --none --initlabel # Disk partitioning information part swap --fstype="swap" --ondisk=vda --size=2048 part /home --fstype="xfs" --ondisk=vda --size=1026 --encrypted --luks-version=luks2 part / --fstype="xfs" --ondisk=vda --size=8192 part /boot --fstype="xfs" --ondisk=vda --size=1024 part /var --fstype="xfs" --ondisk=vda --size=2048 -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Note above: - /var is NOT encrypted and directly on disk (NO LVM). - /home is encrypted and directly on disk. Early boot services really shouldn't depend on any mounts with the exception of /, /run, and /tmp. Also, use of /var/run has been discouraged for about a decade now. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (plymouth bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4334 |