Arch Linux

Please read this before reporting a bug:

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

REPEAT: Do NOT report bugs for outdated packages!

FS#34345 - systemd won't boot; tries to run not-configured plymouth

Attached to Project: Arch Linux
Opened by kei (kei) - Sunday, 17 March 2013, 14:46 GMT
Last edited by Dave Reisner (falconindy) - Wednesday, 20 March 2013, 17:40 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To No-one
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


After yesterday's update (Mar 16) my system won't boot anymore. The red error message from "journalctl -xb" is "Failed at step EXEC spawning /bin/plymouth: No such file or directory". The strange thing: I've never used plymouth---at least not on purpose. Plymouth is not installed according to "pacman -Qs plymouth" and "grep -r 'plymouth' /etc" does not yield any result.

I'm cautious about altering stuff myself as I don't know much about systemd, but since this is the computer I use for work, I'd appreciate to hear of any quick workarounds.

Additional info:
* package version(s)
systemd 198-1
filesystem 2013.03-2
* config and/or log files etc.
I will try to extract them from the rescue shell if needed!

Steps to reproduce:
Boot the system.

I'd be glad to supply additional information; just let me know!
This task depends upon

Closed by  Dave Reisner (falconindy)
Wednesday, 20 March 2013, 17:40 GMT
Reason for closing:  Not a bug
Additional comments about closing:  User configuration error.
Comment by Dave Reisner (falconindy) - Sunday, 17 March 2013, 15:55 GMT
plymouth is not, nor has it ever been a requirement of systemd. There is a single hardcoded reference in the early startup of systemd that refers to plymouth -- it fails silently when plymouth isn't found. What you cite as an error sounds more like it comes from a unit file which you have lying around.
Comment by kei (kei) - Sunday, 17 March 2013, 17:02 GMT
I consulted the man page of journalctl once again and could now get all the errors:
# journalctl -xb -p err
... systemd[1]: Failed to load default target: No such file or directory
... kernel: microcode: failed to load file amd-ucode/microcode_amd.bin
... kernel: sp5100_tco: mmio address 0xb8fe00 already in use
... systemd[280]: Failed at step EXEC spawning /bin/plymouth: No such file or directory

I'm pretty sure that the second error has been there before (I think I forgot to install the amd ucode package), but I don't know about the others. How can I identify what's keeping the default target from loading? I didn't change anything in the unit files.
Comment by kei (kei) - Sunday, 17 March 2013, 17:19 GMT
Another note: if I do a "systemctl default" in the rescue shell, it boots up the system indeed. But: the graphics is just random colored lines on the screen after kdm starts (using a previously fully functional KDE).
Comment by kei (kei) - Monday, 18 March 2013, 21:40 GMT
well I understand that this only affects me and so it's severity has been set to low. But, please, help me with this as my computer is now UNUSABLE. I cannot revert the update and I'd really like to spare me setting up the system once again :/
Comment by Andrej Klič (lelio) - Monday, 18 March 2013, 22:47 GMT
You're not alone. I have the exact same problem as you. –After upgrading systemd-197-4 to 198-1 my boot stops, and I'm thrown to rescue mode. By journalctl -xb I see the same err message about failing to load default target and an failing to exec plymouth, which I had never installed.
If I jump out of rescue mode with C-d, system boots normally to my awesomewm desktop (I have autologin configured with SLiM). Here I observe second weird thing, if I logout of my awesomewm session, SLiM suddenly hangs. Or when I try to poweroff instead of logout, systemd-198-1 has trouble to shut down SLiM service, as it takes extra time.

Solution for me: downgrade back to systemd-197-4 lib32-systemd-197-1 systemd-sysvcompat-197-4 and lurk in this bug thread :(
Comment by Johannes Schlatow (vali) - Monday, 18 March 2013, 23:03 GMT
Same problem here:

-- Unit has finished starting up.
-- The start-up result is done.
Mar 18 12:31:18 vali-notebook mtp-probe[1892]: checking bus 2, device 2: "/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-2"
Mar 18 12:31:18 vali-notebook mtp-probe[1893]: checking bus 2, device 3: "/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-6"
Mar 18 12:31:18 vali-notebook mtp-probe[1893]: bus: 2, device: 3 was not an MTP device
Mar 18 12:31:18 vali-notebook mtp-probe[1892]: bus: 2, device: 2 was not an MTP device
Mar 18 12:31:21 vali-notebook kernel: bio: create slab <bio-1> at 1
Mar 18 12:31:21 vali-notebook mkswap[1937]: Setting up swapspace version 1, size = 2000056 KiB
Mar 18 12:31:21 vali-notebook mkswap[1937]: no label, UUID=97890cc8-fe0f-4505-88a9-0df49b699e68
Mar 18 12:31:25 vali-notebook systemd[1946]: Failed at step EXEC spawning /bin/plymouth: No such file or directory
-- Subject: Process /bin/plymouth could not be executed
-- Defined-By: systemd
-- Support:
-- Documentation:
-- The process /bin/plymouth could not be executed and failed.
-- The error number returned while executing this process is 2.
Comment by kei (kei) - Tuesday, 19 March 2013, 01:32 GMT
Thanks, downgrading to 197 is also effective as a workaround for me. Looking forward to a definitive solution :-)
Comment by Alessandro Doro (adoroo) - Wednesday, 20 March 2013, 13:37 GMT
I had the same problem in one system. Following I found the solution and removed a leftover runlevel indication in the grub kernel command line.

A little research showed me that this is nota bug.
From systemd(1):
2, 3, 4, 5
Boot into the specified legacy SysV runlevel. These are equivalent to, ...

In systemd-198-1 the symlinks are removed.
See commit 245d345f7539983c08fd8dbc0c51079422ca096a, build-sys: link runlevel targets on install only if sysv compat is enabled,
Comment by kei (kei) - Wednesday, 20 March 2013, 17:37 GMT
Indeed, that was the problem! Thank you very much!