X fails to start after upgrading from plymouth-0.8.7-1.fc18 to plymouth-0.8.8-1.fc18 using kdm login manager # 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 Sat, 2012-10-27 20:02:16 CDT; 17s ago Main PID: 632 CGroup: name=systemd:/system/plymouth-quit-wait.service Oct 27 20:01:56 localhost.localdomain systemd[1]: Starting Wait for Plymouth Boot Screen to Quit... Oct 27 20:02:16 localhost.localdomain systemd[1]: Failed to start Wait for Plymouth Boot Screen to Quit. Oct 27 20:02:16 localhost.localdomain systemd[1]: Unit plymouth-quit-wait.service entered failed state Xorg.0.log: Fatal server error: [ 22.237] Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices [ 22.237] [ 22.237] (EE) even startx fails similarly
Same problem with my F18, I solve that with downgrade plymouth in init 3 yum downgrade plymouth* And I return with plymouth 0.8.7-1.fc18.
Ditto here. Either downgrade plymouth or systemctl start plymouth-quit.service ; systemctl start kdm.service
Hi, Not only in kde X fails, in Gnome too X fails. Oct 27 16:09:26 localhost gdm-simple-slave[522]: WARNING: Child process 661 was already dead. Oct 27 16:09:26 localhost gdm-simple-slave[522]: GLib-GObject-CRITICAL: g_object_ref: assertion `object->ref_count > 0' failed Oct 27 16:09:26 localhost gdm-simple-slave[522]: GLib-GObject-CRITICAL: g_object_unref: assertion `object->ref_count > 0' failed Oct 27 16:09:26 localhost gdm[492]: gdm-binary[492]: WARNING: GdmDisplay: display lasted 1.242620 seconds Oct 27 16:09:26 localhost gdm-binary[492]: WARNING: GdmDisplay: display lasted 1.242620 seconds It looks like to succeed because: Oct 27 16:09:27 localhost gdm-simple-slave[762]: WARNING: Failed to give slave programs access to the display. Trying to proceed. gdm 'succeeded' but loaded the llvmpipe instead of - in my case - nouveau. This 'succes' was may be the reason why misc gave a +1 in bohdi. Martin Kho
On my laptop (Lenovo X220, Intel Sandybridge) this version of Plymouth caused a fallback to LLVMPipe in gnome-shell. Rolling back the version to 0.8.7-1 fixed it.
could anyone see this post a full log? i reboot a bunch of times but never hit it, so some piece of the puzzle is mssing. i'm doing a full yum update now.
Created attachment 635224 [details] got it to reproduce! it took me over an hour of mindlessly rebooting in a loop, but I finally reproduced. log attached, i haven't had a chance to look over it yet.
> -- Logs begin at Mon, 2012-10-29 16:33:45 EDT, end at Mon, 2012-10-29 16:34:16 EDT. -- > Oct 29 17:23:03 localhost systemd-journal[105]: Allowing runtime journal files to grow to 395.6M. Boot starts > Oct 29 17:23:03 localhost kernel: [drm] Initialized drm 1.1.0 20060810 KMS driver started loading > Oct 29 17:23:03 localhost : [main.c] check_logging:checking if console messages should be redirected and logged Plymouth starting > Oct 29 17:23:03 localhost dracut-initqueue[235]: Mounted root filesystem /dev/sda4 Root filesystem is mounted > Oct 29 17:23:03 localhost : [ply-boot-server.c] print_connection_process_identity:connection is from pid 291 (/usr/bin/plymouth update-root-fs --new-root-dir=/sysroot) with parent pid 1 (/init splash) > Oct 29 17:23:03 localhost : [ply-boot-server.c] ply_boot_connection_on_request:got newroot request > Oct 29 17:23:03 localhost : [main.c] on_newroot:new root mounted at "/sysroot", switching to it plymouth swiveled into the new root fs > Oct 29 17:23:05 localhost kernel: fbcon: inteldrmfb (fb0) is primary device > Oct 29 17:23:06 localhost kernel: Console: switching to colour frame buffer device 180x56 > Oct 29 17:23:06 localhost kernel: fb0: inteldrmfb frame buffer device > Oct 29 17:23:06 localhost kernel: drm: registered panic notifier > Oct 29 17:23:07 localhost kernel: acpi device:3d: registered as cooling_device4 > Oct 29 17:23:07 localhost kernel: ACPI: Video Device [VID1] (multi-head: yes rom: no post: no) > Oct 29 17:23:07 localhost kernel: input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input7 > Oct 29 17:23:07 localhost kernel: [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 KMS driver is ready to go, we can in theory draw now. > Oct 29 17:23:07 localhost kernel: initcall i915_init+0x0/0x68 [i915] returned 0 after 3376533 usecs > Oct 29 17:23:07 localhost systemd[1]: Stopped udev Kernel Device Manager. > Oct 29 17:23:07 localhost systemd[1]: Stopping udev Kernel Socket. > Oct 29 17:23:07 localhost systemd[1]: Closed udev Kernel Socket. > Oct 29 17:23:07 localhost systemd[1]: Stopping udev Control Socket. > Oct 29 17:23:07 localhost systemd[1]: Closed udev Control Socket. > Oct 29 17:23:07 localhost systemd[1]: Starting Cleanup udevd DB... > Oct 29 17:23:07 localhost systemd[1]: Started Cleanup udevd DB. > Oct 29 17:23:07 localhost systemd[1]: Starting Switch Root. > Oct 29 17:23:07 localhost systemd[1]: Reached target Switch Root. > Oct 29 17:23:07 localhost systemd[1]: Starting Switch Root... > Oct 29 17:23:07 localhost systemd[1]: Switching root. systemd is swiveling too now > Oct 29 17:23:07 localhost [105]: Journal stopped > Oct 29 17:23:07 halfline-ssd.usersys.redhat.com systemd-udevd[321]: starting version 195 udev is starting back up > Oct 29 17:23:07 halfline-ssd.usersys.redhat.com : [main.c] on_update:updating status to 'systemd-journald.service' > Oct 29 17:23:07 halfline-ssd.usersys.redhat.com systemd-journal[370]: Journal started > Oct 29 17:23:07 halfline-ssd.usersys.redhat.com systemd[1]: systemd 195 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ; fedora) And systemd is back > Oct 29 17:23:08 halfline-ssd.usersys.redhat.com plymouthd[380]: [main.c] check_verbosity:streaming debug output to /dev/kmsg instead of screen plymouthd is getting started a second time. > Oct 29 17:23:08 halfline-ssd.usersys.redhat.com : [main.c] main:plymouthd is already running But it notices it's already running > Oct 29 17:23:08 halfline-ssd.usersys.redhat.com : [ply-boot-server.c] print_connection_process_identity:connection is from pid 414 (/usr/bin/plymouth show-splash) with parent pid 1 (/usr/lib/systemd/systemd --switched-root --system --deserialize 21) systemd told us to show the splash screen > Oct 29 17:23:08 halfline-ssd.usersys.redhat.com : [./plugin.c] find_controller_for_encoder:Found already lit monitor > Oct 29 17:23:08 halfline-ssd.usersys.redhat.com : [./plugin.c] get_index_of_active_mode:Looking for connector mode index of active mode 1440x900 > Oct 29 17:23:08 halfline-ssd.usersys.redhat.com : [./plugin.c] find_index_of_mode:Found connector mode index 0 for mode 1440x900 > Oct 29 17:23:08 halfline-ssd.usersys.redhat.com : [./plugin.c] ply_renderer_head_add_connector:Adding connector with id 7 to 1440x900 head > Oct 29 17:23:08 halfline-ssd.usersys.redhat.com : [./plugin.c] ply_renderer_head_new:Creating 1440x900 renderer head We've started to show the splash but haven't gotten very far yet > Oct 29 17:23:08 halfline-ssd.usersys.redhat.com systemd[1]: Started Show Plymouth Boot Screen. ah, apparently plymouth show-splash has returned too early, before we've shown the splash > Oct 29 17:23:08 halfline-ssd.usersys.redhat.com gdm-binary[490]: DEBUG(+): Enabling debugging GDM is going now > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [ply-renderer.c] ply_renderer_open_plugin:opened renderer plugin /usr/lib64/plymouth/renderers/drm.so > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] set_keyboard:listening for keystrokes > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] set_keyboard:listening for backspace > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] set_keyboard:listening for enter > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] add_pixel_displays_from_renderer:Adding displays for 1 heads > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] check_for_consoles:After processing serial consoles there are now 1 text displays > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] plymouth_should_show_default_splash:checking if plymouth should show default splash > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] plymouth_should_show_default_splash:using default splash because kernel command line has option "splash" Still haven't completly shown the splash yet. > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com gdm[490]: gdm-binary[490]: DEBUG(+): GdmLocalDisplayFactory: Adding display on seat seat0 > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com gdm[490]: gdm-binary[490]: DEBUG(+): GdmLocalDisplayFactory: Reserving X display: 0 And GDM is still chugging along preparing to start an X server > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [./plugin.c] ply_renderer_head_set_scan_out_buffer:Setting scan out buffer of 1440x900 head to our buffer > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [./plugin.c] activate:taking master and scanning out plymouth has taken control of the display but hasn't drawn anything yet > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [ply-boot-server.c] print_connection_process_identity:connection is from pid 457 (/usr/bin/plymouth update-root-fs --read-write) with parent pid 1 (/usr/lib/systemd/systemd --switched-root --system --deserialize 21) systemd now told plymouth that the root filesystem is now read write. > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] on_update:updating status to 'dbus.service' and plymouthd is getting told about the system bus starting > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] on_update:updating status to 'systemd-logind.service' and now logind. > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] on_update:updating status to 'gdm.service' and now gdm. Since gdm was started earlier, clearly plymouthd is just getting told these messages a little late. > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [ply-boot-server.c] print_connection_process_identity:connection is from pid 619 (/bin/plymouth --ping) with parent pid 584 (/usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Displays/_0) GDM is pinging plymouth > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [ply-boot-server.c] print_connection_process_identity:connection is from pid 622 (/bin/plymouth deactivate) with parent pid 584 (/usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Displays/_0) GDM is telling plymouth to deactivate > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] on_boot_splash_idle:boot splash idle > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] on_boot_splash_idle:deactivating splash > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [main.c] deactivate_splash:deactivating renderer > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [./plugin.c] deactivate:dropping master We do and now drop DRM master > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [ply-boot-server.c] ply_boot_connection_on_deactivated:deactivated > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com gdm-simple-slave[584]: DEBUG(+): GdmServer: Starting X server process: /usr/bin/Xorg :0 -background none -verbose -logverbose 7 -core -auth /var/run/gdm/auth-for-gdm-13rnO8/database -seat seat0 -nolisten tcp vt1 > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com gdm-simple-slave[584]: DEBUG(+): GdmSimpleSlave: Started X server After we finish deactivating GDM tries to start the X server. > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [./plugin.c] on_boot_progress:boot progressed to end > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [./plugin.c] start_end_animation:starting end animation > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [./plugin.c] start_end_animation:hiding progress animation > Oct 29 17:23:09 halfline-ssd.usersys.redhat.com : [./plugin.c] view_start_end_animation:starting end sequence animation for 146x145 view And now plymouth is doing some additional animation when it should be deactivated and not doing anything else > Oct 29 17:23:10 halfline-ssd.usersys.redhat.com gdm-simple-slave[584]: DEBUG(+): GdmSlave: Server is ready - opening display :0 > Oct 29 17:23:10 halfline-ssd.usersys.redhat.com gdm-simple-slave[584]: WARNING: Unable to connect to display :0 GDM fails to connect to X (though this log doesn't really say why) > Oct 29 17:23:10 halfline-ssd.usersys.redhat.com gdm-simple-slave[584]: WARNING: Unable to connect to display after 10 tries - bailing out > Oct 29 17:23:10 halfline-ssd.usersys.redhat.com gdm-binary[490]: DEBUG(+): GdmSlaveProxy: slave (pid:584) done (status:1) > Oct 29 17:23:10 halfline-ssd.usersys.redhat.com gdm-binary[490]: DEBUG(+): GdmDisplay: Slave exited: 1 So it bails. > Oct 29 17:23:10 halfline-ssd.usersys.redhat.com : [ply-boot-server.c] print_connection_process_identity:connection is from pid 788 (/bin/plymouth --ping) with parent pid 786 (/usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Displays/_1) > Oct 29 17:23:10 halfline-ssd.usersys.redhat.com : [ply-boot-server.c] print_connection_process_identity:connection is from pid 789 (/bin/plymouth deactivate) with parent pid 786 (/usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Displays/_1) GDM tries to ping and deactivate plymouth again > Oct 29 17:23:28 halfline-ssd.usersys.redhat.com systemd[1]: plymouth-quit-wait.service operation timed out. Terminating. > Oct 29 17:23:28 halfline-ssd.usersys.redhat.com systemd[1]: Failed to start Wait for Plymouth Boot Screen to Quit. Plymouth doesn't like getting deactivated twice I guess, because 18 seconds go by and stuff starts timing out > Oct 29 17:23:32 halfline-ssd.usersys.redhat.com systemd[1]: Started Console Manager. > Oct 29 17:23:32 halfline-ssd.usersys.redhat.com login[792]: LOGIN ON tty6 BY rstrode > Oct 29 17:23:40 halfline-ssd.usersys.redhat.com [1006]: Process 236 (plymouthd) dumped core. Plymouth crashes > Oct 29 17:23:40 halfline-ssd.usersys.redhat.com systemd[1]: SELinux Got Sender :1.0 > Oct 29 17:23:40 halfline-ssd.usersys.redhat.com systemd[1]: Started Getty on tty6. > Oct 29 17:23:40 halfline-ssd.usersys.redhat.com [1010]: Process 1007 (Xorg) dumped core. X crashes > Oct 29 17:23:43 halfline-ssd.usersys.redhat.com gdm-simple-slave[786]: GLib-GObject-CRITICAL: g_object_ref: assertion `object->ref_count > 0' failed > Oct 29 17:23:43 halfline-ssd.usersys.redhat.com gdm-simple-slave[786]: DEBUG(+): GdmSimpleSlave: Stopping simple_slave > Oct 29 17:23:43 halfline-ssd.usersys.redhat.com gdm-simple-slave[786]: DEBUG(+): GdmSlave: Stopping slave > Oct 29 17:23:43 halfline-ssd.usersys.redhat.com gdm-simple-slave[786]: GLib-GObject-CRITICAL: g_object_unref: assertion `object->ref_count > 0' failed GDM doesn't crash but starts spewing ugly messages and things just go downhill from there.
Created attachment 637200 [details] better log with drm debug
Created attachment 637201 [details] Xorg.0.log
I tried plymouth-0.8.8-3 from koji and it (still) fails when using kdm after the failure, plymouth is still running, manually doing: plymouth --quit systemctl restart kdm brings things back to life. I'll try to carve out some time to help debug this on the kdm side of things. (unless you have better prospects on where the problem is?)
plymouth-0.8.8-3.fc18,gdm-3.6.1-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/plymouth-0.8.8-3.fc18,gdm-3.6.1-4.fc18
Rex, to be sure, you rebuilt in the initrd after updating plymouth?
Ugh, no
Ok, confirmed good but only after rerunning dracut
So, since, as far as I'm aware, no part of the usual update process here includes rebuilding initrd/initramfs afterward, isn't this bug simply going to resurface for everyone on this bug once they get: https://admin.fedoraproject.org/updates/plymouth-0.8.8-3.fc18,gdm-3.6.1-4.fc18 ?? Am I missing something?
well, anytime the kernel gets updated it should get rebuilt. So as long as we get this in for GA, things should be fine.
Glad things are working, by the way! Can you karma?
I'm not sure I can karma++ this in good conscience as it is. upgrading this without a kernel in the transaction still needs X won't start. :(
*shrug* plymouth updates are always like that. I tried to fix it a couple of years ago by giving plymouth it's own initrd, but some of the pieces never landed and grub stopped supporting multiple initrds.
> upgrading this without a kernel in the transaction still needs X won't start. :( Only if you previously had the broken build. If you're upgrading from F17, everything will be fine once this is in. So please let it go through to stable.
Package plymouth-0.8.8-3.fc18, gdm-3.6.1-4.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing plymouth-0.8.8-3.fc18 gdm-3.6.1-4.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17794/plymouth-0.8.8-3.fc18,gdm-3.6.1-4.fc18 then log in and leave karma (feedback).
(In reply to comment #21) > Package plymouth-0.8.8-3.fc18, gdm-3.6.1-4.fc18: > * should fix your issue, > * was pushed to the Fedora 18 testing repository, > * should be available at your local mirror within two days. > Update it with: > # su -c 'yum update --enablerepo=updates-testing plymouth-0.8.8-3.fc18 > gdm-3.6.1-4.fc18' > as soon as you are able to. > Please go to the following url: > https://admin.fedoraproject.org/updates/FEDORA-2012-17794/plymouth-0.8.8-3. > fc18,gdm-3.6.1-4.fc18 > then log in and leave karma (feedback). You say that solve problem with gdm, but I use kdm, Is that solve also the problem with kdm ?
Hi, In Gnome everything is fine, no quirks in /var/log/messages. There was a kernel update too, In KDE I had - like Rex had to - to run dracut --force - no kernel update -, and all is fine now. Thanks, Martin Kho Btw. No karma, because I've no FAS account.
(In reply to comment #23) > Hi, > > In Gnome everything is fine, no quirks in /var/log/messages. There was a > kernel update too, In KDE I had - like Rex had to - to run dracut --force - > no kernel update -, and all is fine now. > > Thanks, > > Martin Kho > > Btw. No karma, because I've no FAS account. And you think that is a good thing ? For me no, it's a regression...
Hi Dominique, You mean running "dracut --force" after the update I suppose. That could maybe be better, but the issue it self is - for me at least - solved. That is great. And it's still Fedora 18 somewere around beta state. Had it happened after release, then it would be a different story. So: "regression..."? I wouldn't call it that way. To me it's more a 'development risk', which I can live with. :-) Martin Kho
halfline, I suppose adding 'dracut -f' to plymouth %post or %posttrans isn't an option (unreliable or poses some other risk)?
Or even more evil (and risky.. :) ), add to kernel.spec for each kernel variant, %tiggerin -- plymouth dracut -f ... which ought to ensure initramfs's get regnerated automatically on plymouth updates
(In reply to comment #25) > Hi Dominique, > > You mean running "dracut --force" after the update I suppose. That could > maybe be better, but the issue it self is - for me at least - solved. That > is great. And it's still Fedora 18 somewere around beta state. Had it > happened after release, then it would be a different story. So: > "regression..."? I wouldn't call it that way. To me it's more a 'development > risk', which I can live with. :-) > > Martin Kho OK, that also work for me, I do "dracut --force" after update plymouth. Sorry for "regression" it's excessive, but for me, add a command after an update is not "natural", I know that Fedora 18 is a beta, and I hope this will be fixed for the release of F18. For me it's not a problem, I test F18 beta for tracking bugs, (I think I am an advanced user, I am with Fedora since FC5), but for new user this could be prohibitive ... Amicalement Dominique
I wouldn't fill comfortable adding dracut -f to rpm scriplets , especially this late in the F18 cycle. Regenerating the initrd has side effects. It also updates dracut for instance. There is some risk to it. When plymouth was first added to the distro the consensus at the time was it was a bad idea. We could potentially revisit that, but I wouldn't want to do it for F18. Note, to completely fully upgrade plymouth, we'd have to regenerate every installed initrd, not just the one associated with the running kernel. Doing that seems suboptimal. The best solution, I think, is to give plymouth it's own initrd. We should revisit that, but status quo isn't that bad. We don't do plymouth updates that often.
@dominique: > Sorry for "regression" it's excessive, but for me, add a command after an > update is not "natural", > I know that Fedora 18 is a beta, and I hope this will be fixed for the release > of F18. As I explained in my comment #20, you only have to run dracut manually (or use /usr/libexec/plymouth/plymouth-update-initrd which runs dracut) if you had the broken version of plymouth. When upgrading from F17 to F18 with the fixed plymouth build, you will NOT need to rerun dracut manually!
3 people confirmed it working, setting status to verified. Those of you, who experienced the issue, and now see it fixed, please provide karma to Bodhi. Thanks.
In my system fully updated fedora 18 this still happens, I can startx manually but after boot the is not kdm or gdm or lightdm (tested the 3 of them). Removed plymouth, re installed and did dracut --force and still no dm at bootup.
Joseph, from what I understand, this report is about plymouth breaking DM, so if you removed plymouth and you don't get a DM, it's probably a different problem. The update already went stable, so I'll close this report and please file a new one with full logs regarding your issue. Thanks.
*** Bug 875474 has been marked as a duplicate of this bug. ***
upgraded from f17 to f18 today. with the f18 kernel i am not able to bootup beyond a blank screen after the grub menu. with the f17 kernel, i am able to boot but it is fussy. 1 time it gave me the kdm log in screen the other time it dint.. it jumped out of the plymouth progress bar and into the cli. systemctl status plymouth-quit-wait.service showed Active: failed (Result: timeout) since Fri, 2013-01-18 05:28:56 EST; 5min ago systemctl start plymouth-quit.service ; systemctl start kdm.service gave me the kdm login screen. this is not nice as it is the family desktop and they wont know how to do that.
I'm experiencing the same issue as MOhammed Arafa. I tried to do a dracut -f, but that did not fix it.