Arch Linux

This bug report ist quite old but still valid. I ran into the same issue again just minutes ago.
Any chance to get this fixes anytime soon?

From my experiments, if we want to use sulogin from busybox:
* mkinitcpio-busybox package needs to be updated to build sulogin (by adding CONFIG_SULOGIN=y, CONFIG_FEATURE_SHADOWPASSWDS=y and CONFIG_USE_BB_CRYPT_SHA=y to config file)
* a patch should be added since latest stable version has a bug since glib 2.17 changed the crypt() return value. See http://git.busybox.net/busybox/commit/?id=8ed96726603a59969b99e4ea30dbd9b06955084b
* /etc/shadow is required, so IMHO it needs to be added by the install file of the base hook
* /etc/gshadow is not required
* libcrypt.so.1 is also a dependency
* contrary to /sbin/sulogin, sulogin from busybox doesn't fallback on /bin/sh if the root shell (in /etc/passwd) does not exist, so we either need to add the root shell to the initrd or add Environment="SUSHELL=/bin/sh" to emergency.service

It seems there is no real gain from adding /sbin/sulogin (with libcrypt.so.1), /etc/shadow, and /etc/gshadow in the systemd hooks.

Also, rd.systemd.unit=emergency.target doesn't work, even with proper sulogin, because emergency.target is launched before everything else and kernel module for keyboard is not loaded.

So what is workaround?

I added systemd hook instead of udev, generated initramfs with just default mkinitcpio -p linux and because for some reason root failed to mount I got dropped to emergency shell but that failed with "/bin/sh: /sbin/sulogin not found" and I can't get past this. I don't know why root mount failed as I can't access shell...

You can create a file /etc/initcpio/install/sd-sulogin with the content

#!/bin/bash

build() {
# sulogin is needed for emergency target
add_binary /sbin/sulogin
add_file /etc/shadow
add_file /etc/gshadow
}

help() {
Add sulogin for systemd.
}

And then add the sd-sulogin hook.

Any news on if / how this is going to be fixed?

Here's a dirty trick which makes adding password files to the initrd optional. It adds the '--force' option to sulogin, which makes it start a root shell without asking for a password if no password file is found:

Create a file /etc/systemd/system/emergency.service.d/sulogin-force.conf with the content

[Service]
ExecStart=
ExecStart=-/bin/sh -c "/sbin/sulogin --force; /usr/bin/systemctl --fail --no-block default"

You can then change the file /etc/initcpio/install/sd-sulogin to have the content

#!/bin/bash

build() {
# sulogin is needed for emergency target
add_binary /sbin/sulogin
add_file /etc/systemd/system/emergency.service.d/sulogin-force.conf
}

help() {
Add sulogin for systemd.
}

if will be accepted decision to copy file "/etc/shadow" to initramfs , than it may be bad for cryptsetup/luks users.

in this case: cryptsetup/luks users will be still have strong protected/encrypted root and still have strong protected/encrypted "/home/", but file "/etc/shadow" has less protection (only sha512 with salt).

Why not add a new optional install hook to add the /etc/{,g}shadow files? Together with my suggestions for /etc/initcpio/install/sd-sulogin and /etc/systemd/system/emergency.service.d/sulogin-force.conf from above, one can have the best of both worlds: if the shadow files are present (added by the hook) ask for the root password, if not, simply start a root shell.

Add a file: /etc/initcpio/install/sd-shadow with content:

#!/bin/bash

build() {
# add shadow files for sulogin
add_file /etc/shadow
add_file /etc/gshadow
}

help() {
Add shadow files for sulogin so starting an emergency shell will ask for the root password.
}

Note: Personally I don't see much general use for storing password files in the initrd. Unless the system has some kind of hardware protection / encryption, anyone with physical access to the machine during early boot practically owns that part of the boot process anyway.

I'm the developer of several initcpio hooks, and currently I'm trying to port them to being systemd compatible. In some of them I need to generate (not copy) a /etc/passwd file. But I didn't needed yet to put neither shadow nor gshadow into the initrd. These are very sensitive files, not only because they contain the salted hashes of passwords, but they contain several hints at to what precisely a user has installed in the encrypted root partition.

If there is need for these files being in the initrd, let them be runtime generated with only the users/groups needed. Perhaps, we could even adopt having .initramfs(as is the case with crypttab) shadow and gshadow files, with different passwords/groups than those in the encrypted root partition. Although I believe this would put unnecessary burden on users.

Also, I never really liked this approach of needing to have separate sd-* hooks. So, I'm using declare -F add_systemd_unit from within my hooks to detect if a systemd initrd image is being generated and so I can install the proper units. In the case a "base" hook based initrd is being built, I install the needed binaries and runscript. And the common needed things don't need to be duplicated across normal and sd-* hooks.

By the way, looking at dracut source code, that's exactly what they do:

https://github.com/haraldh/dracut/blob/master/modules.d/00systemd/module-setup.sh#L180

They selectively update the /etc/passwd file with needed entries.

The lack of 'login' support, or dumping directly in to the initramfs single user mode console, caused me quite the headache last night.

Please elevate this to at LEAST normal priority, as it makes handling any other initramfs issue a nightmare.

Additionally, while my attempt at distilling the above suggestions did not have the desired outcome, I was at least able to log in once I added the password files.

The following, ALONG WITH, an sd-sulogin hook entry, allows for a working initramfs.

#!/bin/bash
# cat /etc/initcpio/install/sd-sulogin

build() {
add_binary /usr/sbin/sulogin
add_file /etc/passwd
add_file /etc/shadow
# This trick didn't work... add_file /etc/systemd/system/emergency.service.d/sulogin-force.conf
# sulogin is needed for emergency target
}

help() {
echo Add sulogin for systemd.
}

I was also just bitten by this.
I had put an external device into fstab. Worked fine at home. When on the road it was not there and boot failed. There was no way to boot anyway or edit fstab.
This is ridiculous.

Attached is a patch against `systemd` package which allows meaningful use of `rd.systemd.unit={rescue,emergency}.target` in kernel cmdline with systemd-based initcpio (given that `base` hook is enabled as well).
Starting with systemd 231 (the next release), there will also be `rd.rescue` and `rd.emergency` aliases for that.

This is about to hit [testing]. I was able to boot with 'rd.systemd.unit=rescue' and get a useful shell.