Does not work with RHEL8
krbvroc1 opened this issue · comments
Just came across this project while migrating from dracut-crypt-ssh on Centos 7 to RHEL8.
This project does not seem to work with RHEL8.
Upon booting, the console requests the passphrase be entered PRIOR to ssh being started.
I tried to debug this some by looking at the debug logs and such...
I believe the issue is the following two lines add:
dracut-sshd/46sshd/sshd.service
Lines 7 to 8 in 31eecda
I commented out those 2 lines and it now works. Is it possible that by adding an 'After' for a target that does not exist on RHEL8, you have delayed the start of the sshd.service?
I commented out those 2 lines and it now works. Is it possible that by adding an 'After' for a target that does not exist on RHEL8, you have delayed the start of the sshd.service?
It's possible but it would surprise me.
I mean After= is documented as:
If a unit
foo.service contains a setting Before=bar.service and both units
are being started, bar.service's start-up is delayed until
foo.service has finished starting up. Note that this setting is
independent of and orthogonal to the requirement dependencies as
configured by Requires=, Wants= or BindsTo=. [..]
After= is the inverse of Before=, i.e. while After=
ensures that the configured unit is started after the listed unit
finished starting up, Before= ensures the opposite, that the
configured unit is fully started up before the listed unit is
started.
(emphasis mine)
As I understand it, After=X.service in Y.service does nothing if Y.service is started without X.service.
This should also hold when X.service simply doesn't exist.
See also: https://serverfault.com/a/1096424/63769
Are you certain that RHEL 8 doesn't have systemd-tmpfiles-setup.service?
Another possibility is that systemd-tmpfiles-setup.service exists in RHEL 8 early boot environment and is started together with sshd.service, but some other unit that provides the unlocked LUKS volume has something like Before=systemd-tmpfiles-setup.service set and thus blocks sshd from being started. But this would also surprise me.
FWIW, when I look around in the early boot environment of a Fedora 35 system, systemd-tmpfiles-setup.service is definitely started before the LUKS disk is unlocked.
Can you inspect the dependencies in your early boot environment a bit?
Perhaps commands like the ones below help to show what's going on.
systemctl list-dependencies --after systemd-tmpfiles-setup.service
systemctl list-dependencies systemd-tmpfiles-setup.service
systemctl list-dependencies --after sshd
systemctl list-dependencies sshd
Oddly, in order to provide the info you I restored the After=systemd-tmpfiles-setup.service line and re-ran 'dracut -f -v' to regenerate. However, this time it worked (at least one time).
initramfs-ssh:/root# systemctl list-dependencies --after systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service
● ├─system.slice
● ├─systemd-journald.socket
● ├─systemd-sysusers.service
● └─local-fs.target
● └─local-fs-pre.target
● ├─memstrack.service
● └─systemd-tmpfiles-setup-dev.service
initramfs-ssh:/root# systemctl list-dependencies systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service
● └─system.slice
initramfs-ssh:/root# systemctl list-dependencies --after sshd
sshd.service
● ├─system.slice
● ├─systemd-journald.socket
● └─systemd-tmpfiles-setup.service
initramfs-ssh:/root# systemctl list-dependencies sshd
sshd.service
● └─system.slice
Could the time (or times) where your sshd didn't start be caused by sshd being blocked by insufficiently available entropy?
See also the second FAQ item in the README. That item discusses the issue in the context of VMs, but it might also happen on certain bare-metal systems.