Systemd hook compatibility

[JuniorJPDJ]

Hi,
I'm trying to make it work with systemd only hooks, I can't even see any messages connected with this hook, or getting ip address on my screen after bootup.
When I start fallback shell I don't have any IP address.
My initcpio hooks:
base systemd keyboard autodetect ssh-cryptsetup modconf sd-vconsole block bcache sd-lvm2 filesystems fsck

my mkinitcpio output

[root@Dell7010 ~]# mkinitcpio -p linux
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 4.18.5-arch1-1-ARCH
  -> Running build hook: [base]
  -> Running build hook: [systemd]
  -> Running build hook: [keyboard]
  -> Running build hook: [autodetect]
  -> Running build hook: [ssh-cryptsetup]
dropbear_dss_host_key : sha1!! 60:2e:48:ca:71:86:14:20:b2:b3:41:75:f4:49:05:1c:e2:f9:fa:32
dropbear_rsa_host_key : sha1!! af:ab:b0:ea:59:cc:fc:1a:9e:d0:ba:52:6f:26:94:fd:0e:60:db:23
dropbear_ecdsa_host_key : sha1!! 99:10:92:f4:0f:3a:9f:62:a3:66:0b:c0:3d:76:2f:cc:10:31:ad:9f
  -> Running build hook: [modconf]
  -> Running build hook: [sd-vconsole]
  -> Running build hook: [block]
  -> Running build hook: [bcache]
  -> Running build hook: [sd-lvm2]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating lzop-compressed initcpio image: /boot/initramfs-linux.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: 4.18.5-arch1-1-ARCH
  -> Running build hook: [base]
  -> Running build hook: [systemd]
  -> Running build hook: [keyboard]
  -> Running build hook: [ssh-cryptsetup]
dropbear_dss_host_key : sha1!! 60:2e:48:ca:71:86:14:20:b2:b3:41:75:f4:49:05:1c:e2:f9:fa:32
dropbear_rsa_host_key : sha1!! af:ab:b0:ea:59:cc:fc:1a:9e:d0:ba:52:6f:26:94:fd:0e:60:db:23
dropbear_ecdsa_host_key : sha1!! 99:10:92:f4:0f:3a:9f:62:a3:66:0b:c0:3d:76:2f:cc:10:31:ad:9f
==> WARNING: Possibly missing firmware for module: softing_cs
==> WARNING: Possibly missing firmware for module: wcn36xx
==> WARNING: Possibly missing firmware for module: at76c50x_usb
==> WARNING: Possibly missing firmware for module: atmel
==> WARNING: Possibly missing firmware for module: b43
==> WARNING: Possibly missing firmware for module: b43legacy
==> WARNING: Possibly missing firmware for module: ipw2100
==> WARNING: Possibly missing firmware for module: ipw2200
==> WARNING: Possibly missing firmware for module: orinoco_usb
==> WARNING: Possibly missing firmware for module: p54pci
==> WARNING: Possibly missing firmware for module: p54spi
==> WARNING: Possibly missing firmware for module: p54usb
==> WARNING: Possibly missing firmware for module: prism54
==> WARNING: Possibly missing firmware for module: rtl8723ae
==> WARNING: Possibly missing firmware for module: rsi_sdio
==> WARNING: Possibly missing firmware for module: rsi_usb
==> WARNING: Possibly missing firmware for module: zd1201
==> WARNING: Possibly missing firmware for module: zd1211rw
  -> Running build hook: [modconf]
  -> Running build hook: [sd-vconsole]
  -> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: aic94xx
==> WARNING: Possibly missing firmware for module: wd719x
  -> Running build hook: [bcache]
  -> Running build hook: [sd-lvm2]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating lzop-compressed initcpio image: /boot/initramfs-linux-fallback.img
==> Image generation successful

[suiryc]

This hook is only compatible with the legacy way of doing things.
systemd hooks work in a different manner. Basically legacy initrd loads the hook as a script and executes its run_hook function, while systemd is - as usual - relying on service units and the likes. Hence even if you add this hook to the list, while in systemd mode its script is not executed.

I'm not sure how much work is needed to make this compatible with systemd: can the script be called as-is through a systemd unit ? would dropbear need to be handled in a dedicated unit ? ...
Up to now I did not have to make it work with systemd - I actually did not know/remember there was a systemd-way of doing this. I'm still interested to take a look at it, but depending on the difficulty and how much time I can - and am willing to - spend on it, it may take a while before it is done (if at all possible).

[suiryc]

As an alternative, you can also try what is documented as Remote unlocking of the root (or other) partition.
Seems like there already are systemd tools for each necessary step (network, ssh, cryptsetup).

If it works as described, I guess there is even no need for me to update my hook.
Maybe even the other hooks mentionned (netconf, dropbear, ...) are so that what my hook do can be done as easily with those. The original legacy dropbear_initrd_encrypt AUR package, which was later split in those new hooks (as mentioned here), was not so easy to use at the time (which was one of the reasons that made me code my hook based on it).

[suiryc]

So I did a quick test with mkinitcpio-systemd-tool, and it should meet your needs.

Basically I

• added the systemd-tool hook, which comes with necessary systemd units etc
  • enabled the systemd initrd-network, initrd-cryptsetup and initrd-dropbear units (edit: the systemd units do not need to be enabled)
  • (on fresh install) had to manually create the systemd-network and systemd-resolve users/groups ^(*)
  • added the authorized public key in /etc/dropbear/authorized_keys
• added the sd-encrypt hook ^(**)
  • a few tests showed that it needs to be placed after systemd-tool
  • copied /etc/crypttab to /etc/crypttab.initramfs (the latter if present is included as /etc/crypttab inside the initramfs)
• re-generated the initramfs
• rebooted

The boot sequence now displays a prompt to enter the password:

secret>

The same prompt is displayed when connecting through SSH.


^(*) In systemd 2.39, those users are dynamic and not created in /etc/passwd and /etc/group, and this prevents the network service from properly starting (at least inside initrd). See mkinitcpio-systemd-tool ticket #17.
^(**) This makes initrd wait for partitions to be unlocked before continuing. Otherwise (in my test, I encrypt a partition that is not the system root) if the boot sequence reaches the point where sysroot is mounted (no password needed), it continues from the real root system and systemd-tool units are stopped (and later, after intrd, the password for such partitions is asked).
According to the boot sequence I would say it is because the initrd target was reached at which point we leave this state (and thus systemd-tool units are stopped because they only run within initrd).