Package Details: plymouth 22.02.122-1

Git Clone URL: (read-only, click to copy)
Package Base: plymouth
Description: A graphical boot splash screen with kernel mode-setting support
Upstream URL:
Licenses: GPL
Submitter: PirateJonno
Maintainer: Taijian
Last Packager: Taijian
Votes: 573
Popularity: 4.61
First Submitted: 2009-08-12 04:16 (UTC)
Last Updated: 2022-01-11 20:24 (UTC)

Pinned Comments

Taijian commented on 2021-03-29 09:40 (UTC)


Due to the fact that plymouth stable releases by upstream are few and far between, I'd like to recommend to anyone experiencing stability issues or bugs to try out the plymouth-git package as a basic troubleshooting step, because many bugs will already have been fixed there.

Latest Comments

Benjamin commented on 2022-06-10 11:59 (UTC)

@iib verify that you have installed base-devel. I was facing the same problem as you, thinking I had base-devel installed already, until I double checked and realized I had not.

iib commented on 2021-12-15 23:00 (UTC)

help! I see error: /home/user/aur/plymouth/src/plymouth-0.9.5/configure: line 15525: syntax error near unexpected token IMAGE,' /home/user/aur/plymouth/src/plymouth-0.9.5/configure: line 15525:PKG_CHECK_MODULES(IMAGE, libpng >= 1.2.16 )' ==> ERROR: A failure occurred in build().

Cromer commented on 2021-10-30 17:24 (UTC)

@Wings-Fantasy, the deps are fine, the problem is on your end, to build from the AUR you are supposed to have base-devel installed which includes autotools and autoreconf.

Wings-Fantasy commented on 2021-10-30 13:14 (UTC)

It seems that a dependency is missing, and the autoreconf command was not found in the error on line 4 of ./

whynothugo commented on 2021-10-27 13:14 (UTC) (edited on 2021-10-27 13:15 (UTC) by whynothugo)


Taijian commented on 2021-10-27 08:35 (UTC)

@whynothugo: You are right. Changed without version bump.

whynothugo commented on 2021-10-21 11:41 (UTC)

Why is the gdm-plymouth.service symlink included?

The link is broken and systemd reports over and over this when applying presets.

It seems that it's no longer recommended or necessary anyway:

whynothugo commented on 2021-07-26 14:02 (UTC)

Yup, I misread you. :P

ArthurBorsboom commented on 2021-07-26 13:25 (UTC)

@whynothugo, I think you misunderstood me. I tried to explain that all packages of base-devel ahould not be included as make dependencies, such as automake and patch. I believe you said the same thing, so we should be aligned.

ArthurBorsboom commented on 2021-07-26 13:25 (UTC)

@whynothugo, I think you misunderstood me. I tried to explain that all packages of base-devel ahould not be included as make dependencies, such as automake and patch. I believe you said the same thing, so we should be aligned.

ArthurBorsboom commented on 2021-07-26 13:25 (UTC)

@whynothugo, I think you misunderstood me. I tried to explain that all packages of base-devel ahould not be included as make dependencies, such as automake and patch. I believe you said the same thing, so we should be aligned.

whynothugo commented on 2021-07-26 13:04 (UTC)

@ArthurBorsboom All those packages are part of base-devel. From the link you posted:

The group base-devel is assumed to be already installed when building with makepkg. Members of this group should not be included in makedepends array.

ArthurBorsboom commented on 2021-07-26 11:41 (UTC)

@ljdswer285 Packages patch, autoconf, automake should not be included as make dependencies.


ljdswer285 commented on 2021-07-26 09:37 (UTC)

Some make dependencies are not included in pkgbuild. Such as patch, autoconf and automake

Taijian commented on 2021-07-04 10:51 (UTC) (edited on 2021-07-04 10:51 (UTC) by Taijian)

@mephinet: Please see this Wiki entry:

TL:DR - This has been fixed upstream but no new release seems to be forthcoming any time soon. If you want the fix, please switch to the -git package here on the AUR (or badger the upstream people about doing a new release...).

mephinet commented on 2021-07-04 10:14 (UTC)

FYI, something that should be addressed: A warning reported by systemd:

systemd[1]: /usr/lib/systemd/system/plymouth-start.service:15: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.

avrelaun commented on 2021-04-23 16:38 (UTC)

@Taijian: Followup on my external monitor issue, since I bought a thunderbolt dock I no longer have the issue, I guess the kernel must load these later on and not conflict with Plymouth anymore

m.schabhuettl commented on 2021-04-21 19:21 (UTC)

@Sanras yeah sure. Just install the plymouth-git package. Everything should work out of the box. I just had to re-set my plymouth theme.

Sanras commented on 2021-04-21 19:08 (UTC)

@m.schabhuettl, thank you for the info, that's good to know. Since plymouth-git conflicts plymouth, does that mean I can just install plymouth-git right now, and it will replace normal plymouth without any further configuration necessary?

m.schabhuettl commented on 2021-04-21 18:54 (UTC) (edited on 2021-04-21 18:59 (UTC) by m.schabhuettl)

