Package Details: plymouth 0.9.2-12

Git Clone URL: https://aur.archlinux.org/plymouth.git (read-only)
Package Base: plymouth
Description: A graphical boot splash screen with kernel mode-setting support
Upstream URL: http://www.freedesktop.org/wiki/Software/Plymouth/
Licenses: GPL
Conflicts: plymouth-git
Provides: plymouth
Submitter: PirateJonno
Maintainer: nullptr_t
Last Packager: nullptr_t
Votes: 380
Popularity: 9.594516
First Submitted: 2009-08-12 04:16
Last Updated: 2016-10-12 00:07

Sources (17)

  • arch-logo.png
  • gdm-plymouth.service
  • http://www.freedesktop.org/software/plymouth/releases/plymouth-0.9.2.tar.bz2
  • lightdm-plymouth.service
  • lxdm-plymouth.service
  • plymouth-deactivate.service
  • plymouth-quit.service.in.patch
  • plymouth-set-default-theme.in.patch
  • plymouth-start.path
  • plymouth-start.service
  • plymouth-update-initrd.patch
  • plymouth.encrypt_hook
  • plymouth.encrypt_install
  • plymouth.initcpio_hook
  • plymouth.initcpio_install
  • sddm-plymouth.service
  • slim-plymouth.service

Latest Comments

jpprovost commented on 2016-11-13 08:22

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

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]: https://aur.archlinux.org/packages/breeze-plymouth/

lomapur commented on 2016-10-09 11:20

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

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.

morealaz commented on 2016-09-17 11:34

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

morealaz commented on 2016-09-17 11:17

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

morealaz commented on 2016-08-11 12:08

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

I have written some notes about getting a seamless Plymouth to X transition: https://github.com/mjkillough/notes/blob/master/boot-experience.md

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] https://lists.freedesktop.org/archives/plymouth/2014-March/000753.html

Koterpillar commented on 2016-06-29 08:08

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

This works: cryptdevice=UUID=xxxxx

hexchain commented on 2016-03-26 10:32

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

nullptr_t commented on 2016-01-08 20:50

I've got the repo up and running again, but the URL changed:
https://wiki.archlinux.org/index.php/Unofficial_user_repositories#nullptr_t

nullptr_t commented on 2015-12-12 17:57

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

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 = https://www.slau.me/archlinux/mirrors/$repo/$arch

The key-id is 1607AC45
armv6h might follow when I have more time.

swiftgeek commented on 2015-11-26 14:31

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 (initrd-switch-root.target.wants , sysinit.target.wants)
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=sysinit.target
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"

Anonymous comment on 2015-11-26 04:07

Actually, reconsidering that unit add-in. I think that might just keep it from triggering at all. Instead, let's try this:

Save https://ptpb.pw/je1W.path as plymouth-start.path and add plymouth-start.path to the list of units to add in plymouth.initcpio_install.

Anonymous comment on 2015-11-26 03:55

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.

Anonymous comment on 2015-11-26 03:53

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

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

@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

Anonymous comment on 2015-11-25 21:08

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: https://github.com/Celti/mkinitcpio-systemd-plymouth

maxf commented on 2015-11-25 20:49

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

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

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

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

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

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

zerophase commented on 2015-10-24 19:19

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

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

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

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

Yes it is and it is not specific to arch. Some people posted a bug report for the same issue on Debian here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782456

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

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

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

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).

nimpsnawak commented on 2015-06-16 12:20

@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

@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.)

nimpsnawak commented on 2015-06-15 13:06

... in addition to what, I had to downgrade from current plymouth release to "plymouth-legacy" (https://aur4.archlinux.org/packages/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.

nimpsnawak commented on 2015-06-14 13:22

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

nimpsnawak commented on 2015-06-14 13:22

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

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.

nullptr_t commented on 2015-05-15 09:05

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

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

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.

DoctorJellyface commented on 2015-04-19 15:49

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

DoctorJellyface commented on 2015-04-19 15:49

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

damian01w commented on 2015-04-19 14:52

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.

DoctorJellyface commented on 2015-04-19 12:20

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

DoctorJellyface commented on 2015-04-19 11:37

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

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

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

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

damian01w commented on 2015-03-18 02:11

@Celti No problem :)

