Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#36265 - [systemd] does not work

Attached to Project: Arch Linux
Opened by Gerardo Exequiel Pozzi (djgera) - Wednesday, 24 July 2013, 17:24 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 18 June 2016, 19:00 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 13
Private No


Description: I am testing "systemd" initcpio hook.
The /sbin/sulogin is not added by "systemd" hook since is a non-hard dep (-/sbin/sulogin) and is not enabled in mkinitcpio-busybox

* Create a new "emergency" hook or add needed things to "systemd":
* Enable sulogin in mkinitcpio-busybox and see if hard needs /etc/{,g}shadow
* Use /sbin/sulogin [util-linux] (deps on {also /etc/shadow and /etc/gshadow is needed}
* symlink sulogin to sh and avoid credentials (just like current init::break= parameter)

Additional info:
This task depends upon

Closed by  Dave Reisner (falconindy)
Saturday, 18 June 2016, 19:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  systemd-230-5
Comment by Christian Hesse (eworm) - Thursday, 04 September 2014, 07:28 GMT
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?
Comment by Jean-Philippe Garcia Ballester (giga) - Thursday, 16 October 2014, 06:06 GMT
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
* /etc/shadow is required, so IMHO it needs to be added by the install file of the base hook
* /etc/gshadow is not required
* 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, /etc/shadow, and /etc/gshadow in the systemd hooks.

Also, doesn't work, even with proper sulogin, because is launched before everything else and kernel module for keyboard is not loaded.
Comment by Dāvis (davispuh) - Saturday, 29 November 2014, 12:44 GMT
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...
Comment by Jean-Philippe Garcia Ballester (giga) - Monday, 01 December 2014, 00:44 GMT
You can create a file /etc/initcpio/install/sd-sulogin with the content


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.
Comment by Alain Kalker (ackalker) - Friday, 30 January 2015, 04:01 GMT
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

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


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.
Comment by Andrei Antonov (pl_m) - Saturday, 31 January 2015, 06:18 GMT
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).
Comment by Alain Kalker (ackalker) - Saturday, 31 January 2015, 19:02 GMT
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:


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.
Comment by Giancarlo Razzolini (grazzolini) - Friday, 07 August 2015, 03:13 GMT
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.
Comment by Giancarlo Razzolini (grazzolini) - Friday, 07 August 2015, 16:26 GMT
By the way, looking at dracut source code, that's exactly what they do:

They selectively update the /etc/passwd file with needed entries.
Comment by Michael J Evans (mjevans) - Thursday, 08 October 2015, 00:55 GMT
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.

# 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.
Comment by Philipp (hollunder) - Saturday, 30 January 2016, 12:29 GMT
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.
Comment by Ivan Shapovalov (intelfx) - Tuesday, 14 June 2016, 07:39 GMT
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.
Comment by Dave Reisner (falconindy) - Saturday, 18 June 2016, 13:50 GMT
This is about to hit [testing]. I was able to boot with 'rd.systemd.unit=rescue' and get a useful shell.