@Sanras Got exactly the same problem. Changing to plymouth-git fixes the issues.But the latest commit of plymouth-git has problems with AUR helpers (showing there is a newer version even if there isn't).

Sanras commented on 2021-04-21 17:38 (UTC)

Seems that after the latest sddm update, plymouth now also breaks sddm.

When I boot up, the boot screen displays, goes away, and then the system freezes at a black screen.

I have found two fixes for the issue. One is to rollback the sddm package, which fixes the issue.

Removing splash from boot parameters and booting without the animation also fixes the issue. This is why I suspect this is an issue to do with plymouth.

Hopefully this gets fixed soon. It seems that plymouth is getting more and more broken.

Taijian commented on 2021-03-29 09:40 (UTC)


Due to the fact that plymouth stable releases by upstream are few and far between, I'd like to recommend to anyone experiencing stability issues or bugs to try out the plymouth-git package as a basic troubleshooting step, because many bugs will already have been fixed there.

Taijian commented on 2021-03-23 19:47 (UTC)

@avrelaun: This is a pity. I had hoped (sorta) that your's might just be #118, because the fix for that is already in plymouth-git. But if that doesn't help...

Could you maybe open a new bug report upstream and link it here for posterity?

avrelaun commented on 2021-03-23 13:32 (UTC)

@Taijian: Tried plymouth-git, also updated the UEFI to the latest version, same problem. As for the issues, #102 is different (it does not just flickers but hangs all outputs to black with blinking cursor), and #118 might be similar. It's on a ThinkPad X1C7 with intel GPU.

Taijian commented on 2021-03-23 10:02 (UTC)

@avrelaun: Also, could you try out plymouth-git and see if maybe the issue is already fixed there?

Taijian commented on 2021-03-23 10:00 (UTC)

@avrelaun: Could you check these two upstream bugs and report back if either one fits with your issue?

Also: What kind of setup do you have? GPU(s), UEFI update status, ...

avrelaun commented on 2021-03-22 15:03 (UTC)

Whenever I boot my laptop plugged to my 4k hdmi monitor, the splash screen appears only on my laptop screen, then both screens go black with just a blinking cursor on the top left corner.

I then have to force off, boot again with the hdmi unplugged and then I see my encrypted disk prompt as expected. Anyone else ?

Taijian commented on 2021-03-20 10:53 (UTC)

@RealOrRandom: You are probably right - this seems to be related to this - which, in my defense, is also linked from the issue I referenced earlier. So, I stand by my earlier assertion: Upstream & kernel devs are both working on it, not much I can do here to try to outsmart them.

RealOrRandom commented on 2021-03-20 10:32 (UTC)

@Taijian: I think this is a different issue. I can confirm Sanras' observations.

But the upstream issue #141 seems different: it is only about showing the vendor logo. The vendor is part of the observations that Sanras describes but that's just an artifact. The issue here is that shutdown takes much longer than before.

Taijian commented on 2021-03-20 10:23 (UTC)

@Sanras: After looking at this upstream issue, there does not seem to be much that we can do about it at the moment. Apparently plymouth upstream is in contact with the kernel devs and talking about this, and I personally would not presume to be more savvy about solving this than that bunch...

Sanras commented on 2021-03-19 18:53 (UTC) (edited on 2021-03-19 18:53 (UTC) by Sanras)

After the Linux update to 5.11.x, I have an issue with Plymouth when shutting down the PC. After starting the shutdown, the animation plays as usual. Normally, it would finish shutting down in about 3-4 secs, and turn off. But with 5.11, the animation plays, then screen goes black, sits there for a second, and then flashes back on and displays the last frame of the boot animation that was on screen when the display went black. Sits there for 10 secs, then finally turns off. This seems to be an issue with Plymouth, another user reported the same thing and mentioned that disabling plymouth solves the issue. Is there anything I can do to fix the issue without getting rid of plymouth?

tinywrkb commented on 2021-02-26 15:31 (UTC) (edited on 2021-02-26 15:36 (UTC) by tinywrkb)

@Taijian I was very general in my message and I feel you took it the wrong way, I'm sorry that you feel this way.
Also, I wouldn't take the time to post here if I didn't think other users wouldn't appreciate this update.
Considering your response, I switched to maintain my own package and won't post here anymore.

Taijian commented on 2021-02-26 15:13 (UTC) (edited on 2021-02-26 15:14 (UTC) by Taijian)

@tinywrkb: I am very sorry to hear that you are unhappy with the service level provided by me. May I suggest you address this with my supervisor?

Sarcasm aside - I agree that shipping broken packages would not constitute 'great service'. On the other hand, this package is very much not broken, working very fine and merely outputting a warning in the journal at startup. If you cannot live with that until a new release comes out AND feel unable to run with the -git package that I maintain for people not wanting to wait for new releases - such as myself - then, I am afraid, I simply cannot help you. However, if you continue addressing me in the very unfriendly manner that you exibited in your last post, I am afraid I WILL learn to just ignore you.

Have a great day!

tinywrkb commented on 2021-02-26 15:06 (UTC)

@Taijian I'm avoiding VCS packages on my stable systems unless I'm testing something specific, I'm not a guinea pig, I like my systems being stable.
If an upstream stable release is broken, it's expected to bump to a recent commit or cherry-pick it.
If a maintainer doesn't do so then the package is useless for the users and they will just switch away.
Note that this is a public repository, the maintainer volunteered to give a service to the users, and shipping a package with bugs is not a great service.

I would like to see this resolved here and avoid maintaining another private package.

Taijian commented on 2021-02-26 14:38 (UTC)

@tinywrkb: May I suggest you check out plymouth-git?

I intend to let this package strictly follow official upstream releases - for everyone who wants to stay more up-to-date, there is the -git package.

tinywrkb commented on 2021-02-26 14:19 (UTC)

Please bump the version to checkout c74b3aef9c34c1c51b2c9c14f10f2906925ed380 now that the KillMode fix is merged.
Considering it took 6 months to merge this minor change, I would not be surprised if we would have to wait another half year for a new release.

Taijian commented on 2021-01-17 12:01 (UTC)

@sxul07: again, I'd like refer you to the upstream issue. If you genuinely want to help resolve this issue, please work with upstream on this.

This is the stable release package of plymouth. I will only include support for 'new' methods once they are enabled upstream in an official release. plymouth-git will pick them up once they get merged upstream.

sxul07 commented on 2021-01-17 03:51 (UTC) (edited on 2021-01-17 03:52 (UTC) by sxul07)

@Taijian I try to solve this problem, maybe it can be for your reference:

        if cryptsetup isLuks ${resolved} >/dev/null 2>&1; then
            [ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated
            if [ ! -e "/dev/mapper/${cryptname}" ]; then
                # If keyfile exists, try to use that
                if [ -f ${ckeyfile} ]; then
                    if eval cryptsetup --key-file ${ckeyfile} luksOpen ${resolved} ${cryptname} ${cryptargs} ${CSQUIET}; then
                        echo "Invalid keyfile. Reverting to passphrase."
                # Ask for a passphrase
                if [ ${dopassphrase} -gt 0 ]; then
                    echo "A password is required to access the ${cryptname} volume:"
                    plymouth ask-for-password --prompt="Password for ${cryptname} volume" --dont-pause-progress --number-of-tries=5 --command="/sbin/cryptsetup luksOpen --key-file=- ${resolved} ${cryptname} ${cryptargs} ${CSQUIET}"
                    sleep 2
            if [ -e "/dev/mapper/${cryptname}" ]; then
                if [ ${DEPRECATED_CRYPT} -eq 1 ]; then
                    export root="/dev/mapper/root"
                err "Password succeeded, but ${cryptname} creation failed, aborting..."
                exit 1
        elif [ -n "${crypto}" ]; then

Taijian commented on 2021-01-16 21:03 (UTC)

@sxul07: Please see this upstream issue about clevis support:

I cannot include something here that hasn't even been implemented upstream yet.

sxul07 commented on 2021-01-16 19:48 (UTC)

Clevis hook is not supported, please check luks device is already unlock before ask for password

tba commented on 2020-11-13 14:42 (UTC)

@rharish, yes, you are right. I've missed that. Thanks.

rharish commented on 2020-11-13 14:38 (UTC)

@tba pkgconf is part of base-devel, so it's not needed. This is mentioned here:

tba commented on 2020-11-13 14:36 (UTC)


Thanks for packaging.

I've got this error

..../plymouth/src/plymouth-0.9.5/configure: line 11825: syntax error near unexpected token `IMAGE,'
..../plymouth/src/plymouth-0.9.5/configure: line 11825: `PKG_CHECK_MODULES(IMAGE, libpng >= 1.2.16 )'

PKG_CHECK_MODULES needs pkg-config. So pkgconf should be added to makedepends.

ArthurBorsboom commented on 2020-09-01 18:52 (UTC)

@Taijian, regarding the systemd warning, an upstream bug report has been created.

kamil commented on 2020-08-22 21:20 (UTC) (edited on 2020-08-23 19:09 (UTC) by kamil)

@Taijian sorry but now the latest change breaks my sddm. Right after the loading screen when the sddm is suppose to load, the screen flashes, turns black, and the plymouth animation shows again for a brief moment. It keeps doing that in an endless loop unless I hit F1 which shows the console and after a while sddm loads fine. It seems as if something prevents the sddm from starting up and causes it to crash.

Reverting back to 0.9.5-4 solves the issue.

Edit: 0.9.5-6 seems to be working fine.

rharish commented on 2020-08-22 14:56 (UTC)

@Taijian I can confirm; it works. Thanks, and hope you're well now!

maoxuner commented on 2020-08-22 14:37 (UTC)

It works well now. Thx @Taijian

Taijian commented on 2020-08-22 12:44 (UTC)

OK, sorry to everyone who had trouble with the last update.

Lessons learned: Do not make changes late at night just prior to getting sick - you might screw up and then not be able to fix things for several days...

milouse commented on 2020-08-22 09:49 (UTC) (edited on 2020-08-22 09:50 (UTC) by milouse)


I think you forgot to remove gdm-plymouth.service, lightdm-plymouth.service and sddm-plymouth.service files from the repository: even if they are not used anymore, we still have to download/check them.

henrik_er commented on 2020-08-22 08:14 (UTC)

@taijian Can confirm I have the same issue as @maoxuner and @rharish here. Removing splash in kerenel params let me boot, but without animations. If I don't do this I have to do "" or lower to get in.

maoxuner commented on 2020-08-22 02:44 (UTC)

@rharish I have the save issue. I tried to disable splash in kernel params, then lightdm started successfullly but the boot animate didn't show.

rharish commented on 2020-08-21 10:37 (UTC) (edited on 2020-08-21 10:38 (UTC) by rharish)

@Taijian The latest change (0.9.5-4) broke my plymouth+lightdm configuration. After plymouth would finish, I would get a black screen (with the backlight still on), but lightdm wouldn't start. After reverting back to 0.9.5-3, I observed that if I used lightdm-plymouth.service, it worked well, but I got the same errors as 0.9.5-4 (which symlinked lightdm-plymouth.service to lightdm.service) if I used lightdm.service. Could you look into this issue? This prevents me from using the latest plymouth.

Taijian commented on 2020-08-19 18:44 (UTC)

@ArthusBorsboom: This is an upstream issue. Please see here:

Feel free to open an issue on the upstream bug tracker. :)

ArthurBorsboom commented on 2020-08-17 07:00 (UTC)

[    2.090346] systemd[1]: /usr/lib/systemd/system/plymouth-start.service:15: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.

Taijian commented on 2020-08-10 20:40 (UTC)

@kostas213: Please note that automake is part of base-devel, which in required for any and all AUR packages.

Please see:

kostas213 commented on 2020-08-10 20:11 (UTC) (edited on 2020-08-10 20:12 (UTC) by kostas213)

I got the following error while installing the package using yay:

Can't exec "aclocal": No such file or directory at /usr/share/autoconf/Autom4te/ line 326.
autoreconf: failed to run aclocal: No such file or directory
./ line 6: /tmp/makepkg/plymouth/src/plymouth-0.9.5/configure: No such file or directory

I just needed to install automake and then everything worked. Just mentioning it in case it's useful for somebody else.

Taijian commented on 2020-08-09 10:47 (UTC)

@rhysperry111: You are right, the new update should fix this problem. Sorry!

@marzzzello: Could you try building this without an AUR helper? For me, it builds fine in a clean chroot, so I'm not sure what exactly the source of your problem is.

rhysperry111 commented on 2020-08-09 08:51 (UTC) (edited on 2020-08-09 08:52 (UTC) by rhysperry111)

With the fix you included for the missing fonts on the initcpio you hardcoded a font.

It leads to this error on systems without the font installed when running mkinitcpio:

==> ERROR: file not found: `/usr/share/fonts/TTF/DejaVuSans.ttf'

You could either add DeJaVuSans to the dependencies, or work out a way to automatically select a font that the user does have installed. Upstream they seem to reference /usr/lib/plymouth/plymouth-populate-initrd bu I have no idea how that works

marzzzello commented on 2020-08-09 07:58 (UTC) (edited on 2020-08-11 13:23 (UTC) by marzzzello)

I get the following error in build (same in -git version):

checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
/home/marzzzello/.cache/yay/plymouth/src/plymouth-0.9.5/configure: line 11825: syntax error near unexpected token `IMAGE,'
/home/marzzzello/.cache/yay/plymouth/src/plymouth-0.9.5/configure: line 11825: `PKG_CHECK_MODULES(IMAGE, libpng >= 1.2.16 )'
==> FEHLER: Ein Fehler geschah in build().
    Breche ab...
error making: %!s(func() string=0x563685bd1a60)

EDIT: Fixed now with 0.9.5-3

Taijian commented on 2020-08-07 19:28 (UTC)

@RealOrRandom: Thanks for the heads-up! I'll try to look into it over the weekend and put together an update.

RealOrRandom commented on 2020-08-07 14:40 (UTC)

Some files are not copied to the initrd when using disk encryption with systemd hooks:

Apparently it turns out that this our bug:

rhysperry111 commented on 2020-05-28 08:11 (UTC)

@gui_user It should work if you follow the instructions at

gui_user commented on 2020-05-28 08:05 (UTC)

Is this working on a default installation?

rhysperry111 commented on 2020-05-26 09:40 (UTC)

Hi, is anyone else having problems booting with encrypted root?

If I unlock while plymouth is running it hangs, but if I press esc and then unlock my boot works normally

ZinStack commented on 2020-04-16 19:53 (UTC)

Not sure if anyone noticed, but getty cannot start because plymouth-quit-wait.service hangs the system in a starting state. Stopping it manually will kinda fix it, it will drop out of session and will need to restart gdm-plymouth to log back in, perhaps just unexpected system state change or some gnome stuff idk. Not critical, but very annoying

avrelaun commented on 2020-04-08 15:31 (UTC)

@nullptr_t while you're at it, could you please update the old arch logo and replace it with the new one ? Here's the one I made and used for a while now, specifically sized to be a drop-in replacement in /usr/share/plymouth/arch-logo.png, and it's also a transparent png:

drlorente97 commented on 2020-04-04 22:26 (UTC)

@nullptr_t please add RemainAfterExit=true to plymouth-start.service and plymouth-read-write.service. This can be easily done with a patch.

avrelaun commented on 2020-04-01 16:31 (UTC)

As suggested in the systemd previouly mentionned, adding RemainAfterExit=yes on both plymouth-start.service and plymouth-read-write.service fixes the problem. This package service files need to be updated to fix it for all users.

Subs commented on 2020-03-20 12:12 (UTC)

Hi, Since systemd 245, plymouth start screen never stops. See issue (direct link to the fix) here

diabonas commented on 2020-03-11 11:13 (UTC) (edited on 2020-03-11 11:13 (UTC) by diabonas)

@TheJackiMonster patch and autoconf are part of the base-devel group, which is assumed to be always installed when building packages. They should never be included in makedepends.

RealOrRandom commented on 2020-03-11 10:23 (UTC) (edited on 2020-03-11 10:24 (UTC) by RealOrRandom)

If (after the systemd update to v245) you suffer from a bug that the plymouth screen appears at random times even after the boot process has completed and renders your system unusable, one of the following workarounds is sufficient:

  • Add the line "RemainAfterExit=yes" to the [Service] section in /usr/lib/systemd/system/plymouth-start.service OR
  • "sudo systemctl mask plymouth-start.service" (and unmask after the issue has been fixed in plymouth)

Plymouth will be fixed soon, see

TheJackiMonster commented on 2020-03-05 21:50 (UTC)

Installing the package requires 'patch' and 'autoconf'. So these should be added to the makedepends at least.

NuBz commented on 2020-01-19 17:06 (UTC) (edited on 2020-01-19 17:10 (UTC) by NuBz)


Thank you for the response I will check it out again in a bit and see what happens.

Edit: Just tried and all is fine.

aminvakil commented on 2020-01-19 06:38 (UTC)

@Nubz As we're speaking now the link to freedesktop is: which as far as I'm seeing can be downloaded without problems.

NuBz commented on 2020-01-18 22:37 (UTC)

Cloning git no longer works since it will not download from

Obviously not the maintainers fault just wanted it to be known.

francoism90 commented on 2019-11-03 08:53 (UTC)

Could you please update to the github link instead? :) Seems FD is down.

StewartLittle commented on 2019-07-12 19:14 (UTC)

This doesn't work for me it keeps defaulting to fall back mode and not using the actual theme, I've set fbdev in modules as well as nvidia in modules in mkinitcpio.conf but it still won't work. What am I missing? Plymouth-legacy worked like a charm but that got removed from AUR.

flamusdiu commented on 2019-03-21 01:22 (UTC)

Anyone notice that is down atm? =\

stweller commented on 2019-03-12 19:28 (UTC) (edited on 2019-03-13 15:32 (UTC) by stweller)

The plymouth hook seems to need the DejaVu fonts by default, so shouldn't this depend on ttf-dejavu?

[edit] Sorry, forget about that. Just saw the optional dependency.

nullptr_t commented on 2019-03-01 13:08 (UTC) (edited on 2019-03-01 13:13 (UTC) by nullptr_t)

Does anyone experience issues with the compile option --enable-gdm-transition without gdm?

MatthewTrescott commented on 2019-02-23 20:06 (UTC)

@nullptr_t I suggest adding systemd-logind.service to the After= line for sddm-plymouth.service. Without that, SDDM sometimes gets started before logind which means that the shut down/restart/sleep buttons don't work on the login screen.

zerophase commented on 2019-02-12 17:44 (UTC)

@nullptr_t I'm booting with a minimal initramfs. Dropped udev from initramfs. I do get a warning message about not having udev. Should plymouth be capable of working without udev?

I just want to make sure I have the right idea about how plymouth works. How I currently boot is I get the bios logo -> rEFInd boot loader (switch to white screen) -> default linux kernel (changes to terminal once fsck outputs). If plymouth is working correctly I should keep the bios logo till the kernel prints the results of fsck right?

nullptr_t commented on 2019-02-11 09:53 (UTC)

It depends. If you are using systemd in you initramfs, you do not need to use udev [0]. If you are not using systemd, you should use the udev hook.


zerophase commented on 2019-02-11 01:53 (UTC)

Should plymouth work properly with initramfs without udev?

marlemion commented on 2019-01-21 21:33 (UTC) (edited on 2019-02-04 17:12 (UTC) by marlemion)

Same problem with fbdev: I see the theme with three dots (default theme). The custom theme breeze is not loaded.

UPDATE: Solution: I had to add the btrfs module to be loaded in grub. Don't know why it worked beforehand, though.

nullptr_t commented on 2019-01-21 17:31 (UTC)

Yes, you need to install xf86-video-fdev and add it to the modules of you mkinitcpio.conf

You don't need to advance in testing, I'll test it. Just give the possible solution a try. Yes, there is a difference between the hooks 'sd-plymouth' and 'plymouth'.

For plymouth I always use and have used fbdev with drivers like nvidia loading with xorg-server after plymouth with fbdev. fbdev is also suggested by the plymouth developers [1].


marlemion commented on 2019-01-21 09:52 (UTC)

Would that include installing xf86-video-fbdev and adding modules="fbdev" instead of radeon? I will try that tonight.

There is no difference between the two hooks in initcpio.

Unfortunately, I cannot track the issue down to the version. I remember it not working for a few months, but I did not look into it. However, the system has been kept in sync with upstream very closely (daily updates).

nullptr_t commented on 2019-01-21 05:06 (UTC) (edited on 2019-01-21 05:24 (UTC) by nullptr_t)

Did you try xf86-video-fbdev for Early KMS? Is it the new release (0.9.4) for you or didn't it work for a longer period of time? Does the regular initcpio hook without systemd work better for you? Does the text mode work?

I'll have a review on the package to make it use fbdev for a better compatibility.

marlemion commented on 2019-01-20 13:46 (UTC) (edited on 2019-01-20 13:48 (UTC) by marlemion)

Since a few months (five or so) plymouth does not work with any other themes (in particular breeze) anymore. Instead, I get the three squares from the standard theme.

My graphic card is a radeon HD 6850M and, yes, I am including the radeon driver into the initramfs. I must also add that displaying the themes worked beforehand without any problem.

Sometimes when rebooting I can see the breeze splash when shutting down.

cat /etc/plymouth/plymouthd.conf

Distribution defaults. Changes to this file will get overwritten during

[Daemon] Theme=breeze ShowDelay=1 DeviceTimeout=3

cat /etc/mkinitcpio.conf

BINARIES=() FILES=(/etc/modprobe.d/noacer.conf) HOOKS=(base systemd sd-plymouth autodetect modconf block filesystems keyboard fsck) MODULES="radeon"

This also happens with the udev/plymouth hooks.

I have also 'quiet splash' in the grub kernel command line.

pacman -Qi plymouth Name : plymouth Version : 0.9.4-1 Beschreibung : A graphical boot splash screen with kernel mode-setting support Architektur : x86_64 URL : Lizenzen : GPL Gruppen : Nichts Stellt bereit : plymouth Hängt ab von : libdrm pango systemd Optionale Abhängigkeiten : ttf-dejavu [Installiert] Benötigt von : breeze-plymouth Optional für : Nichts In Konflikt mit : plymouth-git plymouth-legacy plymouth-nosystemd Ersetzt : Nichts Installationsgröße : 1670,00 KiB Packer : Unknown Packager Erstellt am : Sa 01 Dez 2018 19:05:50 CET Installiert am : Sa 01 Dez 2018 19:07:43 CET Installationsgrund : Ausdrücklich installiert Installations-Skript : Nein Verifiziert durch : Nichts

Any idea what might be the culprit? It is working with exactly the same config files (apart from the video driver) on another pure intel laptop.

edarblanco commented on 2019-01-18 01:58 (UTC)

Problem to display manager on kernel version < 4.20, X server not working

StewartLittle commented on 2018-12-11 18:22 (UTC)

No problem, if you do put it in community could the arch-logo theme that's based on Ubuntu's plymouth theme be added as well maybe in a plymouth theme package which might include other themes from aur. Could this be considered?

FFY00 commented on 2018-12-11 17:42 (UTC)

I got sidetracked with other stuff. Thanks for remembering me. I'll revaluate the situation.

FFY00 commented on 2018-12-11 17:42 (UTC)

I got sidetracked with other stuff. Thanks for remembering me. I'll revaluate the situation.

StewartLittle commented on 2018-12-11 17:38 (UTC)

I thought this was heading to the community repository? It's been a few months since FFY00 said it would and as of now it hadn't appeared in the official repository nor the testing repository, is there a reason for the delay????

nullptr_t commented on 2018-09-06 07:07 (UTC)

I recommend to decrease the number of --number-of-tries from the commit .

nullptr_t commented on 2018-09-06 06:29 (UTC) (edited on 2018-09-06 06:29 (UTC) by nullptr_t)

Yes, that is okay for me. Since the last release the package includes the first patch after the 0.9.3 release, a patch from a non-stable version, that was requested. The modifications in the releases since 0.9.3-1 where requested.

FFY00 commented on 2018-09-01 15:26 (UTC)

I am interested in moving this to [community]. Is this ok with you?

tintypemolly commented on 2018-08-13 06:30 (UTC)

I think the maintainer can update this package to include the #include <sys/sysmacros.h> patch. glibc recently made its major version upgraded 11 days ago in the Arch official repository, presumably removing the #include <sys/sysmacros.h> in its header. The patch itself made its way into the plymouth's official repo, but there has been no release since then. So, for the time being, there is no other way than patching it to make it build.

tintypemolly commented on 2018-08-13 06:04 (UTC) (edited on 2018-08-13 06:05 (UTC) by tintypemolly)

@ABOhiccups Download the patch. Assuming path to the patch file is /path/to/sysmacros.patch, 1. Open PKGBUILD and look for prepare() function. 2. Append patch -p1 -i /path/to/sysmacros.path at the end of the function. 3. Do makepkg stuffs as usual.

ABOhiccups commented on 2018-08-12 20:09 (UTC) (edited on 2018-08-12 20:09 (UTC) by ABOhiccups)

@koassim How do I use a patch? This link is from Gentoo. We're on Arch Linux.

koassim commented on 2018-08-10 12:26 (UTC)

If you are unable to compile with the following error: /usr/bin/ld: libply-splash-core/.libs/ undefined reference to minor' /usr/bin/ld: libply-splash-core/.libs/ undefined reference tomajor'

Use the patch from here:

rocky7x commented on 2018-07-24 14:58 (UTC)

Any idea how to get plymouth to show graphical password prompt for non-root luks partitions? plymouth-encrypt hook is not usable here and the only thing I get is the text password prompt "behind" the splash...

14mRh4X0r commented on 2018-06-09 18:50 (UTC) (edited on 2018-06-09 18:51 (UTC) by 14mRh4X0r)

Reloading systemd with systemctl daemon-reload triggers plymouth-start.service, hence switching to the boot splash. I'm a GNOME user, and when using X, switching back to the proper VT is all that's needed, but when using Wayland, switching back causes the following messages in the journal and needs a restart of gdm to recover:

Jun 09 20:34:13 vischium sudo[1775]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jun 09 20:34:13 vischium systemd[1]: Reloading.
Jun 09 20:34:14 vischium sudo[1775]: pam_unix(sudo:session): session closed for user root
Jun 09 20:34:14 vischium systemd[1]: Starting Setup Virtual Console...
Jun 09 20:34:14 vischium systemd[1]: Started Setup Virtual Console.
Jun 09 20:34:14 vischium systemd[1]: Starting Show Plymouth Boot Screen...
Jun 09 20:34:14 vischium systemd[1]: Received SIGRTMIN+20 from PID 1824 (plymouthd).
Jun 09 20:34:14 vischium systemd[1]: Started Show Plymouth Boot Screen.
Jun 09 20:34:14 vischium kernel: rfkill: input handler enabled
Jun 09 20:34:15 vischium gnome-shell[634]: Failed to apply DRM plane transform 0: Permission denied
Jun 09 20:34:15 vischium gnome-shell[634]: Failed to set power save mode for output eDP-1: Permission denied
Jun 09 20:34:15 vischium org.gnome.Shell.desktop[634]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Jun 09 20:34:15 vischium org.gnome.Shell.desktop[634]: > Warning:          Unsupported maximum keycode 374, clipping.
Jun 09 20:34:15 vischium org.gnome.Shell.desktop[634]: >                   X11 cannot support keycodes above 255.
Jun 09 20:34:15 vischium org.gnome.Shell.desktop[634]: > Warning:          Unsupported high keycode 372 for name <I372> ignored
Jun 09 20:34:15 vischium org.gnome.Shell.desktop[634]: >                   X11 cannot support keycodes above 255.
Jun 09 20:34:15 vischium org.gnome.Shell.desktop[634]: >                   This warning only shows for the first high keycode.
Jun 09 20:34:15 vischium org.gnome.Shell.desktop[634]: > Internal error:   Could not resolve keysym XF86WWAN
Jun 09 20:34:15 vischium org.gnome.Shell.desktop[634]: > Internal error:   Could not resolve keysym XF86RFKill
Jun 09 20:34:15 vischium org.gnome.Shell.desktop[634]: > Internal error:   Could not resolve keysym XF86Keyboard
Jun 09 20:34:15 vischium org.gnome.Shell.desktop[634]: Errors from xkbcomp are not fatal to the X server
Jun 09 20:34:15 vischium gnome-shell[634]: Failed to set CRTC mode 1920x1080: Permission denied
Jun 09 20:34:15 vischium kernel: gnome-shell[634]: segfault at 20 ip 00007f38fb899d37 sp 00007ffcc8b73610 error 4 in[7f38fb794000+183000]
Jun 09 20:34:15 vischium systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Jun 09 20:34:15 vischium systemd[1]: Started Process Core Dump (PID 1829/UID 0).
Jun 09 20:34:15 vischium org.gnome.Shell.desktop[634]: (EE) failed to read Wayland events: Broken pipe
Jun 09 20:34:15 vischium gnome-session[626]: gnome-session-binary[626]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11
Jun 09 20:34:15 vischium polkitd[574]: Unregistered Authentication Agent for unix-session:c1 (system bus name :1.30, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) (disconnected from bus)
Jun 09 20:34:15 vischium gnome-session-binary[626]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11
Jun 09 20:34:15 vischium gnome-session-binary[626]: Unrecoverable failure in required component org.gnome.Shell.desktop
Jun 09 20:34:15 vischium at-spi-bus-launcher[679]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1024"
Jun 09 20:34:15 vischium at-spi-bus-launcher[679]:       after 21 requests (21 known processed) with 0 events remaining.
Jun 09 20:34:16 vischium systemd-coredump[1830]: Process 634 (gnome-shell) of user 120 dumped core.

This makes plymouth rather unusable for me, but I do like my boot splash. Is it something with my configuration or is it something with plymouth?

For completeness' sake, this is what happens when booted with plymouth.enable=0:

Jun 09 20:37:46 vischium sudo[1618]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jun 09 20:37:46 vischium systemd[1]: Reloading.
Jun 09 20:37:46 vischium sudo[1618]: pam_unix(sudo:session): session closed for user root
Jun 09 20:37:46 vischium systemd[1]: Starting Setup Virtual Console...
Jun 09 20:37:46 vischium systemd[1]: Started Setup Virtual Console.

minextu commented on 2018-04-25 14:51 (UTC)

Please add to the plymouth-encrypt hook. See line 22 in

CarterCox commented on 2018-04-06 18:31 (UTC)

Does anyone know how to get this working? The wiki guide doesn't cut it for me. It gets stuck showing boot messages and then nothing.

Cromer commented on 2018-03-15 13:56 (UTC)

@ganthore pkg-config should not be in any dependencies on any packages. It is part of the group "base-devel" and should be on all systems that build packages by default. If you don't have that package installed, that means your system is incorrectly configured and you should install base-devel group.

ganthore commented on 2018-03-15 00:10 (UTC)

You need to add pkg-config as a dependency.

step21 commented on 2017-11-29 17:59 (UTC)

Hi, it seems plymouth has some overlap with some files by geoclue/geoclue2 in /usr/share/gtk-doc/html/geoclue This seems a very unnecessary conflict, as it seems it has not business with these files, so could this conflict maybe be avoided?

hdante commented on 2017-11-27 01:26 (UTC)

Hello, I can confirm the problem with gdm-plymouth.service, when used, it breaks systemd startup with the message "A start job is running for Hold until boot process finishes up", blocking gettys and cosole logins.

zeroxfourc commented on 2017-11-06 19:29 (UTC)

Hey, please consider using a stronger hash algoritm than MD5 (for example SHA256) and a HTTPS download link such as this one:

sylveon commented on 2017-10-15 19:08 (UTC)

With the gdm-plymouth service, it is impossible for me to use a TTY, because it shows me the following instead of a login prompt: [*** ] A start job is running for Hold until boot process finishes up (system uptime here / no limit)

zerophase commented on 2017-10-15 14:28 (UTC)

Is anyone else getting a white screen when UEFI booting? The plymouth boot spinner comes up eventually, but only for a second or 2 before getting into the desktop. After booting with rEFInd shouldn't the plymouth boot spinner come up right away?

nullptr_t commented on 2017-10-13 17:12 (UTC)

For anybody having troubles with plymouth themes after the new release from upstream, please refer to post #6 of this thread:

towo commented on 2017-09-22 07:31 (UTC)

@mtorromeo: Uuuh, that's way nicer. Didn't know about that one.

nullptr_t commented on 2017-09-21 17:14 (UTC) (edited on 2017-09-21 17:16 (UTC) by nullptr_t)

@mtorromeo, @towo: I was going to place an "ExecStartPre = mkdir -m 755 -p /run/plymouth" into the [Service] section to address the pid file problem, but I think @mtorromeos solution is more pleasing fashion.

mtorromeo commented on 2017-09-21 17:01 (UTC)

@towo, @nullptr_t: Just add "RuntimeDirectory = plymouth" to the [Service] section of the systemd unit to delegate the creation of /run/plymouth to systemd.

towo commented on 2017-09-21 10:46 (UTC)

Cheers; when going for a complete systemd initramfs with sd-encrypt, systemd-ask-password-plymouth never starts up because it depends on a pidfile existing in /run/plymouth/; since the systemd hook initializes /run as tmpfs, the add_dir from the install script is useless. My current würgaround is including a systemd service to create /run/plymouth if necessary (, but this should probably be fixed in a more pleasing fashion.

nullptr_t commented on 2017-09-06 08:38 (UTC)

Thanks, is changed in the 0.9.2-2 release.

digitalcube commented on 2017-09-05 18:27 (UTC)

I think there may be a small typo in plymouth.encrypt_hook line 79: ${cryptdev} should be ${resolved} like in the vanilla encrypt hook. That would allow PARTUUID to be used to identify the encrypted device.

r3b311i0n commented on 2017-08-24 03:02 (UTC)

No services are duplicated, it just shows the same message twice before "Started Deactivate Plymouth Boot Screen", and I don't have any HOOKs set twice. Also, if I use official gdm instead of gdm-plymouth, the duplication doesn't occur.

nullptr_t commented on 2017-08-23 21:58 (UTC) (edited on 2017-08-23 22:03 (UTC) by nullptr_t)

I could not find any duplications in there (by human eyes). The journal messages are following the scheme t - Mounting /mnt/data... t+x - Mounted /mnt/data If your boot screen output differs from log: Does your initcpio maybe have a HOOK set twice (/etc/mkinitcpio.conf)?

r3b311i0n commented on 2017-08-19 01:33 (UTC) (edited on 2017-08-20 02:56 (UTC) by r3b311i0n)

Thanks for the reply @nullptr_t It's an HP Envy 15. HD4600 (modesetting driver) + GeForce GT-740m using nvidia proprietary with Bumblebee + bbswitch. Bootloader: systemd-boot kernel params: root=PARTUUID=02531cbb-14c0-4888-b1e3-a096e60d1106 quiet splash loglevel=3 acpi_backlight=vendor nvidia-drm.modeset=1 rw Journal for systemd - The issue is very similar to this I've tried with the nvidia card on both early and late KMS with the same result. I've also noticed that the last few service messages (the ones after "Started Deactivate Plymouth Boot Screen") do not get duplicated. Thanks again for the help :)

nullptr_t commented on 2017-08-18 13:52 (UTC)

Can you provide some more details on journal and configuration please?

r3b311i0n commented on 2017-08-18 12:13 (UTC)

I'm getting duplicated boot messages after the 0.9.3-1 upgrade. > Optimus system. > Using gdm-plymouth. Downgrading to 0.9.2-14 fixes this.

sovanyio commented on 2017-08-16 20:25 (UTC)

@Aetf, odd it worked for me here and for plymouth-git. The add_full_dir command is probably cleaner anyway.

Aetf commented on 2017-08-16 18:09 (UTC)

@sovanyio, @nullptr_t This doesn't work for me. Still only normal files were added to initcpio. Here's the gist I'm using: Note the add_full_dir call replaced the whole for loop. Thanks

nullptr_t commented on 2017-08-16 07:14 (UTC)

Thanks to both! The patch is included in the new release.

sovanyio commented on 2017-08-15 17:54 (UTC) (edited on 2017-08-15 18:06 (UTC) by sovanyio)

For anyone struggling to get themes to work during boot--this is the fix alluded to by Aetf: /lib/initcpio/install/plymouth @nullptr_t please integrate

petris commented on 2017-07-30 16:02 (UTC)

For anyone else with the "a start job is running to Hold until boot process finishes up" issue, masking the plymouth-quit-wait service worked for me: systemctl mask plymouth-quit-wait.service It appears that this still has the "nice" transition between the plymouth startup screen and GDM (i.e., no black screen flicker), though I noticed that now, on restart/shutdown, the plymouth graphic is no longer displayed. I can deal with that though, I just wanted the screen to not switch back to the console on bootup.

0dd17y commented on 2017-07-28 14:52 (UTC) (edited on 2017-07-28 14:54 (UTC) by 0dd17y)

Hi, I am having an issue with plymouth which displays splash screen however causes boot to hang (using Grub2 and auto-login to tty1 - without DM/WM) on VirtualBox. sd-plymouth hook is being used and delay is set to 1. However if I press ESC during splash screen (and get textual output) it boots normally to tty1. Also another thing is that if I set delay to 0 I get past splash screen but the theme is some gray background with white squares. (attached screenshot) Any advice on this is appreciated. Thank you.

nullptr_t commented on 2017-06-30 08:05 (UTC)

@carmelo12341 Thanks for the reference. I included that sd-plymouth.initcpio_install hook in the 0.9.2-13 release

commented on 2017-06-29 17:10 (UTC)

@nullptr_t maybe he is refering to this

nullptr_t commented on 2017-06-06 08:49 (UTC)

What kind of hook do you mean? Plymouth is added to the initrd, systemd services for the display managers are included. Do you mean something like the plymouth-start.service?

prMoriarty commented on 2017-06-03 03:17 (UTC)

nullptr_t please add systemd hook

nullptr_t commented on 2017-04-13 17:06 (UTC) (edited on 2017-04-13 17:07 (UTC) by nullptr_t)

I agree with TingPing. If you want pkgconf for building your packages, you can manually install it until it joins base-devel. plymouth builds fine with pkg-config, so there is no need to add pkgconf to any package providing .pc files.

TingPing commented on 2017-04-12 22:32 (UTC)

> please consider adding pkgconf as an optional dependency since the original pkg-config under base-devel package group is deprecated pkgconf provides pkg-config so thats what you would depend upon. Even then deprecated is a strong word and it would be very silly for literally every AUR package to add a dep to pkg-config.

jc-aur commented on 2017-04-12 22:29 (UTC)

please consider adding pkgconf as an optional dependency since the original pkg-config under base-devel package group is deprecated

nullptr_t commented on 2017-03-19 20:07 (UTC) (edited on 2017-03-19 20:08 (UTC) by nullptr_t)

plymouth is part of you kernels's initramfs and gets build into it while building the image. You have to change that in your /etc/mkinitcpio.conf. I have no experience with plymouth and systemd hooks yet, but works fine for me with grub and UEFI.

zerophase commented on 2017-02-24 04:40 (UTC)

I can't get plymouth to display a boot screen. I'm using rEFInd, UEFI, and proprietary Nvidia KMS. The shutdown screen shows up, but during boot I just get a white background. Where the systemd output should be I do have a black screen covering it up, but no icon. So, I think Plymouth is definitely loading up, but not for rEFInd. Should there be any files added to the boot partition for plymouth?

differ commented on 2017-02-21 02:12 (UTC)

@ArchangeGabriel: Thank you, now that is ok!

Archange commented on 2017-02-20 21:19 (UTC)

@differ: Looks like you’re trying to build with only the PKGBUILD. As you can see on this very same page, they are 17 sources for this packages, from which 16 are local ones. If you want to build using makepkg, you should download a whole snapshot from the link in the menu on the right (

differ commented on 2017-02-20 19:34 (UTC)

Hello, I'm trying to get plymouth. When I run makepkg command I get following error: ==> ERROR: arch-logo.png was not found in the build directory and is not a URL. Can anyone tell me what to do with it?

garwil commented on 2017-01-05 12:52 (UTC)

@Koterpillar You can fix the missing font issue by copying /etc/fonts/conf.d/60-latin-free.conf to /etc/fonts/conf.d/60-latin.conf

kubrick commented on 2017-01-02 13:10 (UTC)

Reply to myself, I fixed the issue by adding the i915 module my initramfs, it all works great now.

kubrick commented on 2017-01-02 07:56 (UTC)

is plymouth-encrypt supposed to work UEFI systems? When plymouth prompts for my luks password, it's echoed in plaintext in the console and doesn't work...

jpprovost commented on 2016-11-13 08:22 (UTC)

Hi there! Is it normal that plymouth-quit-wait.service takes around 22s of my boot time? Thanks,

Aetf commented on 2016-11-04 23:19 (UTC)

Hi, the plymouth.initcpio_install script is incompatible to breeze-plymouth[1] theme. In addition to normal files under /usr/share/plymouth/themes/breeze/, this theme also has a images folder at /usr/share/plymouth/themes/breeze/images/. In the plymouth.initcpio_install script, around line 37, it checks and skips all non-file children under the folder. I'm not sure I understand the reason why not just add the whole themes/${PLYMOUTH_THEME_NAME} folder to initramfs, maybe there are other themes that puts non-related files in the theme folder? Missing images folder is causing problems like blank screen when ask password input should be shown, as reported in the breeze-plymouth package. [1]:

lomapur commented on 2016-10-09 11:20 (UTC)

The problem with "a start job is running to Hold until boot process finishes up" running indefinitely is still there for me with sddm-plymouth.service. Anyone has any fix/workaround for that one already? Thanks guys! :)

mjkillough commented on 2016-09-18 15:19 (UTC)

Thanks a lot for including plymouth-deactivate.service. I think the changes to the dm-plymouth.service scripts aren't quite right: I think you want them to start after plymouth-deactivate.service, but before plymouth-quit.service.

commented on 2016-09-17 11:34 (UTC)

plymouth-deactivate.service is in source files but didn't install it in package.

commented on 2016-09-17 11:17 (UTC)

Could you please include a service file for SDDM? It's current service file (sddm.service) contents are: [Unit] Description=Simple Desktop Display Manager Documentation=man:sddm(1) man:sddm.conf(5) Conflicts=getty@tty1.service After=systemd-user-sessions.service getty@tty1.service plymouth-quit.service [Service] ExecStart=/usr/bin/sddm Restart=always [Install] Alias=display-manager.service

commented on 2016-08-11 12:08 (UTC)

excellent Notes @mjkillough I think these notes which you mention must be included in wiki and also plymouth-deactivate.service must be included in this package. I use them and worked perfectly for me.

mjkillough commented on 2016-08-07 11:46 (UTC)

I have written some notes about getting a seamless Plymouth to X transition: As described in [0], it seems the intended way to get a seamless transition is to call `plymouth deacivate` before starting X (rather than `plymouth quit`, as the .service scripts in this package do). I've created a `plymouth-deactivate.service` for this purpose, which is available in my notes above. I'm still tweaking, but will eventually try to get my notes onto the wiki. Perhaps it would be worth including the `plymouth-deactivate.service` script in this package so it is easier for others to use? [0]

Koterpillar commented on 2016-06-29 08:08 (UTC)

With Infinality installed, I get: -> Running build hook: [plymouth-encrypt] ==> ERROR: file not found: `/etc/fonts/conf.d/60-latin.conf'

nullptr_t commented on 2016-03-27 10:37 (UTC)

This works: cryptdevice=UUID=xxxxx

hexchain commented on 2016-03-26 10:32 (UTC)

Using a cryptdevice=PARTUUID=xxxxx parameter works with encrypt hook but not plymouth-encrypt.

nullptr_t commented on 2016-01-08 20:50 (UTC)

I've got the repo up and running again, but the URL changed:

nullptr_t commented on 2015-12-12 17:57 (UTC)

NOTE: If you are using my mirror, the repo name changed to nullptr_t to reflect username change

nullptr_t commented on 2015-12-10 21:02 (UTC) (edited on 2015-12-12 14:51 (UTC) by nullptr_t)

You can now get this package prebuild, signed and secured from my repo here by adding the following to /etc/pacman.conf [nullptr_t] SigLevel = Optional TrustedOnly Server =$repo/$arch The key-id is 1607AC45 armv6h might follow when I have more time.

swiftgeek commented on 2015-11-26 14:31 (UTC) (edited on 2015-11-27 06:34 (UTC) by swiftgeek)

Sadly mentioned path file doesn't do anything (even with path changed to bogus one, ofc inside initrd) ---- EDIT1: Ok i think i made it work, by removing plymouth-start symlinks in *.wants/ and putting path files symlinks in them ( , Now this will start service after first drm based fb is made - so probably that has to be fixed by user passing earlymodules in kcmd (is that still working on systemd based initrd?). [This is for intel+radeon/nvidia optimus-like notebooks and more] EDIT2: I had to also remove those lines from plymouth-start.service: [Install] WantedBy seems to be redundant to the directory in edit above Now it looks like i'm back in square one - sysfs doesn't seems to be available this early so i'm slightly out of ideas on detecting vesafb->drm Or inotify isn't kicking in fast enough (not much idea on how to debug) --- Important notes: • text splash is evil and is going to damage ttys in one way or another WITHOUT providing any eye candy whatsoever Even fedora isn't using this particular theme/engine as fallback! • *DM and plymouthd have to be started on the same tty - it can be changed in either of them - otherwise you won't get smooth transition in eg. lightdm "X -background none" is also helping with having smooth transition. • If your *DM is starting one X for greeter (login prompt) and starting another for the user you can expect KD_GRAPHICS->KD_TEXT->KD_GRAPHICS and there is *probably* nothing you can do about that (or you can workaround by reusing the X server). • If plymouth is crashing during boot, not passing splash isn't going to help - you need to boot with initrd without plymouth in such case. (crash of plymouth can cause unusable mouse/ctrl,backspace,escape) • In order to not have plymouth inside fallback initrd add plymouth hook after -S in fallback_options in /etc/mkinitcpio.d/linux.preset eg. fallback_options="-S plymouth,autodetect,keymap,consolefont -A keyboard"

commented on 2015-11-26 04:07 (UTC)

Actually, reconsidering that unit add-in. I think that might just keep it from triggering at all. Instead, let's try this: Save as plymouth-start.path and add plymouth-start.path to the list of units to add in plymouth.initcpio_install.

commented on 2015-11-26 03:55 (UTC)

Also, regarding encryption, you shouldn't need the plymouth-encrypt hook at all, even with the systemd units added — what you do need is sd-encrypt, because that's what has all the fancy systemd cryptsetup generators.

commented on 2015-11-26 03:53 (UTC)

Glad to hear my work is now “official”! :) Back when I was using it it “just worked”, no need to wait for the drivers, but to make the appropriate units trigger on the existence of the path, --REMOVED because I'm an idiot and write things that don't work, see above--