Following this [0] and compiling gdm from scratch with --with-plymouth flag, I get smooth transition between plymouth and gdm.

[0] https://forum.manjaro.org/index.php?topic=18501.0

Anonymous comment on 2015-03-18 01:50

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

damian01w commented on 2015-03-18 01:15

New upstream release 0.9.2

NyQuil commented on 2015-03-17 20:05

0.9.2 was just released :)

ryanvade commented on 2015-01-01 17:08

@shihjay2 that worked for me. Thank you.

shihjay2 commented on 2014-12-25 14:21

@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. https://forum.manjaro.org/index.php?topic=18501.0

ryanvade commented on 2014-12-20 23:18

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.

ryanvade commented on 2014-12-20 23:15

I also want to know how to use Plymouth with GDM.

eduardomezencio commented on 2014-12-18 19:03

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

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...

gokul commented on 2014-12-06 21:42

Update on gdm. I had reported a bug:
https://bugzilla.gnome.org/show_bug.cgi?id=740802

If I understand the fix correctly, it will at least draw attention to plymouth's absence when gdm is packaged.

gokul commented on 2014-12-03 04:25

@atomictissue,
probably needs an AUR package ...
because: https://bugs.archlinux.org/task/35115

atomictissue commented on 2014-12-02 20:02

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?

gokul commented on 2014-11-27 08:26

@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 https://wiki.archlinux.org/index.php/mkinitcpio#Common_hooks 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

@gokul,
Just so I understand...for method 1 your suggested, you download the script from https://github.com/Celti/mkinitcpio-systemd-plymouth, 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?

gokul commented on 2014-11-25 06:27

@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.

Anonymous comment on 2014-11-24 07:04

Also, I put my mkinitcpio/systemd Plymouth hook on GitHub: https://github.com/Celti/mkinitcpio-systemd-plymouth

Anonymous comment on 2014-11-24 06:48

Please add 'ln -s "../systemd-ask-password-plymouth.path" "$pkgdir/usr/lib/systemd/system/sysinit.target.wants/systemd-ask-password-plymouth.path"' 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

Needs pkg-config as a dependency: http://pastebin.com/DzPbePJP

gokul commented on 2014-11-21 06:09

@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.

gokul commented on 2014-11-21 05:50

@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.

[aside: this ^^ is probably why gdm.service has a "conflicts" field with plymouth-quit.service in it ... I will explore whether that was actually doing its job. If that works, it means that do not have to mask anything on our own.]

atomictissue commented on 2014-11-21 01:11

@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?

atomictissue commented on 2014-11-21 01:10

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?

atomictissue commented on 2014-11-20 14:01

Is it possible to have the splash stay up until GDM is ready? On my computer, the splash shows for a bit, but then it goes back to the black screen. Also, trying to preview the splash from a TTY as per the instructions crashes the system.

gokul commented on 2014-11-19 17:41

Just for completeness [sorry if this only related in spirit], the gdm to gnome transition can be patched as well.
reference: https://bugzilla.gnome.org/show_bug.cgi?id=740377

gokul commented on 2014-11-18 22:34

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.

gokul commented on 2014-11-18 22:32

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.

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

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

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

@shihjay2 It works,Thaks! :-)

shihjay2 commented on 2014-11-05 04:04

@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

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

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?

Anonymous comment on 2014-11-02 17:15

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

Yes I do with "quiet splash"

Anonymous comment on 2014-11-02 16:29

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

mareex commented on 2014-11-02 15:42

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 http://pastebin.com/UMcDbvLR under /etc/customizepkg.d/systemd for automization.

mareex commented on 2014-11-02 15:38

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 sourcecode and recompile systemd.

Who wants to build with abs in combination with yaourt and customizepkg can save this http://pastebin.com/UMcDbvLR under /etc/customizepkg.d/systemd for automization.

mareex commented on 2014-11-02 15:38

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 sourcecode and recompile systemd.

Who wants to build with abs in combination with yaourt and customizepkg can save this http://pastebin.com/UMcDbvLR under /etc/customizepkg.d/systemd for automization.




mareex commented on 2014-11-02 01:46

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?

Anonymous comment on 2014-11-01 22:26

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

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:
https://bugs.archlinux.org/task/42634?string=[systemd]

Anonymous comment on 2014-11-01 20:11

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.

Anonymous comment on 2014-11-01 20:08

