As the title says, plymouth cannot show animations in the reboot or in the shutdown process for intel graphics. When the shutdown process starts, plymouthd tries to start; the screen shows the splash for a very short moment and then sweitches back to the text mode and then the process of shutting down/rebooting continues. The strange thing is that the same whole plymouth works completely fine on another laptop with radeon hardware but with 99% identical packages and configurations (They become updated at the same time with the same profiles/keyworded packages, etc.). I don't know why it fails for the intel driver. I have attached the plymouth log for the shutdown process. I have digged every possible website or source of information with "plymouth" keyword and after one week of searching and doing everything I could do (like testing different patched kernels), in vain, I am here. I admit that, some other people *in the past* had reported that even with intel it works fine. ================================================================================ emerge --info: Portage 2.1.11.55 (default/linux/amd64/13.0/desktop/kde, gcc-4.7.2, glibc-2.15-r3, 3.8.2-pf x86_64) ================================================================= System uname: Linux-3.8.2-pf-x86_64-Intel-R-_Core-TM-_i3_CPU_M_380_@_2.53GHz-with-gentoo-2.1 KiB Mem: 3841516 total, 2319416 free KiB Swap: 4194300 total, 4194300 free Timestamp of tree: Sat, 20 Apr 2013 20:15:01 +0000 ld GNU ld (GNU Binutils) 2.22 distcc 3.1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3, 4.7.2-r1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.7 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo tlp linuxsystems science x-lymnprtg my_local ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA AdobeFlash-11.x PUEL sun-bcla-java-vm skype-eula dlj-1.1 RTCW-ETEULA AdobeFlash-10.3 AdobeFlash-10 Nero-EULA-US skype-4.0.0.7-copyright Intel-SDP" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /usr/share/polkit-1/actions /usr/share/themes/oxygen-gtk/gtk-2.0" CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo" CXXFLAGS="-O2 -march=native -pipe" DISTDIR="/usr/portage/distfiles/" EMERGE_DEFAULT_OPTS="--keep-going --jobs=8 --load-average=8.0 --with-bdeps y" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms unknown-features-warn unmerge-logs unmerge-orphans userfetch xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://trumpetti.atm.tut.fi/gentoo/ http://portage.org.ua/" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-z,now,--as-needed,-O1,--hash-style=gnu,--sort-common" MAKEOPTS="-j5 -l8" PKGDIR="/usr/portage/GentooPackages/" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/usr/portage/prtgtmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/lymnprtg/tlp /usr/portage/lymnprtg/linuxsystems /usr/portage/lymnprtg/science /usr/portage/lymnprtg /usr/portage/lymnprtg/localoverlays" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="3dnow 3dnowext 3gp X a52 aac aalib acl acpi alsa amd64 amr archive asf automount avahi berkdb bittorrent blas bluetooth bmp branding bzip2 cairo cdda cddb cdio cdparanoia cdr cli consolekit cracklib crypt cups cxx dbus declarative directfb djvu double-precision dri dts dv dvb dvd dvdnav dvdr emboss encode exif faac faad fam fbcon fbcondecor fbsplash ffmpeg firefox flac flash fortran fortran95 fuse gdbm gif gmp gpg gpm gstreamer gtk gzip h323 html iconv id3tag inotify ipv6 jingle jpeg jpeg2k kde kipi lame lapack lcms ldap libnotify live lm_sensors lzma mad matroska mjpeg mms mmx mmxext mng modules mozilla mp3 mp4 mpeg mudflap multilib ncurses network nfs nls nptl nptlonly nsplugin ogg ogm openal opengl openmp oss pam pango pcre pdf phonon plasma png pnm policykit postscript ppds python3 qt3support qt4 quicktime rar readline samba scanner sdl search semantic-desktop session sftp sip slp smp socks socks5 spell sse sse2 sse3 sse4 sse4_1 sse4a ssh ssl ssse3 startup-notification stream svg symlink taglib tcpd theora tiff tk truetype type3 udev udisks unicode upower usb v4l vaapi vcd vcdx vlm vorbis vpx wav wavpack webgl wifi wma wmf wxwidgets x264 xattr xcb xcomposite xinerama xml xpm xscreensaver xv xvid yahoo youtube zeroconf zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DRACUT_MODULES="plymouth" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en ar fa" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="gt68xx" USERLAND="GNU" VIDEO_CARDS="intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, USE_PYTHON ================================================================================ The output of emerge: emerge -pv dracut plymouth plymouth-openrc-plugin Calculating dependencies... done! [ebuild R ~] sys-kernel/dracut-027-r1 USE="optimization -debug -device-mapper -net (-selinux)" DRACUT_MODULES="plymouth -biosdevname -bootchart -btrfs -caps -cifs -crypt -crypt-gpg -crypt-loop -dmraid -dmsquash-live -gensplash -iscsi -livenet -lvm -mdraid -multipath -nbd -nfs -ssh-client -syslog -systemd" 0 kB [ebuild R ~] sys-boot/plymouth-openrc-plugin-0.1.2 0 kB [ebuild R ~] sys-boot/plymouth-0.8.8-r1 USE="libkms openrc pango -debug -gdm -gtk -static-libs -systemd" VIDEO_CARDS="intel -radeon" 0 kB I have build them almost ten times with different sets of flags (like -optimizations +caps etc.), but have gotten the same results. Thank you for your efforts for bringing such a nice OS to us, anyway. Reproducible: Always
Created attachment 346360 [details] Kernel configuration for gentoo-sources-3.8.1
Created attachment 346362 [details] Plymouth shutdown log
That's weird. It works for me™, and I have intel HD 4000. Which model is yours?
And do you use any initramfs? If so, which tool do you use to generate it?
(In reply to comment #3) > That's weird. It works for me™, and I have intel HD 4000. Which model is > yours? It's an Arrandale cpu combined with an Ironlake gpu (aka intel hd) The cpu: http://ark.intel.com/products/50178 The gpu: http://en.wikipedia.org/wiki/Comparison_of_Intel_graphics_processing_units#Fifth_generation It's really weird. In your idea is it more related to the kernel itself or to the driver, i.e. xf86-vidoe-intel? I should mention that I have not tested different intel drivers. Thus, I think I should give different verison of the intel driver a try. I'll inform you of the result.
(In reply to comment #4) > And do you use any initramfs? If so, which tool do you use to generate it? I used dracut for producing the initramfs. The only module was plymouth. emerge -pv dracut [ebuild R ~] sys-kernel/dracut-027-r1 USE="optimization -debug -device-mapper -net (-selinux)" DRACUT_MODULES="plymouth -biosdevname -bootchart -btrfs -caps -cifs -crypt -crypt-gpg -crypt-loop -dmraid -dmsquash-live -gensplash -iscsi -livenet -lvm -mdraid -multipath -nbd -nfs -ssh-client -syslog -systemd" 0 kB
(In reply to comment #3) > That's weird. It works for me™, and I have intel HD 4000. Which model is > yours? Also, could you please kindly let me know your configuration (kernel, intel driver and other related information) so that I can try to check the issue with your configuration as well?
the video-intel driver does not matter at all in my understanding. You are not under X11, so the X DDX driver is not involved at all. Only KMS and drm are to my understanding. And I think they are not the problem at all. I use dracut too. Do you use openrc? With the sys-boot/plymouth-openrc-plugin ?
(In reply to comment #8) > the video-intel driver does not matter at all in my understanding. You are > not under X11, so the X DDX driver is not involved at all. Only KMS and drm > are to my understanding. And I think they are not the problem at all. > > I use dracut too. Do you use openrc? With the > sys-boot/plymouth-openrc-plugin ? Yes, you are right because I just tested different versions (stable and keyworded) with the same results. Furthermore, I now remember that I did a lot of tricks to test the issue and one of them were in the time when I had disabled xdm. So, this is only kernel related. I have tested (3.7.1/3.7.4/3.8.1/3.8.2 pf/gentoo) and now I am going to test vanilla 3.9.rc8 and 3.6.x and 3.5.x. This is going to be an epic testing! What a stubborn bug to kill...
I don't think it is kernel either. That's why I asked about openrc and the plugin. It might just be a wrong communicatin between the init system and plymouth. But since I don't use openrc it is a bit hard for me to understand if this can be the case or not. And I just realized that I'm listed as the maintainer of the openrc plugins.... well since proxy-maint is in CC: guys can you please remove me from that? I maintain plymouth and that's ok but I have only systemd on my only gentoo system, can't test the openrc plugin. Sorry.
(In reply to comment #9) > > sys-boot/plymouth-openrc-plugin ? Yes, [ebuild R ~] sys-boot/plymouth-openrc-plugin-0.1.2 0 kB While diggin every website and downloading irc logs to find something useful, I got this: https://github.com/aidecoe/plymouth-openrc-plugin/issues/2 A gentoo user explained a problem, but I don't think it is related. What's your idea? Furthermore, the plugin is two years old. Also, did you have a chance to have a look at the plymouth debug log?
(In reply to comment #10) > I don't think it is kernel either. That's why I asked about openrc and the > plugin. It might just be a wrong communicatin between the init system and > plymouth. > > But since I don't use openrc it is a bit hard for me to understand if this > can be the case or not. > > And I just realized that I'm listed as the maintainer of the openrc > plugins.... well since proxy-maint is in CC: guys can you please remove me > from that? I maintain plymouth and that's ok but I have only systemd on my > only gentoo system, can't test the openrc plugin. Sorry. Hmmmm. I changed my idea accordingly. I am going to test systemd instead of the kernel testing. Just because gentoo was udev friendly, I stayed with udev to avoid bugs. But now it seems that it might be worth to change to systemd. I will install systemd and will report the results.
(In reply to comment #11) > A gentoo user explained a problem, but I don't think it is related. What's > your idea? > Furthermore, the plugin is two years old. > Also, did you have a chance to have a look at the plymouth debug log? My idea is that plymouth-openrc-plugin is no more maintained [I don't maintain it, again I was not even aware I was the maintainer of that package in gentoo O_O], so it should just be removed. I looked at the log, but I don't really understand what's going on. This is pretty sad I know, sorry about that, but I can't work on plymouth-openrc-plugin. Let's hope someone will step up to maintain it. If you want to try other kernels feel free to do so, but I think the problem is the openrc plugin. It is 2 years old, no surprise it is going to break. So dont' want to waste your time. The intel KMS and drm code are pretty solid, I really doubt the problem is the kernel. About systemd: why not just dropping plymouth? I mean having plymouth doesn't sound as a good reason to switch init system, really. You are going to hit bigger problems with systemd. Also systemd in gentoo is in an experimental stage. It is far from being well supported. This is not to change your mind, this is just to let you know what your are going to find. Indeed your help is welcome if you want to contribute :)
(In reply to comment #13) > (In reply to comment #11) > > A gentoo user explained a problem, but I don't think it is related. What's > > your idea? > > Furthermore, the plugin is two years old. > > Also, did you have a chance to have a look at the plymouth debug log? > > My idea is that plymouth-openrc-plugin is no more maintained [I don't > maintain it, again I was not even aware I was the maintainer of that package > in gentoo O_O], so it should just be removed. Thank you anyway for your nice and quick replies. > > I looked at the log, but I don't really understand what's going on. > :( > This is pretty sad I know, sorry about that, but I can't work on > plymouth-openrc-plugin. Let's hope someone will step up to maintain it. > It is completely OK. The gentoo users would be grateful if you could offer a person to maintain it. > If you want to try other kernels feel free to do so, but I think the problem > is the openrc plugin. It is 2 years old, no surprise it is going to break. > So dont' want to waste your time. The intel KMS and drm code are pretty > solid, I really doubt the problem is the kernel. > You are right. > About systemd: why not just dropping plymouth? I mean having plymouth > doesn't sound as a good reason to switch init system, really. You are going > to hit bigger problems with systemd. Also systemd in gentoo is in an > experimental stage. It is far from being well supported. This is not to > change your mind, this is just to let you know what your are going to find. > I actually came over again to say that, after a brief searching, I found the new init system experimental in gentoo (exactly as you stated) and there were some complaints about it with some bugs unanswered in the forum (eeeeeie...). Simply I became too afriad to switch to it since it might break many things while I do rely on openrc and its way of init scripting and have my own custom stuff. Thus, it's not wise to switch to it unless Gentoo officials officially support it with a clear change of the default init system. > Indeed your help is welcome if you want to contribute :) I will try to have a look on the openrc plugin for plymouth. I think it will be more beneficial than changing the whole layout just to have plymouth and then become trapped in its bugs (And it seems that after switching to systemd, people have had problems switching back to openrc). Thus, you can leave this bug either "opened" or just "won't fix until a maintainer for the plugin appears." Thank you very much for your support and company.
I'll leave it open, at least for now. What now puzzle me is that on you AMD hardware it is working. It is still a weak argument given the plugin is 2 year old and not maintained, but still....
(In reply to comment #10) > And I just realized that I'm listed as the maintainer of the openrc > plugins.... well since proxy-maint is in CC: guys can you please remove me > from that? I maintain plymouth and that's ok but I have only systemd on my > only gentoo system, can't test the openrc plugin. Sorry. + 25 Apr 2013; Sergey Popov <pinkbyte@gentoo.org> metadata.xml: + Drop maintainer by his request, remove proxy maintainers herd, reassigning to + maintainer-needed All done
(In reply to comment #16) > + 25 Apr 2013; Sergey Popov <pinkbyte@gentoo.org> metadata.xml: > + Drop maintainer by his request, remove proxy maintainers herd, > reassigning to > + maintainer-needed > > All done Thank you Sergey
commit 7f805bae938b58b86f697da02258e2ebe0372981 Author: Sam Jorna <wraeth@gentoo.org> Date: Tue Apr 26 20:21:36 2016 +1000 sys-boot/plymouth: remove proxy maintainer Proxy maintainer has requested to drop the package per mail to the project. Removing both maintainer and project from metadata.xml.
FWIW, I installed plymouth-openrc-plugin today on a Lenovo T61 w/ Intel graphics following the instructions available at https://wiki.gentoo.org/wiki/Plymouth . Everything works as expected, showing the splash at boot, reboot and shutdown. I tested both with and without an initramfs (generated through genkernel-next-64) with the same results (except that w/o the iniramfs the splash starts after around 20 lines of OpenRC loading services etc). I tested once available themes, but extensively performed my tests with "spinfinity" one. Incidentally, I misread the Wiki and masked >plymouth-0.9.0 (instead of >=) and everything worked fine w/ 0.9.0 too. I then tried 0.9.2 but got some artifacts during boot. Now I'm back to plymouth-0.8.8-r4 in order to fill this information. Since the original submitter was using gentoo-sources-3.8.1 and current stable (the one I'm using) is now gentoo-sources-4.4.6, I'd ask to test again, as the plymouth-openrc-plugin seems to work fine here (and, by reading the available source code, it doesn't look obsolete in regards to openrc code). I'm available to provide further information if needed. Pasting emerge --info produces an error (message too long), so I will attach it as a file. The currently (relevant) installed packages: danae ~ # emerge genkernel-next plymouth plymouth-openrc-plugin -pv These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-boot/plymouth-0.8.8-r4::gentoo USE="gtk libkms pango -debug -gdm -static-libs" VIDEO_CARDS="intel -radeon" 0 KiB [ebuild R ] sys-kernel/genkernel-next-64::gentoo USE="plymouth -cryptsetup -dmraid -gpg -iscsi -mdadm (-selinux)" 0 KiB [ebuild R #] sys-boot/plymouth-openrc-plugin-0.1.2::gentoo 0 KiB
Created attachment 444776 [details] Output of emerge --info (on working system)
Created attachment 444778 [details] Kernel configuration for gentoo-sources-4.4.6
thanks for testing, unmasked
Incidentally, I believe this has nothing directly to do with Intel graphics, but rather the fact that the plugin orders Plymouth to terminate almost immediately after starting up, at which point it may or may not have had time to actually show the splash screen, depending on graphics hardware. https://github.com/tlhonmey/plymouth-openrc-plugin has a fixed version that waits until mount-ro (near the end of the shutdown) to terminate Plymouth instead of doing it at localmount (which is near the beginning in most cases.) Since aidecoe is no longer maintaining the plugin, how do you want to handle this? Specifically, should I create a new bug since this one was marked resolved, even though the root cause really wasn't?