swiftgeek commented on 2015-11-26 03:38 (UTC)

And i took those lines shamelessly from celti's repo ;) I still have no idea how to make it wait for /sys/class/graphics/fb*/device/drm/ path to appear (or disable vesafb)

nullptr_t commented on 2015-11-25 21:52 (UTC)

@maxf: I use plymouth-encrypt only after 'block' and it works. You can erase the standard plymouth hook. Maybe the problem is with lvm since plymouth-encrypt standalone works? @Celti: git diff returns that your file and plymouth.initcpio_install are the same in today's release. Also, plymouth.encrypt_install contains the systemd service files as suggested by @swiftgeek

commented on 2015-11-25 21:08 (UTC)

You need special sd-plymouth and sd-encrypt hooks to use plymouth with a systemd initramfs. I don't use this anymore but if any changes are necessary to get it working I can make them:

maxf commented on 2015-11-25 20:49 (UTC)

After the addition of the runscript I changed my initcpio array to systemd. If I change "base keyboard systemd sd-vconsole autodetect modconf block sd-encrypt sd-lvm2 filesystems fsck" (working) to "base keyboard systemd sd-vconsole plymouth autodetect modconf block plymouth-encrypt sd-lvm2 filesystems fsck" systemd hangs on "waiting for device XXX to appear". Did anybody get this to work with LUKS+lvm?

