You are not logged in.
Cheers,
I'm trying to get a fancy pants boot prompt working, but I've run into an issue with using a systemd-based initramfs.
Cobbling everything together from the wiki and whatnot, I've reached following mkinitcpio.conf:
$ cat /etc/mkinitcpio.conf | grep -v '^#' | sed '/^$/d'
MODULES="i915"
BINARIES=""
FILES=""
HOOKS="base systemd sd-plymouth autodetect keyboard sd-vconsole modconf block sd-encrypt sd-lvm2 filesystems fsck"There still seems to a bit of a concurrency issue here, though, as upon booting from the (thus far textmode) grub to Arch, I see the systemd-ask-password-console service being started (as the prompt is there) while plymouth hasn't booted up yet; I'm not sure if there's a plymouth setting stopping it from starting.
Anyhow, as soon as plymouth kicks in, it displays the plymouth splash screen, but it does never seem to get around to starting the plymouth password forwarder.
I'm guessing this is related to the fact that plymouth kicks in later than expected, but debugging is pretty hard; I need to drop back to console with Home and hammer enter three times so that the initramfs kicks me back to the emergency shell, and that seems to kill plymouth. So I can't check the service status of things like
systemd-ask-password-plymouth.service, as it's getting killed with plymouth, if it ever was running. journal isn't in the initramfs, so I can't check that either.journal gets passed on after boot, but shows no hint of issues with starting the service. It just didn't start it all.
The most likely other contender could be that
/run/plymouth/pidisn't generated properly;
/run/plymouthin general is nonexistent after dropping to the emergency shell, and the systemd service does have the pid file as a startup condition.
Anyone else have encountered similar problems, or a robust suggestion?
Last edited by towo (2017-09-27 11:32:49)
Offline
As always, the catharsis of actually writing about your question helps you debug it more thoroughly.
I've since found it that a lack of /run/plymouth is the actual issue, since /run is mounted as tmpfs, but /run/plymouth only gets generated during the mkinitcpio stage. Any hints on how to drop that in would be appreciated.
Offline
hwell.
The current würgaround is as follows:
$ cat /etc/initcpio/install/plymouth-pidfile
#!/bin/bash
build() {
add_systemd_unit plymouth-pidfile.service
}and
$ cat /lib/systemd/system/plymouth-pidfile.service
[Unit]
Description=Ensure plymouth pidfile rundir exists
DefaultDependencies=no
Wants=plymouth-start
After=systemd-udev-trigger.service systemd-udevd.service
Before=plymouth-start.service
ConditionPathExists=!/run/plymouth
[Service]
ExecStart=/usr/bin/mkdir /run/plymouth
Type=oneshot
[Install]
WantedBy=sysinit.targetThat at least makes it work.
Offline
As it happens I ran into this same issue earlier this week. I was about to jump in and see if I could replicate your fix when I saw you had already reached out on the plymouth aur page and a fix was already incorporated. For that I thank you.
I was going to point out systemd-tmpfiles as a cleaner way to make temp files, but the solution mtorromeo suggested is even cleaner. I'm bringing it up anyway just to spread some knowledge.
Btw, you ought to mark this as solved.
Offline
Well, I'd've said it isn't a tempfile, but I knew my solution was an evil hack as well. But mtorromeo showed me that I should always try to check systemd manpages for obscure parameters.
... and then I read up on tmpfiles and the wiki literally gives /run/samba as an example.
Last edited by towo (2017-09-27 11:34:59)
Offline