/usr/lib/systemd/system/sysinit.target.wants/systemd-ask-password-plymouth.path 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

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

masux commented on 2014-10-31 20:11

also change gdm-plymouth.service
from
Conflicts=getty@tty1.service plymouth-quit.service
to
Conflicts=getty@tty1.service

after that plymouth quit work as expected

masux commented on 2014-10-31 19:58

also change gdm-plymouth.service
from
Conflicts=getty@tty1.service plymouth-quit.service
to
Conflicts=getty@tty1.service

After that plymouth quit as expected

masux commented on 2014-10-31 18:39

try this: http://pastebin.com/JfJ2NkYH

masux commented on 2014-10-31 17:05

try this: http://pastebin.com/JfJ2NkYH
also i think maybe in unit files is bug, because plymouth dont stop

giga commented on 2014-10-16 06:26

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).

giga commented on 2014-10-16 03:50

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.

giga commented on 2014-10-16 01:18

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.

Anonymous comment on 2014-10-11 09:37

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.

http://ix.io/eIv

tancrackers commented on 2014-09-28 02:20

Anyone have a fix for this?

kageurufu commented on 2014-09-11 15:02

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

I updated 'plymouth-legacy' which is builds 0.8.8 until v0.9 is fixed. You can find it here: https://aur.archlinux.org/packages/plymouth-legacy/

shihjay2 commented on 2014-09-05 18:12

@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

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

ryanvade commented on 2014-08-29 03:39

Just checking in. Any news on a fix?

tancrackers commented on 2014-08-23 03:52

I'm also suffering from the %⎕⎕⎕ %⎕⎕⎕ %⎕⎕⎕ bug
Intel HD 3000
Latest drivers

Packaging appears fine, though

addisonamiri commented on 2014-08-14 23:11

@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


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

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

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

shihjay2 commented on 2014-07-30 22:03

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. https://www.libreoffice.org/bugzilla/show_bug.cgi?id=80553 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

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

@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

@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

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

errorcode15 commented on 2014-07-26 09:28

The % problem is fixed by using Plymouth a release package instead of this one.

NyQuil commented on 2014-07-23 18:10

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

zalluth commented on 2014-07-23 09:27

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

zalluth commented on 2014-07-23 08:41

It shows only %⎕⎕⎕ %⎕⎕⎕ %⎕⎕⎕ on startup and shutdown

NyQuil commented on 2014-07-16 18:53

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

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

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

masux commented on 2014-06-27 19:14

@padfoot
i forgot also you can try this
# If we have no graphics devices yet, wait for udev to settle
[ -d /sys/class/graphics/fbcon ] && \
[ -d /sys/class/graphics/fb0 ] && \
[ -d /sys/class/drm/card0 ] || udevadm settle

[ -d /sys/class/graphics/fbcon ] && \
[ -d /sys/class/graphics/fb0 ] && \
[ -d /sys/class/drm/card0 ] || sleep 1

masux commented on 2014-06-27 18:53

@padfoot
if you have problems with coldboot try create custom udev hook which adds only your graphics
make a copy of /usr/lib/initcpio/install/udev to /usr/lib/initcpio/install/udev-custom
and create also udev-custom hook something like that
http://pastebin.com/KRzM4Azv
ofcourse you need to know what modules and binaries you need to use your disk, i used this
http://blog.falconindy.com/articles/optmizing-bootup-with-mkinitcpio.html
finally your mkinitcpio.conf looks
http://pastebin.com/g4FFt1ir

gokul commented on 2014-06-27 13:41

@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

@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?

mareex commented on 2014-06-27 13:15

@masux
Did that. System was waiting for plymouth-git.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?

gokul commented on 2014-06-27 09:30

@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

@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

@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

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

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

lluixhi commented on 2014-06-27 01:37

@padfoot

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

padfoot commented on 2014-06-26 22:52

@ 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

@ hobbypunk

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

hobbypunk commented on 2014-06-26 10:56

@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

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

masux commented on 2014-06-26 10:33

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

masux commented on 2014-06-26 10:28

@ padfoot

try it http://pastebin.com/VLjuMK8A

masux commented on 2014-06-26 10:00

@ padfoot