nullptr_t commented on 2015-11-24 10:17 (UTC)

Do you have the systemd hook in your initcpio array? If not, does adding it resolve the problem?

swiftgeek commented on 2015-11-23 18:43 (UTC) (edited on 2015-11-23 20:18 (UTC) by swiftgeek)

Problem is easy: no service files -> no operation at all obviously I currently do not have need plymouth-encrypt, but i have noticed that quite often instead of spinner, i'm getting three square dots theme, that later in boot switch into '?' chars. Same thing happened while not using systemd EDIT: It seems that i have to create another service waiting for fb0/fbcon made by intel drm EDIT2: Simplest universal path to find would be /sys/class/graphics/fb*/device/drm , it doesn't make much sense to launch plymouth fallback on non-kms setup Adding sleep 0.3 as ExecStartPre makes splash work every time though obviously it isn't a real fix

nullptr_t commented on 2015-11-23 15:30 (UTC) (edited on 2015-11-23 15:30 (UTC) by nullptr_t)

Yes, I will after further testing. What exactly is your problem? Does this issue also apply to plymouth-encrypt hook?

swiftgeek commented on 2015-11-23 13:01 (UTC) (edited on 2015-11-23 13:01 (UTC) by swiftgeek)

Adding this below add_runscript in /usr/lib/initcpio/install/plymouth fixes my initrd behavior: map add_systemd_unit \ systemd-ask-password-plymouth.path \ systemd-ask-password-plymouth.service \ plymouth-halt.service \ plymouth-kexec.service \ plymouth-poweroff.service \ plymouth-quit-wait.service \ plymouth-quit.service \ plymouth-read-write.service \ plymouth-reboot.service \ plymouth-start.service \ plymouth-switch-root.service Can you please either add those lines or create another install hook with it eg. sd-plymouth ?

nullptr_t commented on 2015-10-25 13:38 (UTC)

Yes and probably the output of journalctl -xe and the service file, too.

zerophase commented on 2015-10-24 19:19 (UTC)

Even with the switch to lightdm.service, and the changes to plymouth the system still locks up during boot up. It looks like my media server still starts up, but I can't reach the desktop. In the bug report should I include all of the hardware, along with the strap and multipliers as well?

nullptr_t commented on 2015-10-24 14:41 (UTC)

Can you please try to use the default lightdm.service and report the results here? That file already contains a line for plymouth...

nullptr_t commented on 2015-10-24 14:02 (UTC) (edited on 2015-10-24 14:04 (UTC) by nullptr_t)

Ok then, I'll take that line in lightdm-plymouth.service out again. Can you please file a bug report on plymouth upstream? Additionally to your last question: I really don't know, I've got only ATI graphic cards that work out of the box with plymouth and {sddm, gdm, kdm, slim}, I don't use lightdm anymore for a long time now...

zerophase commented on 2015-10-23 16:07 (UTC) (edited on 2015-10-23 16:54 (UTC) by zerophase)

I tried booting once, and plymouth still doesn't work. The system stops the rest of the boot process with this print out: EDAC sbridge: ECC is disabled. Aborting EDAC sbridge: Couldn't find mci handler kvm: disabled by bios I can still switch TTY prompts, but just get a _ cursor. Previously, I was able to switch prompts and would eventually be able to login. If I take splash out the of the kernel parameters everything boots fine. I'm using the NVidia drivers. The system's booting in EFI mode, so I shouldn't need to use Uvesafb, right? I just set the vga mode right?

nullptr_t commented on 2015-10-23 09:24 (UTC)

Yes it is and it is not specific to arch. Some people posted a bug report for the same issue on Debian here: So probably waiting for plymouth's developers is the only way to fix this =/ I also applied the workaround from that bug report to our service file. Let me know, if it works now.

zerophase commented on 2015-10-19 12:10 (UTC)

Is the lightdm-plymouth.service still causing issues? I can't get my system to finish starting up, unless I set the plymouth delay so high it doesn't get hit during the boot up process.

nullptr_t commented on 2015-09-17 19:12 (UTC)

Can you please post a more detailed bug output or similar? For me the password prompt has worked as fallback previously (with this version) and the file should be the same since it is installed by this package...

skeggse commented on 2015-09-17 17:26 (UTC)

The plymouth-encrypt hook differs from the encrypt hook in that it does not used the resolved device for the cryptsetup luksOpen command following the ask-for-password prompt on line 79 of plymouth.encrypt_hook (/usr/lib/initcpio/hooks/plymouth-encrypt).

commented on 2015-06-16 12:20 (UTC)

@gS644 Hi, I guess it's not related to plymouth but to the compatibility between SLIM and Systemd/logind. The only error I had, when I boot and SLIM login screen appears (after plymouth splash screen), was: "a start job is running to hold until boot process finishes up" and that like forever. I found out later that it was caused by plymouth-quit-wait.service (via journalctrl) unable to to some stuff whatever that was. I've seen on forums that some update fixed that in GDM but, due to the fact that SLIM is no longer updated nor maintained, so I guess it's a lost cause. Also, I've noticed that slim.service worked fine with "logout" en TTYs, but I don't know why. plymouth-quit.service from plymouth-legacy : ============================================================================= [Unit] Description=Terminate Plymouth Boot Screen After=rc-local.service plymouth-start.service systemd-user-sessions.service Before=getty@tty1.service [Service] ExecStart=-/usr/bin/plymouth quit --retain-splash Type=oneshot TimeoutSec=20 ============================================================================= plymouth-quit-wait.service from plymouth-legacy : ============================================================================= [Unit] Description=Wait for Plymouth Boot Screen to Quit After=rc-local.service plymouth-start.service systemd-user-sessions.service [Service] ExecStart=-/usr/bin/plymouth --wait Type=oneshot TimeoutSec=20 =============================================================================

nullptr_t commented on 2015-06-15 23:53 (UTC)

@nimpsnawak I fixed the slim-plymouth file according to your diff in 0.9.2-3 release. Can you please provide more information (logs) on your second issue? The systemd files for plymouth-quit-wait.service and plymouth-quit.service and some corresponding *.in files and a path included here are the same in both 0.8.8 and 0.9.2, so its difficult to determine the problem without logs. (logging out and TTYs work for me, but I'm not using slim.)

commented on 2015-06-15 13:06 (UTC)

... in addition to what, I had to downgrade from current plymouth release to "plymouth-legacy" ( in order to avoid plymouth-quit-wait.service hanging at error "a start job is running for hold until boot process finishes up" which cause TTYs aren't available.

commented on 2015-06-14 13:22 (UTC)

Hi there ! I user SLIM + XFCE + PLYMOUTH (and systemd) => latest version the bug : when I logout form xfce session, I got to the splash screen with a "start job is running for hold until boot process finish" after "removed slice user-1000.slice", but nothing happen... I get trough that by changing the original "/usr/lib/systemd/system/slim-plymouth.service" with two new lines : [Service] ExecStart=/usr/bin/slim -nodaemon +Restart=always +IgnoreSIGPIPE=no StandardOutput=syslog like in {kdm,gdm,lightdm}-plymouth.service So, could the maintainer make that change permanent ? Thx

commented on 2015-06-14 13:22 (UTC)

Hi there ! I user SLIM + XFCE + PLYMOUTH (and systemd) => latest version the bug : when I logout form xfce session, I got to the splash screen with a "start job is running for hold until boot process finish" after "removed slice user-1000.slice", but nothing happen... I get trough that by changing the original "/usr/lib/systemd/system/slim-plymouth.service" with two new lines : [Service] ExecStart=/usr/bin/slim -nodaemon +Restart=always +IgnoreSIGPIPE=no StandardOutput=syslog like in {kdm,gdm,lightdm}-plymouth.service So, could the maintainer make that change permanent ? Thx

nullptr_t commented on 2015-05-15 09:06 (UTC)

Well, the only difference between both is build@BlueArch ~/plymouth> diff lightdm.service lightdm-plymouth.service 3,4c3 < Documentation=man:lightdm(1) < Conflicts=getty@tty1.service --- > Conflicts=getty@tty1.service plymouth-quit.service but the regular file has "After=[...] getty@tty1.service plymouth-quit.service" set already. If someone using lightdm can confirm this, I'll change that line or the file with the next release. I left lightdm a few months ago and I'm using sddm now of wich there also is no plymouth specific systemd service within this package. So with sddm the regular systemd service works fine, too, and I'm considering to not provide a plymouth-specific service file for lightdm.

Armandrix commented on 2015-05-14 18:42 (UTC)

I had installed it here today... It works well with arch-glow theme (amd64/radeon), but lightdm fix is broken here, hangs before autologin. Lightdm normal systemd hook works ok.

jurf commented on 2015-04-19 15:49 (UTC)

If you use the spinner theme it nicely fades out and waits.

damian01w commented on 2015-04-19 14:52 (UTC)

Its clear that Plymouth isn't really designed to be built from source. For it to work correctly, it needs integration with the distribution. So it is very difficult to continue functioning properly in each package upgrade. Now, with gdm-3.16, is indistinct use gdm.service or gdm-plymouth.service. The transition it's smooth but now the plymouth screen just freezes and waits for GDM get ready.

jurf commented on 2015-04-19 12:20 (UTC)

I tried using just gdm.service and it had the same effect.

jurf commented on 2015-04-19 11:37 (UTC)

So should I use gdm-plymouth.service or just plain gdm.service? Also, I couldn't boot with `quiet splash` after the update. I had to install gdm-plymouth.

shihjay2 commented on 2015-04-13 05:37 (UTC)

For those who use gnome-shell and gdm, since 3.16 you need to have xorg-server-xwayland installed so that you get a seamless transition from plymouth to gdm. You still need to build gdm with the --with-plymouth flag, however you don't need to do systemctl mask plymouth-start.service plymouth-quit.service plymouth-quit-wait.service anymore (if you already did before, unmask it, otherwise you'll get systemd errors) as the gdm.service script already has a way to override these other scripts now.

zman0900 commented on 2015-03-20 05:44 (UTC)

The previous version was working well for me, but 0.9.2 is causing a kernel panic seconds after I log into gnome. If I boot without "quiet splash" to disable plymouth, everything works fine. The log keeps getting cut off in the crash, but this is the beginning line of it: kernel: BUG: unable to handle kernel paging request at 00000000fffffffd Always the same address, but the stack trace that comes after it seems to just be random stuff every time.

damian01w commented on 2015-03-18 03:19 (UTC)

Just added gdm-plymouth package to simplify the things for smooth gdm transition.

damian01w commented on 2015-03-18 02:11 (UTC)

@Celti No problem :) Following this [0] and compiling gdm from scratch with --with-plymouth flag, I get smooth transition between plymouth and gdm. [0]

commented on 2015-03-18 01:50 (UTC)

Man, the Out of Date link really needs a confirmation dialogue. Sorry about that!

damian01w commented on 2015-03-18 01:15 (UTC)

New upstream release 0.9.2

NyQuil commented on 2015-03-17 20:05 (UTC)

0.9.2 was just released :)

ryanvade commented on 2015-01-01 17:08 (UTC)

@shihjay2 that worked for me. Thank you.

shihjay2 commented on 2014-12-25 14:21 (UTC)

@caspian, @eduardomezencio, @ryanvade; The approach @gokul has posted does work for this version of Plymouth and GDM 3.14 (and I have and Intel graphics card and it works) as long as you include the --with-plymouth when you build GDM from scratch. For more details, I'll refer you this link for more details about how to do that.

ryanvade commented on 2014-12-20 23:18 (UTC)

So has the Intel graphics bugs been fixed? And does it look like GDM may be fixed soon? I really hope to have this back soon.

eduardomezencio commented on 2014-12-18 19:03 (UTC)

Well, looks like the bug gokul reported will only be possible to solve when plymouth is an official/community package, so I'm voting for it. By the posts here I think it's not possible to use it with GDM, but if someone knows a way to do it, I would be really glad to know.

caspian commented on 2014-12-18 07:13 (UTC)

Did anyone manage to get this to work with GDM 3.14? I follow the instructions the wiki but plymouth never shows up, just a regular boot screen...

altg commented on 2014-12-06 21:42 (UTC)

Update on gdm. I had reported a bug: If I understand the fix correctly, it will at least draw attention to plymouth's absence when gdm is packaged.

altg commented on 2014-12-03 04:25 (UTC)

@atomictissue, probably needs an AUR package ... because:

