Bug 870695

Summary: X fails to start after upgrading to plymouth-0.8.8-1.fc18
Product: [Fedora] Fedora Reporter: Rex Dieter <rdieter>
Component: plymouthAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: andreas.bierfert, andrew, bugzilla, chepioq, ericsbinaryworld, fedora, jmarrero, kalevlember, kevin, kparal, lists.kho, mads, martin, mattia.verga, mclasen, mwoehlke.floss, neil, redhat, reklov, rmatos, robatino, rstrode
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-14 05:00:21 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 752660, 846844    
Attachments:
Description Flags
got it to reproduce!
none
better log with drm debug
none
Xorg.0.log none

Description Rex Dieter 2012-10-27 21:33:18 EDT
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
Comment 1 dominique 2012-10-28 04:22:49 EDT
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.
Comment 2 Neil Darlow 2012-10-28 04:31:07 EDT
Ditto here. Either downgrade plymouth or

systemctl start plymouth-quit.service ; systemctl start kdm.service
Comment 3 Martin Kho 2012-10-28 05:58:02 EDT
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
Comment 4 Andrew Hutchings 2012-10-29 15:16:21 EDT
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.
Comment 5 Ray Strode [halfline] 2012-10-29 16:00:03 EDT
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.
Comment 6 Ray Strode [halfline] 2012-10-29 17:30:35 EDT
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.
Comment 7 Ray Strode [halfline] 2012-10-29 18:59:30 EDT
> -- 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.
Comment 8 Ray Strode [halfline] 2012-11-02 14:45:28 EDT
Created attachment 637200 [details]
better log with drm debug
Comment 9 Ray Strode [halfline] 2012-11-02 14:45:54 EDT
Created attachment 637201 [details]
Xorg.0.log
Comment 10 Rex Dieter 2012-11-07 12:48:46 EST
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?)
Comment 11 Fedora Update System 2012-11-07 12:52:47 EST
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
Comment 12 Ray Strode [halfline] 2012-11-07 14:09:05 EST
Rex,
to be sure, you rebuilt in the initrd after updating plymouth?
Comment 13 Rex Dieter 2012-11-07 15:15:00 EST
Ugh, no
Comment 14 Rex Dieter 2012-11-07 15:28:29 EST
Ok, confirmed good but only after rerunning dracut
Comment 15 Rex Dieter 2012-11-08 10:26:19 EST
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?
Comment 16 Ray Strode [halfline] 2012-11-08 10:32:08 EST
well, anytime the kernel gets updated it should get rebuilt.  So as long as we get this in for GA, things should be fine.
Comment 17 Ray Strode [halfline] 2012-11-08 10:32:58 EST
Glad things are working, by the way! Can you karma?
Comment 18 Rex Dieter 2012-11-08 13:18:30 EST
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. :(
Comment 19 Ray Strode [halfline] 2012-11-08 14:17:56 EST
*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.
Comment 20 Kevin Kofler 2012-11-08 16:42:55 EST
> 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.
Comment 21 Fedora Update System 2012-11-08 22:18:04 EST
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).
Comment 22 dominique 2012-11-09 00:22:11 EST
(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 ?
Comment 23 Martin Kho 2012-11-09 07:01:17 EST
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.
Comment 24 dominique 2012-11-09 12:12:26 EST
(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...
Comment 25 Martin Kho 2012-11-09 13:04:12 EST
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
Comment 26 Rex Dieter 2012-11-09 13:10:04 EST
halfline, I suppose adding 'dracut -f' to plymouth %post or %posttrans isn't an option (unreliable or poses some other risk)?
Comment 27 Rex Dieter 2012-11-09 13:12:48 EST
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
Comment 28 dominique 2012-11-09 13:47:42 EST
(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
Comment 29 Ray Strode [halfline] 2012-11-09 13:58:06 EST
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.
Comment 30 Kevin Kofler 2012-11-09 19:46:20 EST
@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!
Comment 31 Kamil Páral 2012-11-12 08:55:35 EST
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.
Comment 32 Joseph Marrero 2012-11-13 23:33:10 EST
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.
Comment 33 Kamil Páral 2012-11-14 05:00:21 EST
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.
Comment 34 Adam Williamson 2012-11-15 21:25:49 EST
*** Bug 875474 has been marked as a duplicate of this bug. ***
Comment 35 Mohammed Arafa 2013-01-18 05:39:34 EST
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.
Comment 36 Eric Mesa 2013-01-20 18:25:00 EST
I'm experiencing the same issue as MOhammed Arafa.  I tried to do a dracut -f, but that did not fix it.