I finally get it work fully(means that plymouth start showing splash screen in early userspace), here it what i edit:
http://pastebin.com/KfDW2gB1
http://pastebin.com/Zu531Pf3
http://pastebin.com/MTUk69sZ
http://pastebin.com/dibX1zsD

btw I dont know what is possible to cut off, i only implement how it is in ubuntu and in INSTALL manual in plymouth package and tried many times many configurations and i only find out this is the only setup that works for me
as you said only important thing is to get coldplug complete before init because it is useful to have plymouth in hooks when it really starts after systemd and systemd-udevd working
and why it is important to get pseudoterminal works? i think it is important only if you have --attach-to-session parameter because plymouth tries to connect to pseudoterminal and in initrd script it is not mounted and if plymouth do not get pseudoterminal work it only waits to systemd and then connect and start work
now all hard work is on you :D

padfoot commented on 2014-06-25 21:31

@ 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

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

masux commented on 2014-06-25 10:46

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
...

padfoot commented on 2014-06-22 23:09

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.

padfoot commented on 2014-06-22 23:07

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.

padfoot commented on 2014-06-22 23:06

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.

padfoot commented on 2014-06-22 22:34

@ 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.

masux commented on 2014-06-22 20:59

ok i made it work, i think main problem was wrong path to pid in /usr/lib/systemd/system/plymouth-start.service compared with /usr/lib/initcpio/hooks/plymouth and another good thing is add parameter --attach-to-session to /usr/lib/initcpio/hooks/plymouth to Redirect console messages from screen to log.

Tested with i915

masux commented on 2014-06-22 20:58

ok i make it work, i think main problem was wrong path to pid in /usr/lib/systemd/system/plymouth-start.service compared with /usr/lib/initcpio/hooks/plymouth and another good thing is add parameter --attach-to-session to /usr/lib/initcpio/hooks/plymouth to Redirect console messages from screen to log.

Tested with i915

padfoot commented on 2014-06-17 21:19

Fixed encrypt-hook to pass cryptargs while unlocking volume.

abandonedaccount commented on 2014-06-17 20:53

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: https://github.com/manjaro/packages-extra/pull/2
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

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

arkeiro commented on 2014-06-11 11:40

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

arkeiro commented on 2014-06-11 11:36

hobbypunk commented on 2014-06-11 07:03

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

padfoot commented on 2014-06-11 00:04

For those who want to revert to 0.8.8, you should be able to find the package here:
http://pkgbuild.com/git/aur-mirror.git/

padfoot commented on 2014-06-10 23:36

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

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. http://pastebin.com/54HjCSCy

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

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

NyQuil commented on 2014-06-10 10:37

@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:

http://pastebin.com/1AcAESWm

(plymouth-0.8.8 worked fine on this VM)

isiachi commented on 2014-06-09 20:17

My setup:
1. EFI
2. Intel
3. Yes
4. http://downloads.rhyeworld.it/files/static/mkinitcpio.conf

Downgraded to 0.8.8.

dnlrn commented on 2014-06-09 10:37

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

Sorry for replying so late, here is my working setup:

1. EFI
2. Intel
3. Yes
4. https://gist.github.com/dnlrn/278b6b8bb51cd4c4928f

mmmm_cake commented on 2014-06-09 01:50

Here you go, padfoot:
https://www.dropbox.com/s/1oyy9a2j4lyok9a/dmesg

Let me know if there's anything else I can do!

padfoot commented on 2014-06-08 22:01

@ 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

Plymouth has stopped working after upgrade for me as well. My setup:

1. EFI
2. Intel
3. Yes
4. https://www.dropbox.com/s/hv5mgwozph1hm2m/mkinitcpio.conf

My output of dmesg | grep plymouth is available at https://www.dropbox.com/s/gu6a5v2qm19nav8/plymouth_debug . It's all Greek to me, but I hope it helps you!

padfoot commented on 2014-06-06 21:33

@ 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/plymouth.pid
line12: /usr/bin/plymouth --debug --show-splash

Rebuild your initrd and the plymouth debug messages will be available in your dmesg output.

Cheers.

padfoot commented on 2014-06-06 21:32

@ 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/plymouth.pid
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

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

starquake commented on 2014-06-06 18:53

The other one doesn't work

1. EFI
2. Intel
3. Yes
4. https://gist.github.com/daafe77e528be5c6d88d

Both mkinitcpio.conf files are identical.