atomictissue commented on 2014-12-02 20:02 (UTC)

I was wondering if it is feasible to change the PKGBUILD for gdm in the official repos so it has --use-plymouth ? Is that possible? will it affect other things?

altg commented on 2014-11-27 08:26 (UTC)

@shihjay2, The autodetect is not relevant. I placed it just to emphasize that systemd and sd-plymouth can be placed before anything else. [check mkinitcpio -H systemd and for some more information] If smooth transition is what you want then as far as I can tell you have to compile gdm with --with-plymouth. Ideally the gdm package should have this change. The way things work is like this: 1. plymouth is started either by "plymouth" hook or by "sd-plymouth" hook or "plymouth-start.service". "sd-plymouth" is simply pushing "plymouth-start.service" into initramfs to start it as early as possible just like "systemd" hook will start systemd from the initramfs itself. The "plymouth" hook starts plymouth but _not_ as a systemd service. This is kind of ugly in a systemd environment which is what arch uses now. 2. something has to tell plymouth to quit. plymouth-quit.service does that. But "gdm.service" will prevent "plymouth-quit.service" from running by declaring a "conflict". So instead we use "gdm-plymouth.service" which does not declare a conflict with "plymouth-quit.service". "gdm.service" conflicts with "plymouth-quit.service" because I think the intention was always to compile gdm with "--with-plymouth" option -- so that gdm itself can ask plymouth to quit -- this is where gdm can do _whatever_ is necessary to prevent the screen from going black between the time plymouth quits and gdm draws something on screen. As you can see there is inconsistency with the current gdm package - it prevents plymouth-quit.service from running and does not stop plymouth on its own. So to answer your second question: transition will be successful so long as plymouth is asked to quit but it will be smooth only if gdm is compiled with "--with-plymouth" option.

shihjay2 commented on 2014-11-26 05:14 (UTC)

@gokul, Just so I understand...for method 1 your suggested, you download the script from, and then enter Hooks="systemd sd-plymouth autodetect" in mkinitcpio.conf and that's it? Do you need to compile GDM with --with-plymouth or not (I prefer not to) with this method to make successful transition to GDM?

altg commented on 2014-11-25 06:27 (UTC)

@Celti, thanks for that! Now I have two working set ups: 1) Starting systemd and sd-plymouth in initramfs using initcpio hooks means I do not have to mask any plymouth services. The conflicts with GDM are resolved cleanly and thus if GDM is going to run plymouth-quit service is not run and GDM (compiled with --with-plymouth) stops plymouth. Hooks= "systemd sd-plymouth autodetect ..." 2) If I don't start systemd in initramfs then only if I mask plymouth-start and plymouth-quit* services I get smooth transition (even when I use GDM compiled with --with-plymouth). Hooks= "base udev plymouth autodetect ..." Method (1) is really neat. Thanks again.

commented on 2014-11-24 07:04 (UTC)

Also, I put my mkinitcpio/systemd Plymouth hook on GitHub:

commented on 2014-11-24 06:48 (UTC)

Please add 'ln -s "../systemd-ask-password-plymouth.path" "$pkgdir/usr/lib/systemd/system/"' to the package() section of the PKGBUILD to ensure that systemd asking for passwords works properly under plymouth without configuration. Notably, configuring this manually after plymouth is already installed puts the symlink in /etc/ instead of /usr/lib/ which prevents mkinitcpio from picking it up for asking for passwords in a systemd-based initrd.

m3thodic commented on 2014-11-24 00:46 (UTC)

Needs pkg-config as a dependency:

altg commented on 2014-11-21 06:09 (UTC)

@atomictissue, I masked the services with: # systemctl mask plymouth-start.service plymouth-quit.service plymouth-quit-wait.service You can undo the effect of that by replacing "mask" with "unmask". And as for gdm, good question... with the plymouth-quit*.service masked, it does not matter if we use gdm.service or gdm-plymouth.service. But I simply continue to use gdm-plymouth.service.

atomictissue commented on 2014-11-21 01:11 (UTC)

@gokul, how did you mask those services? and when you compiled gdm with --with-plymouth did you disable gdm-plymouth.service and just enable gdm?

altg commented on 2014-11-19 17:41 (UTC)

Just for completeness [sorry if this only related in spirit], the gdm to gnome transition can be patched as well. reference:

altg commented on 2014-11-18 22:34 (UTC)

Here is my set up where plymouth starts as early as possible and transitions to gdm without blanking. This might work for others too. 1. Added the plymouth hook to mkinitcpio HOOKS after base and udev. 2. compiled gdm with --with-plymouth option 3. masked plymouth-start.service, plymouth-quit.service and plymouth-quit-wait.service because those actions are taken care of by gdm. 4. set ShowDelay=0 in plymouthd.conf I have not yet figured out how to make gnome-shell load smoothly from gdm... when that happens it will be nearly perfect.

zakkudo commented on 2014-11-13 19:34 (UTC)

I played with plymouth-git and noticed you need libtool installed or if fails. So I tried this plymouth package after installing libgool and the %[][] bug seems to disappear. The gdm transition isn't smooth however :/

Cadair commented on 2014-11-13 15:54 (UTC)

Hello, I have installed the latest version of the package and I am still getting the %[][] bug. I have the plymouth-encrpyt hook active and the gdm-plymouth services (which actually seem to be working now). Any suggestions for debugging?

nibon7 commented on 2014-11-05 06:30 (UTC)

@shihjay2 It works,Thaks! :-)

shihjay2 commented on 2014-11-05 04:04 (UTC)

@nibon7 - do you use gdm or some other display manager? If so you'll need to disable that display manager and enable the ***-plymouth.service equivalent. If you forgot to do that, you'll see the wait for plymouth boot screen to quit indefinitely. What I'm having trouble with is: the first syslinux boot text shows up (which is expected), then the spinfinity boot screen shows (which is also expected), then it goes away and shows the syslinux boot text again (for up to a minute) and then it shows the gdm login screen. So something seems to be awry with the transition when gdm is loading up.

nibon7 commented on 2014-11-05 02:09 (UTC)

It stucks at plymouth boot screen and shows that "A start job is running for wait for plymouth boot screen to quit"

mmmm_cake commented on 2014-11-03 08:50 (UTC)

The Plymouth splash screen is now showing up when I boot, but only after I get the message "[/usr/lib/systemd/system/mdm-plymouth.service:4] Failed to add dependency on getty@tty1, ignoring: Invalid argument". What does this mean?

commented on 2014-11-02 17:15 (UTC)

If you have the quiet flag then that message should never appear. I'd file a bug.

mareex commented on 2014-11-02 17:06 (UTC)

Yes I do with "quiet splash"

commented on 2014-11-02 16:29 (UTC)

Are you booting with the 'quiet' flag on the kernel command line?

mareex commented on 2014-11-02 15:42 (UTC)

Thanks Celti, adding that to FILES lets the warning disappear. But still systemd prints "starting version 217". Is there a simple way to avoid that or do I have to find that print command in the sources, comment it out and compile on my own? EDIT: Ok the only way I found so far is to remove that log message from the source code and recompile systemd. I also updated grub and run mkinitcpio because the message did still pop up after the first reboot. Don't no which of the command was necessary to let it disappear. Who wants to build with abs in combination with yaourt and customizepkg can save this under /etc/customizepkg.d/systemd for automization.

commented on 2014-11-01 22:26 (UTC)

It's not a systemd bug, so please don't request that report be re-opened. If you want to file a bug file it against mkinitcpio, or just add /etc/udev/hwdb.bin to your FILES array in mkinitcpio.conf.

mareex commented on 2014-11-01 22:23 (UTC)

Finally with new PGKBUILD % % % bug is gone for me. Something else not related to plymouth itself: Has anyone else problems with systemd-2.17 printing out something like "hwdb.bin does not exist, please run udevadmin hwdb --update" during boot? This output and plymouth fight each other to death. Any suggestions here? Issue is reported here:[systemd]

commented on 2014-11-01 20:11 (UTC)

Further to the previous, my systemd-initcpio hook isn't installing systemd-ask-password.path because it's not a symlink, thereby breaking opening LUKS containers during boot with plymouth.

commented on 2014-11-01 20:08 (UTC)

/usr/lib/systemd/system/ should be a symlink to ../systemd-ask-password-plymouth.path — currently the same file is installed to both locations instead.

damian01w commented on 2014-11-01 18:49 (UTC)

Updated to rev 5! Working again now, please test and let me know.

masux commented on 2014-10-31 18:39 (UTC)

try this:

jip commented on 2014-10-16 06:26 (UTC)

Adding Celti's file to the package would be good also (however, the files plymouth-quit.service and plymouth-quit-wait.service seems to be unnecessary).

jip commented on 2014-10-16 03:50 (UTC)

The plymouth-start.service needs to be patched, as it uses /var/run/plymouth/pid as a pid file, but other units use /run/plymouth/pid. This is a problem when systemd is used in initrd because /var/run is not a link to /run. Also, the /run/plymouth directory is not created. So I added/changed these two lines: ExecStartPre=/bin/mkdir /run/plymouth ExecStart=/usr/bin/plymouthd --mode=boot --pid-file=/run/plymouth/pid --attach-to-session To reproduce the problem, you need to use systemd in initrd and have an encrypted partition. Without patching /usr/lib/systemd/system/plymouth-start.service, the password is asked on the console and not on plymouth splash screen.

jip commented on 2014-10-16 01:18 (UTC)

As someone said on the discussion page of the wiki page for plymouth, for plymouth to work with kdm, you also need the kdebase-workspace-plymouth package from aur.

commented on 2014-10-11 09:37 (UTC)

I made a mkinitcpio hook for plymouth for systemd-enabled initcpios (i.e., for use with the systemd hook). While I haven't tested it this *should* obviate the need for the plymouth-encrypt hook when used with sd-encrypt.

tancrackers commented on 2014-09-28 02:20 (UTC)

Anyone have a fix for this?

kageurufu commented on 2014-09-11 15:02 (UTC)

slim-plymouth.service is partially broken It needs Restart=on-failure added, like the original slim.service

flamusdiu commented on 2014-09-06 17:53 (UTC)

I updated 'plymouth-legacy' which is builds 0.8.8 until v0.9 is fixed. You can find it here:

shihjay2 commented on 2014-09-05 18:12 (UTC)

@ryanvade There is another AUR package "plymouth-lite" that appears to work pretty well. It's not the same plymouth but a stripped down version that displays a simple splash image (which you can change the .png file to whatever you want). I was able to use it to some sucess and works well with systemd.

ryanvade commented on 2014-08-29 03:40 (UTC)

So if there is no current fix, is there a package or version that does? I am willing to downgrade....

tancrackers commented on 2014-08-23 03:52 (UTC)

I'm also suffering from the %⎕⎕⎕ %⎕⎕⎕ %⎕⎕⎕ bug Intel HD 3000 Latest drivers Packaging appears fine, though

addisonamiri commented on 2014-08-14 23:11 (UTC)

@ryanvade nope. I didn't know it was an intel specific issue but that's all I'm seeing.

ryanvade commented on 2014-08-14 19:40 (UTC)

Has the %⎕⎕⎕ %⎕⎕⎕ %⎕⎕⎕ bug been fixed for intel graphics? Also, what are the other plymouth service files for?

addisonamiri commented on 2014-08-12 21:07 (UTC)

I'm getting errors on mkinitcpio. It's giving me 2 file not found errors. One for "/usr/share/fonts/TTF/DejaVuSans.ttf" and another for "/etc/fonts/conf.d/60-latin.conf". I have infinality fonts installed so DejaVu might just be me but the latin font should be working. "/usr/share/fonts/ttf-dejavu-ib/DejaVuSans.ttf" and "/etc/fonts/conf.d/45-latin.conf" are the locations of the fonts it's looking for (for me at least).

ogarcia commented on 2014-08-03 12:48 (UTC)

Confirm. This package is buggy. Only %⎕⎕⎕ %⎕⎕⎕ %⎕⎕⎕ in boot screen using intel graphics card.

shihjay2 commented on 2014-07-30 22:03 (UTC)

I've had the same issue that @mmmm_cake experienced as well. I think the reason you see the splash screen at shutdown is that udev has already fully initialized the video graphics by then. I think based on the comments on plymouth bugs shows that there may be some issues with plymouth not responding correctly (starts too soon?) at boot when udev is still initializing. As @padfoot had alluded to, it's a plymouth issue, not a packaging issue. See this on bugzilla: which explains the likely problem. It sounds like there are some git commits already for some possible fixes (see above thread). However plymouth-git in AUR is not installing correctly as there were some changes in the code and patches in the tarball are throwing errors; if this gets updated, maybe it might work?

mmmm_cake commented on 2014-07-30 18:35 (UTC)

Well this is weird... I'm having the same problem as zalluth and everyone else. Today, I was using my laptop and the battery became too depleted, so it shut down automatically. But while it was shutting down, it displayed the Plymouth splash screen properly! When I plugged in and booted up, though, the percent signs were back.

errorcode15 commented on 2014-07-28 07:48 (UTC)

@lluixhi yes it was, but the tarball is still downloadable as long as you know the exact url which is to replace plymouth with plymouth-release in the tarball link above. It's a temporary fix, but it works.

lluixhi commented on 2014-07-26 19:02 (UTC)

@zalluth @NyQuil I have the same problem here, and it's really odd.. I thought it was related to the 3.15.x kernel upgrade, but the problem also exists in 3.14.x (linux-lts) @errorcode15 Where does that package exist? Wasn't it discontinued?

errorcode15 commented on 2014-07-26 09:29 (UTC)

The % problem is fixed by using the plymouth-release package instead of this one.

NyQuil commented on 2014-07-23 18:10 (UTC)

@zalluth: Same for me here after doing pacman -Syu yesterday.

zalluth commented on 2014-07-23 09:27 (UTC)

It shows only %⎕⎕⎕ %⎕⎕⎕ %⎕⎕⎕ on startup and shutdown, even after changing the theme with plymouth-set-default-theme -R <themename>.

NyQuil commented on 2014-07-16 18:53 (UTC)

It's now working on my laptop with intel graphics - but only during startup. On my VirtualBox VM, plymouth 0.9.0 isn't working anymore - same on Debian jessie/sid, which got plymouth 0.9.0 some days ago. So, it seems to be an issue with plymouth itself.

Gabe commented on 2014-07-13 02:10 (UTC)

Haven't managed to get this to work. GDM never shows up; "waiting for Plymouth to quit" in the logs. If I boot without kernel parameter "splash" then I can get to GDM and log in, but plymouth is running in the background at all times.

cml commented on 2014-07-07 09:08 (UTC)

@gokul I can confirm your fix works just fine - at least with the spinner theme, have to test it with other though.

altg commented on 2014-06-27 13:41 (UTC)

@mareex The tribar theme alone seems to work 'fast'. Also that is the only theme (possibly) where the --retain-splash switch seems to work as expected... i.e, the tribar will finish and you'll directly see gdm appearing -- so basically your prolonged delay in darkness will be replaced with a static splash screen. I don't know what else can be done as of now. I have not explored how to get a splash during shutdown. Will let you know if I work it out.

mareex commented on 2014-06-27 13:16 (UTC)

@masux Did that. System was waiting for plymouth-quit.service. @gokul Works great. Initially only a black screen was shown. But I have been able to get indo GDM login screen. After setting "ShowDelay=0" in "/etc/plymouth/plymouthd.conf" splash finally showed up. Although timespan between plymouth quitting and GDM appearing is huge (3-4 seconds black screen). In addition to that it is now possible to get into tty's. That was not the case in 0.8.8. Still I get no splash during shutdown and reboot. Any ideas?

altg commented on 2014-06-27 09:30 (UTC)

@mareex et al word of caution: I'm new to arch (just a few days) and new to systemd as well. editing gdm-plymouth.service to change as follows stops plymouth screen properly. #Conflicts=getty@tty1.service plymouth-quit.service Conflicts=getty@tty1.service I think this is because "Conflicts" will stop services which is not the required action for plymouth-quit.service. It is already there in the "After" which is exactly what is needed.

masux commented on 2014-06-27 09:07 (UTC)

@mareex after runs logind service plymouth-quit should start, if you want to see whats happening, try remove quiet kernel parameter and when splash shows try pressing ESC or try remove retain to splash parameter from plymouth-quit.service

hobbypunk commented on 2014-06-27 08:51 (UTC)

@masux i can't look directly, i can't login on other ttys :-/ (is a known problem on my system, without solution ;) :D ). but after restart with out plymouth i can look with: journalctl -e -u plymouth-quit-wait but its not informativ :-/ Log: Jun 27 07:19:23 bethselamin systemd[1]: plymouth-quit-wait.service start operation timed out. Terminating. Jun 27 07:19:23 bethselamin systemd[1]: Failed to start Wait for Plymouth Boot Screen to Quit. thats all :-/

mareex commented on 2014-06-27 08:14 (UTC)

With the newest package plymouth screen appears but does not quit. I am not able to change to text console (Ctrl+AltF2) to investigate this issue. I am using gdm as login manager. Both gdm.service and gdm-plymouth.service do not make plymouth quit. @damian01w Could you please post your HOOKS line from /etc/mkinitcpio.conf?

damian01w commented on 2014-06-27 02:45 (UTC)

Thankyou ! Works for me too with the latest update. :D

lluixhi commented on 2014-06-27 01:37 (UTC)

@padfoot plymouth 0.9.0-4 works for me as well (and better than before, no more fsck lines!)

commented on 2014-06-26 22:52 (UTC)

@ masux Thankyou for your assistance. I have made your suggested changes and updated the package. Still doesn't work for me. My problem seems to be udev. My framebuffer is set up at 0.5s into boot, udev is triggered at 0.7s, yet udev coldplug is not finishing until approx 7.0s and udev actually doesn't recognise my framebuffer device until approx 8.5s (1.5 secs after coldplug has completed). The strange thing is, before the last update to udev, coldplug was finished at 0.8s into boot, something has changed adding 6 secs to the process. To fickle for me, and 0.8.8 (which doesn't wait for all this udev stuff) wqorks perfectly, so it's not as if my system can't display a splash, it is definitely the software. Not getting any response from upstream either. I am reverting to 0.8.8. Feel free to take up the mantle. Cheers.

masux commented on 2014-06-26 12:14 (UTC)

@ hobbypunk look up for plymouth-quit.service with: sudo systemctl status plymouth-quit.service -l

hobbypunk commented on 2014-06-26 10:56 (UTC)

@masux plymouth runs for you? i've the problem that my bootscreen don't quit, any idea? i think i try your changes^^ greets, Marcel

masux commented on 2014-06-26 10:33 (UTC)

for debug i use these kernel parameters: splash plymouth:debug plymouth.debug=stream:/dev/kmsg

masux commented on 2014-06-26 10:28 (UTC)

@ padfoot try it

commented on 2014-06-25 21:31 (UTC)

@ masux I have tried your suggested changes, it makes no difference to my boot, still no plymouth and zero change to the logs. I don' think it is really required as the pseudoterminal is already created anyway. Cheers.

starquake commented on 2014-06-25 21:05 (UTC)

Plymouth seems to be working again on one of my machines. Will check the other too.

masux commented on 2014-06-25 10:46 (UTC)

fix pts: /usr/lib/initcpio/hooks/plymouth ... /bin/mkdir -p /dev/pts /bin/mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || true /usr/bin/plymouthd --mode=boot --pid-file=/var/run/plymouth/pid --attach-to-session ...

commented on 2014-06-22 23:09 (UTC)

The issue, from what I can see with my logs, is that udev coldplug is either not finished, or not being reported as finished during boot, leading plymouth to finding drm/fb devices but totally ignoring them as udev coldplug is not finished. Plymouth will only recognise a drm or framebuffer device after udev coldplug has finished and the device has a seat tag. If either of these conditions is not met, the device is ignored and it should fall back to a text splash. Unfortunately, I am not even geting a text splash as tty1 is not being recognised as boot_vga device, yet the output of $ find /sys -name 'boot_vga' tells me boot_vga has been set correctly. Upstream seems to think there is some sort of race condition going on here.

commented on 2014-06-22 23:07 (UTC)

The issue, from what I can see with my logs, is that udev coldplug is either not finished, or not being reported as finished during boot, leading plymouth to finding drm/fb devices but totally ignoring them as udev coldplug is not finished. Plymouth will only recognise a drm or framebuffer device after udev coldplug has finished and the device has a seat tag. If neither of these conditions is not met, the device is ignored and it should fall back to a text splash. Unfortunately, I am not even geting a text splash either as tty1 is not being recognised at boot_vga, yet the output of $ find /sys -name 'boot_vga' tells me boot_vga has been set correctly. Upstream seems to think there is some sort of race condition going on here.

commented on 2014-06-22 23:06 (UTC)

The issue, from what I can see with my logs, is that udev coldplug is either not finished, or not being reported as finished during boot, leading plymouth to finding drm/fb devices but totally ignoring them as udev coldplug is not finished. Plymouth will only recognise a drm or framebuffer device after udev coldplug has finished and the device has a seat tag. If neither of these conditions is not met, the device is ignored and it should fall back to a text splash. Unfortunately, I am not even geting a text splash either as tty1 is not being recognised at boot_vga, yet the output of $ find /sys -name 'boot_vga' tells me boot_vga has been cet correctly. Upstream seems to think there is some sort of race condition going on here.

commented on 2014-06-22 22:34 (UTC)

@ masux I have applied your suggestions for others to try. The only real change is adding --attach-to-session in the initrd hook as /var/run is a symlink to /run, although I have changed to hook to /var/run. Still does not work for me unfortunately.

commented on 2014-06-17 21:19 (UTC)

Fixed encrypt-hook to pass cryptargs while unlocking volume.

abandonedaccount commented on 2014-06-17 20:53 (UTC)

Hi padfood. There seems to be a small bug wherein plymouth-encrypt hook doesn't pass the cryptargs to cryptsetup More exact info and the dummy fix here: As a side effect it prevented fstrim from working because it wouldn't pass --allow-discards to cryptsetup. This same bug also exists in plymouth-git package. Thanks for your time.

arkeiro commented on 2014-06-11 11:40 (UTC)

Padfoot, I reverted plymouth to version 0.8.8 and now it's working again. Thanks.

hobbypunk commented on 2014-06-11 07:03 (UTC)

hello, it don't work for me to, i have the same config as many intel, MBR, Yes, thats why i don't have any logs ;) but i think a have an other problem found, not shure if it's depending on the start problem ;) but plymouthd run in background anytime and uses 100% of one CPU core. greets, Marcel

commented on 2014-06-11 00:04 (UTC)

For those who want to revert to 0.8.8, you should be able to find the package here:

commented on 2014-06-10 23:36 (UTC)

Ok, from what I can see from all the logs everyone has posted (thankyou) is that it could actually be a udev issue. Plymouth needs to wait for the udev coldplug to complete before it can check for a valid device to display on. From everything I can see in the logs, the current version of udev is not completing the coldplug until about 6-7 seconds into boot, and by that time, my system has almost finished booting (plymouth not getting udev device events until approx 6-7 seconds into boot). But somehow I think the coldplug is completed well before then as I tested by adding some device node tests in the plymouth hook before it would try to launch the splash, and that passed without issue. So it would seem that plymouth is not receiving the required udev events until well into boot and by this time it is too late to show a splash. I have tried getting assistance from upstream, and while I received a reply or 2 at the start, I have not received a response from my last contact for about 2 weeks now. Unfortunately I do not have the skills to debug this any further, and with no responses from upstream, ther is nothing further I can do. Feel free to pick up this package if you have the knowledge to fix it. Cheers.

lluixhi commented on 2014-06-10 23:35 (UTC)

Hello there, I as well request the tar.gz of the 0.8.8 PKGBUILD, scripts, and patches. By the way, 1. MBR 2. Intel 3. Yes 4. I get a black screen that flashes shortly before returning to the same boot up sequence. as w/o plymouth. plymouth-git does not even flash the black screen.

arkeiro commented on 2014-06-10 15:48 (UTC)

Hello! Where can I download the PKGBUILD and tarball for version 0.8.8 of plymouth?

NyQuil commented on 2014-06-10 10:37 (UTC)

@padfoot: Sorry for the late answer. Here's my dmesg output (dmesg | grep ply) on a VBox VM with non working plymouth-0.9.0: (plymouth-0.8.8 worked fine on this VM)

isiachi commented on 2014-06-09 20:17 (UTC)

My setup: 1. EFI 2. Intel 3. Yes 4. Downgraded to 0.8.8.

dnlrn commented on 2014-06-09 10:37 (UTC)

Okay, so while writing my previous comment i've updated my kernel to the new 3.14.6 and now plymouth doesn't work anymore. So I downgraded the kernel and it still doesn't work. So it seems like the new plymotuh version just worked for me because I didn't rebuild the initramfs. The kernel update triggered the rebuild. Conclusion: the new plymouth version also doesn't work for me :( It only worked because the old version was still in the initramfs :)!

dnlrn commented on 2014-06-09 10:24 (UTC)

Sorry for replying so late, here is my working setup: 1. EFI 2. Intel 3. Yes 4.

mmmm_cake commented on 2014-06-09 01:50 (UTC)

Here you go, padfoot: Let me know if there's anything else I can do!

commented on 2014-06-08 22:01 (UTC)

@ mmmm_cake Thank you, could you please post your entire dmesg? Not all messages required contain "plymouth" in the output, so the grep plymouth filter actually removes the lines I need. Cheers.

mmmm_cake commented on 2014-06-08 20:52 (UTC)

Plymouth has stopped working after upgrade for me as well. My setup: 1. EFI 2. Intel 3. Yes 4. My output of dmesg | grep plymouth is available at . It's all Greek to me, but I hope it helps you!

commented on 2014-06-06 21:33 (UTC)

@ starquake and NyQuil Thank you for your feedback. Knowing I'm not the only one with issues, while not good in itself, is a relief. It will give me more info to pass back upstream. If you could get me some debug logs, that would be fantastic. To enable debugging, add the following to your kernel command line: plymouth.debug=stream:/dev/kmsg and edit /usr/lib/initcpio/hooks/plymouth adding --debug to the following lines: line 9: /usr/bin/plymouthd --debug --mode=boot --pid-file=/run/ line12: /usr/bin/plymouth --debug --show-splash Rebuild your initrd and the plymouth debug messages will be available in your dmesg output. Cheers.

commented on 2014-06-06 21:32 (UTC)

@ starquake and NyQuil Thank you for your feedback. Knowing I'm not the only one with issues, while not good in itself, is a relief. It will give me more info to pass back upstream. If you could get me some debug logs, that would be fantastic. To enable debugging, add the following to your kernel command line: plymouth.debug=stream:/dev/kmsg and edit /usr/lib/initcpio/hooks/plymouth adding edbug to the following lines: line 9: /usr/bin/plymouthd --debug --mode=boot --pid-file=/run/ line12: /usr/bin/plymouth --debug --show-splash Rebuild your initrd and the plymouth debug messages will be available in your dmesg output. Cheers.

NyQuil commented on 2014-06-06 20:56 (UTC)

Doesn't work for me too. (x64 VBox install and x86 intel with MBR)

starquake commented on 2014-06-06 18:53 (UTC)

The other one doesn't work 1. EFI 2. Intel 3. Yes 4. Both mkinitcpio.conf files are identical. Differences: Working one is x86 (MedieMonkey), failing one is x86_64 (CodeMonkey) MediaMonkey lshw output: CodeMonkey lshw output: I will see if I can find any errors in logs and things like that

starquake commented on 2014-06-06 07:21 (UTC)

It works for me too. At least for one machine: 1. MBR 2. Intel 3. Yes 4. I also have a machine with EFI and Intel. I will try that when I get home in a few hours.

commented on 2014-06-06 07:09 (UTC)

@ dnlrn, thanks. I'm pleased it is working for you. Unfortunately 0.9.0 doesn't work for me at all. You may be able to assist me in troubleshooting my issues (awkward maintaining a package for others when it doesn't work for myself). May I ask you to email me some details of your set up? Specifically: 1. EFI or MBR - knowing this can determine what type of framebuffer is utilised on your system. 2. Intel/Nouveau/Radeon/Nvidia/ATI - which driver are you using and... 3. Early KMS - knowing the driver and if you have early KMS set up informs me if plymouth is using a framebuffer or drm renderer on your system. 4. Your mkinitcpio.conf - helps me identify possible hook configuration issues. Cheers.

dnlrn commented on 2014-06-05 09:34 (UTC)

I know this is off-topic, but I just want to say thank you for maintaining this package for arch for such a long time, especially since it is very hard to maintain. The newest version 0.9.0 works fine for me :)!

commented on 2014-06-03 07:18 (UTC)

Ok, 0.9.0 has been uploaded. Troubleshooting with upstream, while progressing, is progressing slowly, so I figured the more eyes across this package the better. Please post any issues (and solutions if found) so I can update this package. Cheers.

blackwolf12333 commented on 2014-05-28 19:47 (UTC)

Depends on gtk2 to be installed on the system. Won't build without it.

commented on 2014-05-23 22:14 (UTC)

I am aware 0.9.0 has been released, but at the moment, I cannot get it to work with Arch. I am working with the upstream devs to solve the Arch integration issue. In the meantime, 0.8.8 still works perfectly.

commented on 2014-05-23 08:36 (UTC)

I am aware this package is out of date. 0.9.0 is currently not working with Arch, and I am working with upstream to get a working package. Cheers.

RibShark commented on 2014-05-11 15:10 (UTC)

@SASDOE: Is there a similar method of getting a smooth transision with LightDM?

SASDOE commented on 2014-05-07 15:57 (UTC)