Differences:

Working one is x86 (MedieMonkey), failing one is x86_64 (CodeMonkey)
MediaMonkey lshw output:
https://gist.github.com/bbaec6c023160d835c93
CodeMonkey lshw output:
https://gist.github.com/f37ca93a5ee791a49a22

I will see if I can find any errors in logs and things like that

starquake commented on 2014-06-06 07:21

It works for me too. At least for one machine:

1. MBR
2. Intel
3. Yes
4. https://gist.github.com/b275c1a0700b5dba7837

I also have a machine with EFI and Intel. I will try that when I get home in a few hours.

padfoot commented on 2014-06-06 07:09

@ 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

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 :)!

padfoot commented on 2014-06-03 07:18

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

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

padfoot commented on 2014-05-23 22:14

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.

padfoot commented on 2014-05-23 08:36

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

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

SASDOE commented on 2014-05-07 15:57

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: https://gist.github.com/SASDOE/ed5eb1b0753a64ad7541).

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).

padfoot commented on 2014-04-18 21:39

@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

@ padfoot

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

padfoot commented on 2014-04-18 00:47

@lens

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

lens commented on 2014-04-17 12:41

@ 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.

lens commented on 2014-04-17 12:40

@padfood

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

hobbypunk commented on 2014-04-16 11:15

@ 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 :-/

padfoot commented on 2014-04-16 09:09

@ 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

@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

padfoot commented on 2014-04-16 08:25

@ hobbypunk

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

padfoot commented on 2014-04-16 08:23

@ 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/plymouth.pid
to:
/usr/sbin/plymouthd --mode=boot --pid-file=/run/plymouth.pid --debug
then:
mkinitcpio -p linux

reboot and then you can inspect /var/log/plymouth.log

Cheers.

hobbypunk commented on 2014-04-15 22:40

@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

@padfoot

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

padfoot commented on 2014-04-15 06:24

@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

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)

padfoot commented on 2014-03-29 23:56

@ 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

Hello,

The gdm trick didn't seem to work, no massive loss I just thought it should.

My mkinitcpio.conf is here: http://bpaste.net/show/oeUQu7RIs0iOm0cDfYLJ/

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

padfoot commented on 2014-03-19 08:48

This package is now back to the official release version and replaces the package plymouth-release.

For git, use the plymouth-git package.

padfoot commented on 2014-03-19 05:17

@ 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

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

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

padfoot commented on 2014-03-18 08:49

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.

padfoot commented on 2014-03-15 10:07

Updated PKGBUILD

padfoot commented on 2014-03-08 22:49

Updated the various *-plymouth.service files

padfoot commented on 2014-03-08 08:15

@ 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.

https://wiki.archlinux.org/index.php/AUR_User_Guidelines#Prerequisites

padfoot commented on 2014-03-06 05:08

@ Mello

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

Melo commented on 2014-03-05 21:19

It needs patch as a dependency

Melo commented on 2014-02-23 23:30

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)'

padfoot commented on 2014-02-20 09:34

This build uses /etc/os-release

padfoot commented on 2014-02-11 08:25

@ RibShark

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

Fixed.

RibShark commented on 2014-02-11 07:39

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

@dongfengweixiao

libtool is part of base-devel. Packages of this group shouldn't go to the makedeps.

BTW, now there is plymouth-release
https://aur.archlinux.org/packages/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

@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 :)

padfoot commented on 2014-01-30 05:51

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

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

drism commented on 2014-01-26 23:22

Thanks padfoot, this is working without a hitch.

padfoot commented on 2014-01-26 03:07

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

padfoot commented on 2014-01-26 02:59

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

padfoot commented on 2014-01-25 23:50

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

build req:libtool

dongfengweixiao commented on 2013-12-24 06:20

@ylecuyer pls install libtool

padfoot commented on 2013-12-16 05:51

Downgrading to 0.8.8.50 fixed my splash

padfoot commented on 2013-12-13 22:06

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

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

andreihaiducul commented on 2013-12-04 06:28

@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

Same error here. Is this package still maintained ?

ylecuyer commented on 2013-11-05 01:32

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

@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

Does not work for me:

GEN plymouth.1
I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"
cannot parse http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
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

Also why don't you use the "plymouth-set-default-theme.in.patch" 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

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

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

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