For those of you who want a smooth transition to gdm, you need to compile GDM with the --with-plymouth in configure (or just use this PKGBUILD: I previously had a 5 second lag, not anymore. Also I had at the time added --enable-gdm or whatever in plymouth's PKGBUILD, but don't know if it's relevant or not).

commented on 2014-04-18 21:39 (UTC)

@lens My bad. Revert the changes to /usr/lib/initcpio/hooks/plymouth The new way of enabling logging for plymouth (I thought this was currently only in git, but it worked for me with stable just now). Add plymouth.debug to your kernel command line in grub/syslinux/refind/gummiboot This will log plymouth to your journal.

lens commented on 2014-04-18 14:08 (UTC)

@ padfoot The log file did not appear by adding --debug-file=/var/log/plymouthd.log, too.

commented on 2014-04-18 00:47 (UTC)

@lens Try adding --debug-file=/var/log/plymouthd.log

lens commented on 2014-04-17 12:41 (UTC)

@ padfoot I edited line 9 of /usr/lib/initcpio/hooks/plymouth, did mkinitcpio -p linux and rebooted. However, /var/log/plymouth.log did not appear.

hobbypunk commented on 2014-04-16 11:15 (UTC)

@ padfoot thanks, but i dont know if it works, now my NetworkManager is back on top, 12s to start, i hate it^^ think thats why i dont get gdm directly :-/

commented on 2014-04-16 09:09 (UTC)

@ hobbypunk Try removing plymouth-quit.service from the "conflicts" line in gdm-plymouth.service. This will allow gdm to get underway while plymouth is in the process of quitting rather than gdm waiting until after. Ensure you are able to boot to a console to revert the change BEFORE you try this. The reason the conflict is in the service files is in some cases, the DM may lock up your system without the conflict, rendering your system unbootable.

hobbypunk commented on 2014-04-16 08:45 (UTC)

@padfoot i read it also, but it works great^^ but, is there any other way to get a smooth transition? without it didn't work

commented on 2014-04-16 08:25 (UTC)

@ hobbypunk --enable-gdm-transition is deprecated and designed for gtk2, hence why it makes no difference with gtk3/gnome3.

commented on 2014-04-16 08:23 (UTC)

@ lens and hobypunk Try the following to find the cause of the plymouth-quit-wait.service failure. As root: edit /usr/lib/initcpio/hooks/plymouth change line 9 from: /usr/sbin/plymouthd --mode=boot --pid-file=/run/ to: /usr/sbin/plymouthd --mode=boot --pid-file=/run/ --debug then: mkinitcpio -p linux reboot and then you can inspect /var/log/plymouth.log Cheers.

hobbypunk commented on 2014-04-15 22:40 (UTC)

@padfoot and @lens Hello, i have the same problem on gnome, i start also gnome-plymouth.service i've the same problems with plymouth-quit-wait.service. i compile it with "--enable-gdm-transition" but with or without didnt change anything, systemd-analyse blame shows over 20s for plymouth-quit-wait.service :( have anyone any ideas? :-/

lens commented on 2014-04-15 14:35 (UTC)

@padfoot Thanks for replying. I am using kdm-plymouth.service to start kdm.

commented on 2014-04-15 06:24 (UTC)

@lens Something is causing the plymouth-quit-wait.service to fail. Which service are you using to start kdm? Are you using kdm.service or kdm-plymouth.service?

lens commented on 2014-04-14 14:18 (UTC)

plymouthd eats about 30 percent of CPU usage even after kde desktop starts. Am I the only one who has this problem? $ systemctl status plymouth-quit.service plymouth-quit.service - Terminate Plymouth Boot Screen Loaded: loaded (/usr/lib/systemd/system/plymouth-quit.service; static) Active: inactive (dead) $ systemctl status plymouth-quit-wait.service plymouth-quit-wait.service - Wait for Plymouth Boot Screen to Quit Loaded: loaded (/usr/lib/systemd/system/plymouth-quit-wait.service; static) Active: failed (Result: timeout) since Mon 2014-04-14 00:39:31 JST; 22h ago Main PID: 268 (code=killed, signal=TERM)

commented on 2014-03-29 23:56 (UTC)

@ Cadair Are you able to see what the text is before the plymouth-encrypt password box is displayed? This may give an indication of what is happening before plymouth starts. Otherwise everything looks ok. Perhaps try moving the plymouth hook before udev. It may have an impact (and it may not work depending on your system hardware configuration). I use "base plymouth udev ..." and it works perfectly for me. Otherwise (I don't have an encrypted root so don't know exactly how it operates with encryption) I can only guess that plymouth doesn't start until the plymouth-encryption hook, so you may have a brief display of text before that hook is reached. Unfortunately, that hook can not be moved up any further in the hooks array. I really must install an arch image in a VM so I can play with things like encryption.

Cadair commented on 2014-03-29 23:33 (UTC)

Hello, The gdm trick didn't seem to work, no massive loss I just thought it should. My mkinitcpio.conf is here: I have early KMS enabled, I am using the intel drivers, and I am booting using legacy BIOS mode. What happens is I go through bootloader, then the screen res changes (KMS loads?) and then I get a text screen for a second before the password box for my encryption key comes up. thanks a lot Stuart

commented on 2014-03-19 08:48 (UTC)

This package is now back to the official release version and replaces the package plymouth-release. For git, use the plymouth-git package.

commented on 2014-03-19 05:17 (UTC)

@ Cadair: The smooth transition to GDM has been deprecated. This package builds without that option enabled. The current release files for plymouth are from 2012 and gtk support, when enabled is for gtk2. I am uncertain if the smooth transition will work with gtk3/gdm3.x, but give it a try. Edit the PGKBUILD file and add the following option on line 89: --enable-gdm-transition \ This will now build with the transition enabled. Regarding your screen flicker between bootloader/manager and plymouth starting, I would need some more information. Please post your mkinitcpio.conf to pastebin for example, and post the link here. Also, are you using UEFI or BIOS to boot your system? WHich graphics drivers are you using? Do you have early KMS enabled? Cheers.

Cadair commented on 2014-03-18 18:10 (UTC)

As a quick note, I also see a text screen breify after what I guess is KVM kicking in (after screen flicker) before my passphrase entry screen comes up, and doing a `journal -xn | grep gdm` dosen't return anything, I also can't see anything that strikes me as relevant in the full journal.

Cadair commented on 2014-03-18 18:05 (UTC)

Hello, I have succesfully installed this and got it working, thank you very much. I am running full system encryption and it makes it much nice for passphrase entry! However, I can't seem to get the nice transition into GDM working. I have disabled the gdm service and enabled the gdm-plymouth one however it still shows a text screen with all the putput from boot for around 1-2 seconds before GDM loads. Have I missed something silly or is this a problem others have had? Thanks Stuart

commented on 2014-03-18 08:49 (UTC)

Hi isiachi, I only just requested this package be disowned by the previous maintainer so I could take up maintenance of it today via aur-general mailing list. The main reason for this is that there is already a git package (I currently have maintenance of that), and I currently maintain a release version plymouth-release. The idea was to pick up maintenance of this package so I could merge it with plymouth-release so we only have the 2 packages on AUR, namely plymouth and plymouth-git. As I have only just received the notification of it being disowned, it would seem you have taken up ownership of the package before I received the notification. I would appreciate it if you could disown tha package so I can complete the clean up I already have in progress. Thanks.

commented on 2014-03-15 10:07 (UTC)


commented on 2014-03-08 22:49 (UTC)

Updated the various *-plymouth.service files

commented on 2014-03-08 08:15 (UTC)

@ Melo Patch is part of base-devel. When using the AUR, it is automatically assumed you have base-devel installed, so dependencies on packages in base-devel are not required.

commented on 2014-03-06 05:08 (UTC)

@ Mello Sorry, your comment is not clear. What patch? What dependency?

Melo commented on 2014-03-05 21:19 (UTC)

It needs patch as a dependency

Melo commented on 2014-02-23 23:30 (UTC)

It needs autoreconf from autoconf and aclocal from automake and then from configure: aur-plymouth/src/plymouth/configure: line 5223: syntax error near unexpected token `dlopen' aur-plymouth/src/plymouth/configure: line 5223: `LT_INIT(dlopen disable-static pic-only)'

commented on 2014-02-20 09:34 (UTC)

This build uses /etc/os-release

commented on 2014-02-11 08:25 (UTC)

@ RibShark My bad, I forgot to link /etc/os-release to /etc/system-release. Fixed.

RibShark commented on 2014-02-11 07:39 (UTC)

With the latest update I get this when using mkinitcpio: -> Running build hook: [plymouth] ==> ERROR: file not found: `/etc/system-release' ... ==> WARNING: errors were encountered during the build. The image may not be complete.

nachoig commented on 2014-02-02 03:27 (UTC)

@dongfengweixiao libtool is part of base-devel. Packages of this group shouldn't go to the makedeps. BTW, now there is plymouth-release But I prefer this PKGBUILD instead. The idea of avoiding patches and delete distro-specific scripts is really good.

NyQuil commented on 2014-01-30 19:09 (UTC)

@padfoot: Never used this service before, due to problems switching to ttys, but this seems to be working better now. Using kdm-plymouth.service and all seems to be running fine - so thanks for the hint :)

commented on 2014-01-30 05:51 (UTC)

Just to be certain, did you disable kdm.service first and then enable kdm-plymouth.service? # systemctl disable kdm.service # systemctl enable kdm-plymouth.service If so, what output do you get with # journalctl -xn | grep kdm

NyQuil commented on 2014-01-29 18:44 (UTC)

KDM doesn't start for me anymore with this version. Plymouth itself works fine.

drism commented on 2014-01-26 23:22 (UTC)

Thanks padfoot, this is working without a hitch.

commented on 2014-01-26 03:07 (UTC)

Updated PKGBUILD to use release sources instead of git sources so md5sum can be used to verify source.

commented on 2014-01-26 02:59 (UTC)

Updated PKGBUILD to use release sources instead of git sources so md5sum cna be used to verify source.

commented on 2014-01-25 23:50 (UTC)

I uploaded this package (updated the plymouth-git package) as plymouth and plymouth-git are currently not working (for me at least). This package uses the current release version 0.8.8, patches updated and it now works (for me at least). Hopefully this package will work for all those who have been having issues with the git package.

dongfengweixiao commented on 2013-12-24 06:20 (UTC)

build req:libtool

dongfengweixiao commented on 2013-12-24 06:20 (UTC)

@ylecuyer pls install libtool

commented on 2013-12-16 05:51 (UTC)

Downgrading to fixed my splash

commented on 2013-12-13 22:06 (UTC)

NyQuil, I am suffering the same problem. No boot splash, and on restart/shutdown, the splash briefly appears only to be taken over by console messages again, and leaving an artefact of my splash onscreen (the spinner is still shown). Perhaps I'll try git, see if that helps.

NyQuil commented on 2013-12-11 07:41 (UTC)

This the latest update (, plymouth stopped working for me. No plymouth splash screen is shown on startup, only on shutdown.

andreihaiducul commented on 2013-12-04 06:28 (UTC)

@taylorchu Commit 37d2e400d25e6b4716d77d26fb7d40de8a8c1a8a exposed a bug with the current package: plymouth is started on tty7 and gdm never closes it since it starts on tty1, which in turn means that systemd never spawns agetty on other tty since it waits forever for plymouth to quit. Removing the --with-{boot,shutdown}-tty options from configure fixes the problem because the defaults are OK (tty1 and ttylast, respectively). Another option is to modify gdm.service to NOT conflict with plymouth-quit.service, but that would mean modifying vanilla files. Please update the PKGBUILD to use the default tty options.

gormux commented on 2013-12-03 12:14 (UTC)

Same error here. Is this package still maintained ?

ylecuyer commented on 2013-11-05 01:32 (UTC)

I have an error when trying to install /tmp/yaourt-tmp-ylecuyer/aur-plymouth/src/plymouth/configure: line 5221: syntax error near unexpected token `dlopen' /tmp/yaourt-tmp-ylecuyer/aur-plymouth/src/plymouth/configure: line 5221: `LT_INIT(dlopen disable-static pic-only)' ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build plymouth.

kpy commented on 2013-10-23 20:34 (UTC)

@Holzhaus I had the same problem. After installing "docbook-xsl" the package was build without any problems.

Holzhaus commented on 2013-10-23 00:24 (UTC)

Does not work for me: GEN plymouth.1 I/O error : Attempt to load network entity warning: failed to load external entity "" cannot parse Makefile:607: recipe for target 'plymouth.1' failed make[2]: *** [plymouth.1] Error 4 make[2]: Leaving directory '/home/jan/plymouth/src/plymouth/docs' Makefile:443: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/jan/plymouth/src/plymouth' Makefile:374: recipe for target 'all' failed make: *** [all] Error 2

Det commented on 2013-10-06 19:36 (UTC)

Also why don't you use the "" and "plymouth-update-initrd.patch" instead of just removing the 'plymouth-set-default-theme' script? It really is exteremly useful because it avoids ls'ing "/usr/share/plymouth/themes/" to list the themes, and editing "/etc/plymouth/plymouthd.conf" and running 'mkinitcpio -p <kernel name>' to change them.

Det commented on 2013-10-06 18:42 (UTC)

Excuse me?: md5sums=( 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' 'SKIP' ) You only need to skip the _Git_ source. These other files _should_ actually be verified.

taylorchu commented on 2013-10-06 06:29 (UTC)

changelog bizcom logo is replaced by the official white 2-color logo. geric please test the newer version.

geric commented on 2013-10-05 22:39 (UTC)

I'd have to reinstall it on that machine, I just had it setup to test something under Arch and was going through the motions of getting my 'usuals' setup, plymouth being one of them. Does spinfinity work for you?

taylorchu commented on 2013-10-05 20:50 (UTC)

@geric does other theme work?

geric commented on 2013-10-05 15:28 (UTC)

My config file said [Daemon] Theme=spinfinity So if someone broke spinfinity, thats a different issue.

taylorchu commented on 2013-10-04 15:56 (UTC)

@geric are you sure that the theme is usable? it does not seem like a hook problem.

geric commented on 2013-10-04 14:24 (UTC)

It WAS in mkinitcpio, hence my comment "set it up as always," you've always had to install the hook. Tried running "plymouthd && plymouth --show-splash" by hand to test it and it hung at a black screen

taylorchu commented on 2013-10-04 06:58 (UTC)

plymouth-set-default-theme is simply a trivial bash script that reads config and create image. I feel the arch way is to edit the config file, and run mkinitcpio yourself. you need to add the hook to mkinitcpio conf.

geric commented on 2013-10-04 05:05 (UTC)

Bizcom ships from upstream its a default logo incase the distro in question doesn't provide a logo. I'm not sure if the move to plymouthd.conf was done by upstream...or this maintainer. If it was done by the maintainer, then (s)he's kind of flying off the handle as far as modifying upstream. I mention this because it would explain 'plymouth-set-default-theme' still being in the man pages (if the maintainer changed things) Personally when I installed plymouth the other day I didn't get anything at all. Set it up as always, gave it a theme to use... and it never used it. Just kept the normal text boot and shutdown screens, like plymouth wasn't even installed.

erikw commented on 2013-09-29 21:37 (UTC)

After upgrading to v. using the solar theme there's a "Bizcom" logo when booting. Where did that come from? And the program "plymouth-set-default-theme" is gone while the man pages still refers to it.

grufo commented on 2013-09-26 11:37 (UTC)

Please, add plymouthd.conf to the "backup" array: backup=("etc/plymouth/plymouthd.conf") Here is a complete example…: …where I also added the check() function… Bye.

intelfx commented on 2013-09-24 11:23 (UTC)

Please, update PKGBUILD as here: . This (along with modifications to the DM, like in kdebase-workspace-plymouth) is required to have a smooth Plymouth->DM transition.

taylorchu commented on 2013-09-18 23:20 (UTC)

changelog image size is much smaller now

agomonos commented on 2013-09-18 09:26 (UTC)

edit: maybe it's better to use this as fallback after checking for the theme in the first if (using the default plymouth settings): PLYMOUTH_THEME_NAME=$(grep "Theme *= *" /usr/share/plymouth/plymouthd.defaults | grep -v '#' | sed 's/Theme *= *//')

agomonos commented on 2013-09-18 09:13 (UTC)

hi, i noticed that initcipio image created using plymouth are huge since you copy all the themes and all the library. so i created (some time ago) this plymouth.install script that should use only the needed theme and library.. i just updated this script to read /etc/plymouth/plymouthd.conf.. hope this helps! thanks!

taylorchu commented on 2013-09-18 01:25 (UTC)

changelog 1. I removed all non-arch-relevant scripts from upstream, because they are irrelevant and need lots of patches. the new way to config: 1. edit /etc/plymouth/plymouthd.conf 2. run mkinitcpio

commented on 2013-09-17 22:56 (UTC)

sudo plymouth-set-default-theme not exist anymore, so a postintall note about how config it now??

tubal-cain commented on 2013-09-17 18:11 (UTC)

I'm getting this error when I run sudo plymouth-set-default-theme -R arch-logo /usr/lib/plymouth/plymouth-update-initrd: line 2: mkinitrd: command not found

commented on 2013-09-12 09:17 (UTC)

Hi, wondering if there was a reason behind lightdm-plymouth.service being removed from this package? Thanks.

andreihaiducul commented on 2013-09-05 16:07 (UTC)

taylorchu: The new hook works. Thanks. Good job!

ValHue commented on 2013-09-05 06:53 (UTC)

This is impossible: provides=('plymouth') conflicts=('plymouth') Should be: provides=('plymouth') conflicts=('plymouth-git') There is a copy of plymouth-git?

taylorchu commented on 2013-09-05 04:44 (UTC)

changelog * rewrite encrypt hook based on latest hook from official arch repo. use 1. "plymouth plymouth-encrypt" should always go together. if you use plymouth-encrypt, encrypt can be removed. 2. plymouth hook provides full functionality of plymouth. need rebuild after configuration. plymouth-encrypt is just a slightly changed hook based on encrypt hook with "plymouth ask-for-password" @andreihaiducul please test. Thanks.

andreihaiducul commented on 2013-09-05 01:50 (UTC)

taylorchu: with the regular hook, there is no password prompt in plymouth. You can see cryptsetup's prompt if you press ESC, but you can't actually type in anything because any key immediately terminates the input. The plymouth-encrypt hook uses "plymouth ask-for-password" to get the password.

taylorchu commented on 2013-09-05 00:38 (UTC)

@andreihaiducul the regular hook should work. What did you see precisely?

andreihaiducul commented on 2013-09-04 21:07 (UTC)

taylorchu: you shouldn't have thrown out the plymouth-encrypt hook patch, because it's needed to input the LUKS password through plymouth. The regular hook doesn't work at all while plymouth is running, and having to run plymouth after "encrypt" is a step-down from previous versions of this package. Went back to plymouth-git.

taylorchu commented on 2013-09-03 10:39 (UTC)

changelog * use git version (for now) for recent systemd and archlinux update * remove lots of junk (we use clean upstream now). These old junks are some systemd services that are already provided in upstream. I know there are some other files for encrypt and themes. use 1. add your kms module to mkinicpio.conf 2. add "plymouth" after "base" 3. mkinitcpio -p linux (if you are using the default preset)

duht commented on 2013-09-03 08:31 (UTC)

NyQuil is rigt. Please replace the line SCRIPT='plymouth' with add_runscript in plymouth.initcpio_install script to make plymouth mkinitcpio HOOK work again and start plymouth at early boot stage (right after GRUB). More info in this thread:

commented on 2013-08-27 02:19 (UTC)

There is a problem with plymouth-quit.service file The following line ExecStart=-/usr/bin/plymouth quit Should be ExecStart=/usr/bin/plymouth quit Thats basically the reason of plymouth quit service not working. I edited the file and changed the md5sum in PKBUILD to match with the new one did the compilation and then installed the package and now its working ok Please change that files in tarball for other users

NyQuil commented on 2013-08-07 13:05 (UTC)

There seems to be a problem with the initcpio-install-script, since the hook is not applied to the initrd-image anymore: For further information, read this forum thread:

commented on 2013-07-15 06:12 (UTC)

Are there still issues with this or can anyone confirm that it is working through the installation of the package on this page?

jaham commented on 2013-07-12 21:11 (UTC)

Please add pkg-config as a dependency. Thanks

artiom commented on 2013-06-27 14:55 (UTC)

I submitted a bug about quit service:

Peace4all commented on 2013-06-06 16:14 (UTC)

Glad it worked, I updated the tarball and bumped the release to 11. I released the package again, hoping that someone can adopt it.

maccyber commented on 2013-06-06 06:26 (UTC)

Thanks Peace4all - worked for me. Can you adopt the package and apply changes?

Peace4all commented on 2013-06-04 08:53 (UTC)

I applied the changes needed for the recent 'usr/bin update' (basically the same changes ImNtReal highlighted below), and tested it, it seems to work as before ( I use gdm), so at YOUR OWN RISK here is the tar-ball with those changes:

ImNtReal commented on 2013-06-03 12:59 (UTC)

I think you need at add --sbindir=/usr/bin to the ./configure line, and replace /usr/sbin with /usr/bin in all of the extra sources in the package to get this working with the new filesystem package.

commented on 2013-05-30 00:34 (UTC)

Same problem as Gonzih, the wait for Plymouth quit service does not start (times out). gdm disabled and gdm-plymouth enabled. More info: Hopefully someone has a fix.

commented on 2013-05-26 19:22 (UTC)

I keep getting the following error: /tmp/yaourt-tmp-aj/aur-plymouth/./PKGBUILD: line 50: patch: command not found ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build plymouth.

devrs0 commented on 2013-05-20 14:16 (UTC)

libpng15 dependency removed.

Alda commented on 2013-05-20 07:32 (UTC)

There's no need for libpng15 as you just have to reinstall plymouth after the update to libpng16 and it will use it.

devrs0 commented on 2013-05-19 17:33 (UTC)

Updated to include libpng15 as a dependency and fixed lightdm and lxdm services.

commented on 2013-05-18 14:15 (UTC)

>> Remove rc.local from After in plymouth-quit{,-wait}.service (if on native systemd) It doesn't work for me, problem "plymouth still survives in tty1 and plymouthd stresses the CPU" persists. Thanks anyway.

malinas commented on 2013-05-17 21:10 (UTC)

I feel people are getting dumbed down in arch. If you use a sysvcompat method, one can add the rc-local services as one wish. TO answer some questions below: just remove rc.local from After in plymouth-quit{,-wait}.service (if on native systemd), or if one is not using anything in rc.local anyway. lxdm-plymouth.service.. just sed /usr/sbin/lxdm to bin in the service file. :)

commented on 2013-05-16 03:15 (UTC)

service lxdm-plymouth fail too since was moved to /usr/bin

commented on 2013-05-14 17:35 (UTC)

Plymouth still survives in tty1, and plymouthd stresses the CPU. Any idea?

erikw commented on 2013-05-13 19:26 (UTC)

Have the same problem as ImNtReal. Either get this to work with libpng in the official repo (v. 16) or add libpng15 as a dependency.

devrs0 commented on 2013-05-13 17:21 (UTC)

The lightdm binary has been moved from /usr/sbin to /usr/bin in the community package causing the lightdm-plymouth.service to fail.

ImNtReal commented on 2013-05-13 13:06 (UTC)

It may be a good idea to add libpng15 as an optdepend. I just noticed this while building my kernel image: ERROR: binary dependency `' not found for `/usr/lib/plymouth//'

commented on 2013-05-06 21:59 (UTC)

in plymouth.initcpio_install the line "add_runscript" has been replaced with "SCRIPT='plymouth'" and this breaks initcpio functionality for me.

commented on 2013-03-05 14:17 (UTC)

The encrypt hook seems broken : I do not get the prompt to enter the password of the encrypted partition where all my system, but the /boot partition, resides. plymouth 0.8.8-6 was (and is still) working.

commented on 2013-02-25 01:17 (UTC)

Is encrypt_hook.patch not needed anymore?

commented on 2013-02-24 18:42 (UTC)

I can't install this package. The encrypt_hook seems not to match the MD5 code.

ultimA commented on 2013-02-16 19:49 (UTC)

Bug report: /usr/lib/systemd/system/plymouth-quit-wait.service and /usr/lib/systemd/system/plymouth-quit.service should reference rc.local.service instead of rc-local.service. The latter does not exist.

commented on 2013-02-13 22:36 (UTC)

Could not install. Was getting errors. Something changed upstream apparently. To install successfully, had to modify encrypt_hook.patch to the following: --- encrypt_hooka 2012-07-15 11:17:04.000000000 +0300 +++ encrypt_hook 2012-07-15 11:32:59.258648852 +0300 @@ -74,13 +74,10 @@ fi # Ask for a passphrase if [ ${dopassphrase} -gt 0 ]; then - echo "" + echo echo "A password is required to access the ${cryptname} volume:" - - #loop until we get a real password - while ! eval cryptsetup open --type luks ${resolved} ${cryptname} ${cryptargs} ${CSQUIET}; do - sleep 2; - done + plymouth ask-for-password --prompt="Password for ${cryptname} volume" --dont-pause-progress --number-of-tries=5 --command="/sbin/cryptsetup luksOpen --key-file=- ${cryptdev} ${cryptname} ${CSQUIET}" + sleep 2 fi if [ -e "/dev/mapper/${cryptname}" ]; then if [ ${DEPRECATED_CRYPT} -eq 1 ]; then Also had to change md5 sums in 3rd and 4th lines in PKGBUILD: c279d86d6dc18322c054d2272ebb9e90 03d2d991c4f8a36a9a962160f07d626e Good luck!

commented on 2013-01-14 21:23 (UTC)

Hi, I have created a slim-plymouth.service based on the lxdm version. See it here: It could be included with the services distributed in this package.

commented on 2013-01-02 15:43 (UTC)

Please update the lightdm-plymouth.service unit file (LightDM won't start otherwise):

faergeek commented on 2012-12-28 14:31 (UTC)

Apply this patch, please. Since mkinitcpio 0.12.0 SCRIPT variable is unused. See --- plymouth.initcpio_install.orig 2012-07-14 03:04:03.000000000 +0400 +++ plymouth.initcpio_install 2012-12-28 18:25:49.837173735 +0400 @@ -47,7 +47,7 @@ add_binary "$(readlink -e /lib/" add_file /lib/ - SCRIPT='plymouth' + add_runscript } help() {

commented on 2012-12-18 16:05 (UTC)

I have following issue with plymouth package and systemd: Thanks!

lmello commented on 2012-12-13 01:30 (UTC)

I'm gaving critical issues with the latest build - using both gdm.service and gdm-plymouth.service fail to start GDM.

raku commented on 2012-12-01 17:59 (UTC)

Can you apply this patch, please? --- PKGBUILD.orig 2012-11-26 15:57:06.000000000 +0100 +++ PKGBUILD 2012-12-01 18:55:11.000000000 +0100 @@ -92,8 +92,8 @@ make DESTDIR="$pkgdir" install install -Dm644 "$srcdir/arch-logo.png" "$pkgdir/usr/share/plymouth/arch-logo.png" - install -Dm644 ../../encrypt_hook "$pkgdir/usr/lib/initcpio/hooks/plymouth-encrypt" - install -Dm644 ../../encrypt_install "$pkgdir/usr/lib/initcpio/install/plymouth-encrypt" + install -Dm644 "$srcdir/encrypt_hook" "$pkgdir/usr/lib/initcpio/hooks/plymouth-encrypt" + install -Dm644 "$srcdir/encrypt_install" "$pkgdir/usr/lib/initcpio/install/plymouth-encrypt" install -Dm644 "$srcdir/plymouth.functions" "$pkgdir/etc/rc.d/functions.d/plymouth.functions" install -Dm644 "$srcdir/plymouth.initcpio_hook" "$pkgdir/usr/lib/initcpio/hooks/plymouth" install -Dm644 "$srcdir/plymouth.initcpio_install" "$pkgdir/usr/lib/initcpio/install/plymouth" It fixes files paths so plymouth can be built with devtools inside clean chroot.

becatlibra commented on 2012-11-20 19:59 (UTC)

Tried this out today and there is at least one issue preventing it from working on my system: Nov 20 14:18:02 darkhouse systemd[436]: Failed at step EXEC spawning /bin/systemd-tty-ask-password-agent: No such file or directory This is due to an incorrect path in /usr/lib/systemd/system/systemd-ask-password-plymouth.service The path should be /usr/bin rather than /bin

stefano.facchini commented on 2012-11-06 10:53 (UTC)

1. There's no need of systemd-unit-dir.patch, as /lib is just a symlink to /usr/lib 2. It seems to me that gdm-plymouth.serivce is also unnecessary. Comparing it to the official gdm.service the only difference is the lack of getty@tty1.service in "Conflicts=" and "After=", right? BTW, thanks for packaging this, :)

commented on 2012-10-31 13:31 (UTC)

This unit file is wrong: /usr/lib/systemd/system/plymouth-start.service This line: ExecStartPost=-/bin/udevadm settle --timeout=30 --exit-if-exists=/sys/class/drm/card0/dev ; /bin/udevadm settle --timeout=30 --exit-if-exists=/sys/class/graphics/fb0/dev ; /usr/bin/plymouth show-splash Should be: ExecStartPost=-/usr/bin/udevadm settle --timeout=30 --exit-if-exists=/sys/class/drm/card0/dev ; /usr/bin/udevadm settle --timeout=30 --exit-if-exists=/sys/class/graphics/fb0/dev ; /usr/bin/plymouth show-splash

commented on 2012-10-31 13:28 (UTC) (read last comments) aparently users have issues with plymouth and the removal of consolekit

twouters commented on 2012-10-31 12:00 (UTC)

For those using Gnome 3.6, systemd and GDM and have enabled plymouth-gdm.service, it seems that you should use the default gdm.service Otherwise "loginctl show-session $XDG_SESSION_ID | grep Active" will return Active=no. This will cause issues like being unable to change network settings in networkmanager as a regular user etc.

Anthony25 commented on 2012-10-28 18:33 (UTC)

Just replace the line : '4dab1b0e23d81907b79b49c2d8d719b5' by 'c970831d733ca42e20415005967e7843'

commented on 2012-10-26 06:11 (UTC)

Please update the package checksums. I am getting the following build error: ..... encrypt_hook ... FAILED ..... ==> ERROR: One or more files did not pass the validity check! Cheers.

robertfoster commented on 2012-10-26 00:57 (UTC)

added lightdm-plymouth.service

dracorp commented on 2012-10-25 12:30 (UTC)

diff --git a/PKGBUILD b/PKGBUILD index 7fa0e0b..c4dacb5 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -42,12 +42,12 @@ source=("$pkgname/releases/$pkgname-$pkgver. build() { - cd $startdir + cd "$srcdir" msg "Applying Patches..." msg2 "Fixing encrypt HOOK" - patch -p0 -i encrypt_hook.patch - patch -p0 -i encrypt_install.patch + patch -p0 -i "$srcdir"/encrypt_hook.patch --follow-symlinks + patch -p0 -i "$srcdir"/encrypt_install.patch --follow-symlinks

dracorp commented on 2012-10-25 12:18 (UTC)

-> Fixing encrypt HOOK can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- encrypt_hooka 2012-07-15 11:17:04.000000000 +0300 |+++ encrypt_hook 2012-07-15 11:32:59.258648852 +0300 -------------------------- File to patch: Please fix it.

dracorp commented on 2012-10-24 10:04 (UTC)

$ namcap plymouth- plymouth E: Dependency gtk2 detected and not included (libraries ['usr/lib/', 'usr/lib/'] needed in files ['usr/lib/plymouth/renderers/'])

ShadowKyogre commented on 2012-10-07 19:15 (UTC)

@Det: :S Actually, it doesn't. The reason why I mentioned that was because I actually do have a custom SRCDEST variable

Det commented on 2012-10-07 19:00 (UTC)

$SRCDEST won't matter one bit here (most don't even have it set) and the paths to the patches work either way.

ShadowKyogre commented on 2012-10-07 18:26 (UTC)

You might want to change cd $startdir to cd $SRCDEST since some people's SRCDEST variable might be different than $startdir. Also, you may want to change the references to the patch files to "$srcdir/<appropriate patch>.patch" to reflect this.

Det commented on 2012-10-04 10:34 (UTC)

It's because patch 2.7.* was just pulled to [core]: [...] * Refuse to apply a normal patch to a symlink. (Previous versions of patch were replacing the symlink with a regular file.)

FalsePerspective commented on 2012-10-03 13:55 (UTC)

Building fails after this: ==> Applying Patches... -> Fixing encrypt HOOK File encrypt_hook is not a regular file -- refusing to patch 1 out of 1 hunk ignored -- saving rejects to file encrypt_hook.rej ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build plymouth. ==> Restart building plymouth ? [y/N]

solsticedhiver commented on 2012-08-06 22:05 (UTC)

also, plymouth never quits when using systemd. aka, after boot complete and on the desktop switchin to first console, shows pymouth still running. I ahave to run plymouth quit to make it go away. I am using the gdm-plymouth.service I noticed that that file mentions a plymouth-quit.service. but I see no such file at all...

Det commented on 2012-08-06 19:01 (UTC)

No, it's not a typo. That's what it originally was supposed to be. The sub-directory just needs to be created before creating the pid file or cut down completely.

solsticedhiver commented on 2012-08-06 17:43 (UTC)

may be it's a typo and should be /run/ ?

solsticedhiver commented on 2012-08-06 13:40 (UTC)

I got the error: Can not wirte pid file /run/plymouth/pid with either initscript or systemd

gagarski commented on 2012-07-19 19:42 (UTC)

Can I use it without installing systemd?

martadinata666 commented on 2012-07-14 03:09 (UTC)

change the plymouth 0.8.6 md5sums to this 851e5b35537c85afbde90c930a7cb09e , the first line of the md5sums list

techryda commented on 2012-07-13 15:09 (UTC)

All of the files from /lib need to be moved to /usr/lib. This needs to happen ahead of the new glibc being moved from [testing] into core. This has to do with the ongoing merge of the /usr dir see for more info Thanks

liquidsky commented on 2012-06-03 13:55 (UTC)

Same problem here with my crypted LVM as in the plymouth-get package. "The Text field don't appears. And if I switch with F2 to the Text mode I can't type in the Pass code. After two keystrokes the cursors moves in a new line and I get the message that the passcose is wrong."

Det commented on 2012-04-29 16:33 (UTC)

You guys can just flag this thing when that happens.

commented on 2012-04-29 16:27 (UTC)

encrypt_install ... FAILED when validating source files with sha1sums

Det commented on 2012-01-08 13:56 (UTC)

It's fine now, brah.

toropisco commented on 2012-01-08 13:16 (UTC)

Checksums and patches are failing.

Det commented on 2011-07-31 09:53 (UTC)

Synced with plymouth-git (so the splash is shown when shutting down too). I tested it and at least on this machine this thing actually works just as well as plymouth-git (even though the 0.8.3 tarball is over 14 months old). Your own experience may vary. If it varies too much, try out plymouth-git.

Det commented on 2011-07-30 09:53 (UTC)

Updated. Should work just fine now. Though, plymouth-git is recommended.

CPUnltd commented on 2011-07-15 15:40 (UTC)

==> WARNING: Hook 'plymouth' uses a deprecated 'install' function. This should be renamed 'build' /lib/initcpio/install/plymouth: line 3: add_device: command not found

biginoz commented on 2010-09-03 21:52 (UTC)


Det commented on 2010-07-28 16:03 (UTC)

This package doesn't really work. I tried the latest version (0.8.3) and the build fails even without this set-default-theme patch.

Det commented on 2010-07-27 13:35 (UTC)

Somebody should mention this in the AUR mailing list..

Babets commented on 2010-05-06 19:54 (UTC)

0.8.3 is out please update this pkg or leave it orphan.