@geric
does other theme work?

geric commented on 2013-10-05 15:28

My config file said

[Daemon]
Theme=spinfinity

So if someone broke spinfinity, thats a different issue.

taylorchu commented on 2013-10-04 15:56

@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

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

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

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

After upgrading to v. 0.8.8.41.g5277809-1 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

Please, add plymouthd.conf to the "backup" array:

backup=("etc/plymouth/plymouthd.conf")

Here is a complete example…:
http://pastebin.com/cZBpqnt9

…where I also added the check() function…

Bye.

grufo commented on 2013-09-26 11:33

Please, add "plymouthd.conf" to the "backup" array…:

backup=("etc/plymouth/plymouthd.conf")

Here is a PKGBUILD example:

http://pastebin.com/cZBpqnt9

Bye.

intelfx commented on 2013-09-24 11:23

Please, update PKGBUILD as here: http://ix.io/8dY .
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

changelog
image size is much smaller now

agomonos commented on 2013-09-18 09:26

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

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.. http://pastebin.com/gkGfXL7a
i just updated this script to read /etc/plymouth/plymouthd.conf.. hope this helps!
thanks!

taylorchu commented on 2013-09-18 01:25

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

Jristz commented on 2013-09-17 22:56

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

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

padfoot commented on 2013-09-12 09:17

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

taylorchu: The new hook works. Thanks.

Good job!

ValHue commented on 2013-09-05 06:53

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

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

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

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

andreihaiducul commented on 2013-09-04 21:07

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

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

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:
https://bbs.archlinux.org/viewtopic.php?id=167718

Anonymous comment on 2013-08-27 02:19

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

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:

https://bbs.archlinux.org/viewtopic.php?id=167718

Anonymous comment on 2013-07-15 06:12

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

Please add pkg-config as a dependency. Thanks

artiom commented on 2013-06-27 14:55

I submitted a bug about quit service:
https://bugs.freedesktop.org/show_bug.cgi?id=66260

Peace4all commented on 2013-06-06 16:14

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

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

Peace4all commented on 2013-06-04 08:53

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: http://bit.ly/10Ntzqc.

ImNtReal commented on 2013-06-03 12:59

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.

Anonymous comment on 2013-05-30 00:34

Same problem as Gonzih, the wait for Plymouth quit service does not start (times out). gdm disabled and gdm-plymouth enabled.

More info: https://bbs.archlinux.org/viewtopic.php?pid=1207410#p1207410

Hopefully someone has a fix.

Anonymous comment on 2013-05-26 19:22

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

libpng15 dependency removed.

Alda commented on 2013-05-20 07:32

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

Alda commented on 2013-05-20 07:32

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

devrs0 commented on 2013-05-19 17:33

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

devrs0 commented on 2013-05-19 17:27

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

Anonymous comment on 2013-05-18 14:15

>> 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

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. :)

Jristz commented on 2013-05-16 03:15

service lxdm-plymouth fail too since was moved to /usr/bin

Anonymous comment on 2013-05-14 17:35

Plymouth still survives in tty1, and plymouthd stresses the CPU.
Any idea?

erikw commented on 2013-05-13 19:26

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

The lightdm binary has been moved from /usr/sbin to /usr/bin in the community package causing the lightdm-plymouth.service to fail.

devrs0 commented on 2013-05-13 17:20

The lightdm binary has been moved from /usr/sbin to /usr/bin in the community package.

ImNtReal commented on 2013-05-13 13:06

It may be a good idea to add libpng15 as an optdepend. I just noticed this while building my kernel image: ERROR: binary dependency `libpng15.so.15' not found for `/usr/lib/plymouth//space-flares.so'

Anonymous comment on 2013-05-06 21:59

in plymouth.initcpio_install the line "add_runscript" has been replaced with "SCRIPT='plymouth'" and this breaks initcpio functionality for me.

Anonymous comment on 2013-03-05 14:17

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.

Anonymous comment on 2013-02-25 01:17

Is encrypt_hook.patch not needed anymore?

Anonymous comment on 2013-02-24 18:42

I can't install this package. The encrypt_hook seems not to match the MD5 code.

ultimA commented on 2013-02-16 19:49

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.

Anonymous comment on 2013-02-13 22:36

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!

Anonymous comment on 2013-01-14 21:23

Hi,
I have created a slim-plymouth.service based on the lxdm version.
See it here: http://pastebin.com/x30nLAJL It could be included with the services distributed in this package.

Anonymous comment on 2013-01-02 15:43

Please update the lightdm-plymouth.service unit file (LightDM won't start otherwise):
http://pastebin.com/AR6kqV2K

faergeek commented on 2012-12-28 14:31

Apply this patch, please. Since mkinitcpio 0.12.0 SCRIPT variable is unused.
See https://projects.archlinux.org/mkinitcpio.git/commit/?id=f85d28014134076217904885ea339e2f4c438df1

--- 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/libnss_files.so.2)"
add_file /lib/libnss_files.so.2

- SCRIPT='plymouth'
+ add_runscript
}

help() {

Anonymous comment on 2012-12-18 16:05

I have following issue with plymouth package and systemd: https://bbs.archlinux.org/viewtopic.php?pid=1207410#p1207410

Thanks!

lmello commented on 2012-12-13 01:30

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

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

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

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, :)

Anonymous comment on 2012-10-31 13:31

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

Jristz commented on 2012-10-31 13:28

https://bbs.archlinux.org/viewtopic.php?id=151765 (read last comments)

aparently users have issues with plymouth and the removal of consolekit

twouters commented on 2012-10-31 12:00

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

Just replace the line : '4dab1b0e23d81907b79b49c2d8d719b5' by 'c970831d733ca42e20415005967e7843'

padfoot commented on 2012-10-26 06:11

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.

M0Rf30 commented on 2012-10-26 00:57

added lightdm-plymouth.service

dracorp commented on 2012-10-25 12:30

diff --git a/PKGBUILD b/PKGBUILD
index 7fa0e0b..c4dacb5 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -42,12 +42,12 @@ source=("http://www.freedesktop.org/software/$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

-> 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

$ namcap plymouth-0.8.6.1-4-i686.pkg.tar.xz
plymouth E: Dependency gtk2 detected and not included (libraries ['usr/lib/libgdk-x11-2.0.so.0', 'usr/lib/libgtk-x11-2.0.so.0'] needed in files ['usr/lib/plymouth/renderers/x11.so'])

ShadowKyogre commented on 2012-10-07 19:15

@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

$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

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

It's because patch 2.7.* was just pulled to [core]: http://lists.gnu.org/archive/html/bug-patch/2012-09/msg00000.html

[...]
* Refuse to apply a normal patch to a symlink. (Previous versions of patch
were replacing the symlink with a regular file.)

Det commented on 2012-10-04 10:34

It's because patch 2.7.* was just pulled to [core]: http://lists.gnu.org/archive/html/bug-patch/2012-09/msg00000.html

diederick76 commented on 2012-10-03 13:55

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]

solstice commented on 2012-08-06 22:05

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

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.

solstice commented on 2012-08-06 17:43

may be it's a typo and should be /run/plymouth.pid ?

solstice commented on 2012-08-06 13:40

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

Can I use it without installing systemd?

martadinata666 commented on 2012-07-14 03:09

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

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 https://wiki.archlinux.org/index.php/DeveloperWiki:UsrMove for more info

Thanks

liquidsky commented on 2012-06-03 13:55

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

You guys can just flag this thing when that happens.

Anonymous comment on 2012-04-29 16:27

encrypt_install ... FAILED when validating source files with sha1sums

Det commented on 2012-01-08 13:56

It's fine now, brah.

vorbote commented on 2012-01-08 13:16

Checksums and patches are failing.

Det commented on 2011-07-31 09:53

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-31 08:30

Synced with plymouth-git. Actually worked just as well as plymouth-git with this machine but your experience may vary.

In case of whatever bugs I recommend to try plymouth-git.

Det commented on 2011-07-30 09:53

Updated. Should work just fine now. Though, plymouth-git is recommended.

CPUnltd commented on 2011-07-15 15:40

==> 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

updated

Det commented on 2010-07-28 16:03

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-28 15:58

If this thing is to work then here's the new pkgver and md5sum: http://aur.pastebin.com/F5UEXJyP

Det commented on 2010-07-27 13:35

Somebody should mention this in the AUR mailing list..

frb commented on 2010-05-06 19:54

0.8.3 is out please update this pkg or leave it orphan.