https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c2 --- Comment #2 from Andrey Borzenkov 2013-06-12 02:30:51 UTC --- (In reply to comment #1)

Hmm, we should not try to restart plymouth-start on failure, when switching runlevel.

It is not limited to switching run levels; the same problem on boot as well if plymouth was not started in initrd.

How did you disable framebuffer ? nomodeset on kernel command line ?

Simply go to yast bootloader and disable "Use graphical console". I do it by habit as in the past using nVidia driver with framebuffer was asking for troubles. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c4 --- Comment #4 from Andrey Borzenkov 2013-06-12 02:58:08 UTC --- (In reply to comment #3)

Starting plymouth in standard boot, if not started in initrd, is expected.

Of course, I mean it will have the same artificial 60 seconds delay.

What is the end result in your case ? could you paste /proc/cmdline ?

it does not change kernel cmdline, it changes how bootloader sets up screen. BOOT_IMAGE=/vmlinuz-3.7.10-1.11-desktop root=/dev/mapper/system-root resume=/dev/system/swap splash=silent quiet showopts rd.plymouth=0 3 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c6 --- Comment #6 from Andrey Borzenkov 2013-06-12 07:34:40 UTC --- (In reply to comment #5)

Do you still have the issue with yesterday package (when switching between runlevel) ?

Yes.

There was an issue (fixed) which was not ignoring udevadm error code in ExecStartPost.

The problem is not exit code but unconditional waiting for non-existent device.

...

...

What is the end result in your case ? could you paste /proc/cmdline ?

it does not change kernel cmdline, it changes how bootloader sets up screen.

BOOT_IMAGE=/vmlinuz-3.7.10-1.11-desktop root=/dev/mapper/system-root resume=/dev/system/swap splash=silent quiet showopts rd.plymouth=0 3

But this shouldn't have an influence on plymouth. Plymouth relies on the kernel framebuffer (or KMS), not on bootloader graphical console.

Of course, but if KMS is disabled kernel defaults to pure text unless either vga= or video= parameter is given or bootloader sets up required video mode before loading kernel. In my case bootloader starts in pure text mode which is then inherited by kernel. And KMS drivers are disabled. It is not directly related to having nvidia. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c8 Robert Milasan changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmilasan@suse.com InfoProvider|rmilasan@suse.com |fcrozat@suse.com --- Comment #8 from Robert Milasan 2013-06-13 03:06:55 UTC --- I'm not sure here how it would be best to fix this. In plymouth-start.service there is: ExecStartPost=-/sbin/udevadm settle --timeout=30 --exit-if-exists=/sys/class/drm/card0/dev ; /sbin/udevadm settle --timeout=30 --exit-if-exists=/sys/class/graphics/fb0/dev ; /usr/bin/plymouth show-splash

From udev point of view, I don't see anything wrong, wait 30 seconds if /sys/class/drm/card0/dev doesn't exist and wait again 30 seconds if /sys/class/graphics/fb0/dev if again it doesn't exist.

Is it possible to move this to systemd somehow to check for /sys/class/graphics/fb0/dev and/or /sys/class/drm/card0/dev and just add: udevadm settle --timeout=30 ? or not use udevadm settle at all in plymouth-start.service? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c10 --- Comment #10 from Robert Milasan 2013-06-13 03:20:08 UTC --- Yes, I know, that’s why I'm not sure what would be the best idea. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c11 Robert Milasan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |arvidjaar@gmail.com --- Comment #11 from Robert Milasan 2013-07-09 14:51:30 UTC --- @Andrey: can you please test this: /bin/udevadm settle --timeout=30 --exit-if-exists=/sys/class/drm/card0/dev --exit-if-exists=/sys/class/graphics/fb0/dev Change this from plymouth-start.service: ExecStartPost=-/sbin/udevadm settle --timeout=30 --exit-if-exists=/sys/class/drm/card0/dev ; /sbin/udevadm settle --timeout=30 --exit-if-exists=/sys/class/graphics/fb0/dev ; /usr/bin/plymouth show-splash to this: ExecStartPost=-/sbin/udevadm settle --timeout=30 --exit-if-exists=/sys/class/drm/card0/dev --exit-if-exists=/sys/class/graphics/fb0/dev ; /usr/bin/plymouth show-splash and let me know if it makes any difference. Anyway I'm not sure if udevadm settle supports --exit-if-exists twice :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c13 --- Comment #13 from Andrey Borzenkov 2013-07-15 02:22:56 UTC --- Created an attachment (id=547869) --> (http://bugzilla.novell.com/attachment.cgi?id=547869) Output of journalctl -b -u systemd-udevd.log after boot with udev.log-level=debug I'm afraid we were misinterpreting symptoms. "udevadm settle" does not wait for a device. It waits for event queue to drain. And for some reason here I always have mismatch between kernel event count and UDEV event count when I boot into run level 3: opensuse:~ # hexdump -e '"%d\n"' -n 2 /run/udev/queue.bin 2064 opensuse:~ # cat /sys/kernel/uevent_seqnum 2065 opensuse:~ # exit So "udevadm settle" always waits for event that never comes. I attach result of "journalctl -b -u systemd-udevd.service" after booting with "udev.log-level=debug rd.udev.log-level=debug". I'm not sure how to capture what happens in initrd though. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c15 Andrey Borzenkov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|arvidjaar@gmail.com | --- Comment #15 from Andrey Borzenkov 2013-07-15 06:26:00 UTC --- I'm running the latest openSUSE 12.3 kernel (kernel-desktop to be sure), 64 bit. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c17 Andrey Borzenkov changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|rmilasan@suse.com |arvidjaar@gmail.com --- Comment #17 from Andrey Borzenkov 2013-07-20 06:33:42 UTC --- Created an attachment (id=548734) --> (http://bugzilla.novell.com/attachment.cgi?id=548734) Output of udevadm monitor --env I made some more tests. 1. It is still reproducible using 3.10.1-3.gb92a291-desktop 2. It usually does not happen when booting straight into run level 5 3. It never happens when booting into run level 1 4. It always happens when booting into run level 3 or changing into run level 3 from run level 1 5. I could not trigger it when switching from run level 1 to run level 5 So I beefed up service that runs udevadm monitor early (at least before run level 1), and so here are results. udev event counter at run level 1 and at run level 3: 1976 2001 kernel event counter at run level 1 and at run level 3 1976 2002 And output of udevadm monitor attached. The last event seen by udev is as expected 2001. So it appears that either kernel erroneously increments event counter without sending event or event gets lost. I wonder ... there was some discussion on systemd-devel recently about lost events in case of containers. I do not use any of them but may be we are facing something similar (control groups?) Is it possible to make kernel more verbose about uevent handling? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c18 Andrey Borzenkov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|arvidjaar@gmail.com | --- Comment #18 from Andrey Borzenkov 2013-07-20 06:34:52 UTC --- Sorry, clicked wrong checkbox. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c20 --- Comment #20 from Andrey Borzenkov 2013-07-22 08:11:21 UTC --- (In reply to comment #19)

Andrey, can you point me to that thread form systemd-devel mailing list?

http://lists.freedesktop.org/archives/systemd-devel/2013-July/011826.html -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c22 Andrey Borzenkov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|arvidjaar@gmail.com | --- Comment #22 from Andrey Borzenkov 2013-07-22 16:59:58 UTC --- Created an attachment (id=548922) --> (http://bugzilla.novell.com/attachment.cgi?id=548922) dmesg from run-level 3 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c24 --- Comment #24 from Frederic Crozat 2013-07-23 13:52:00 UTC --- in both trace, you are booting with "plymouth.enable=0", so plymouth-start.service isn't started at all (due to ConditionKernelCommandLine=!plymouth.enable=0 ) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c25 Robert Milasan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |arvidjaar@gmail.com --- Comment #25 from Robert Milasan 2013-08-19 07:27:57 UTC --- Andrey, did you try to disable or remove plymouth on that system and see what happens? I honestly don't know whats the issue and can't reproduce it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c27 --- Comment #27 from Andrey Borzenkov 2013-08-24 06:57:28 UTC --- (In reply to comment #25)

I honestly don't know whats the issue and can't reproduce it.

OK, I finally was able to determine what triggers it on my system. It is libvirtd.service (libvirt RPM). Disabling it reliably "fixes" the issue with missing uevent. I tried to compare what happens without and with it loaded. For all I can tell the difference is (apart from obvious reordering of events between boots): +KERNEL add /module/x_tables (module) +KERNEL add /module/ebtables (module) +KERNEL add /module/ebtable_nat (module) +KERNEL add /module/ip_tables (module) +KERNEL add /module/iptable_filter (module) +KERNEL add /module/ip6_tables (module) +KERNEL add /module/ip6table_filter (module) KERNEL change /devices/platform/regulatory.0 (platform) +KERNEL add /devices/virtual/net/lo/queues/rx-0 (queues) +KERNEL add /devices/virtual/net/lo/queues/tx-0 (queues) +KERNEL remove /devices/virtual/net/lo/queues/rx-0 (queues) +KERNEL remove /devices/virtual/net/lo/queues/tx-0 (queues) Here additional events are with libvirtd loaded. Events for +KERNEL add /devices/virtual/net/lo/queues/rx-0 (queues) +KERNEL add /devices/virtual/net/lo/queues/tx-0 (queues) are duplicates - there already are the same events before. But without libvirtd there are no remove events for queues. I do not mean to say libvirtd is at fault here but I'm really curious whether someone else can reproduce it. I attach events without and with libvirtd for reference. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c29 --- Comment #29 from Andrey Borzenkov 2013-08-24 06:58:59 UTC --- Created an attachment (id=554046) --> (http://bugzilla.novell.com/attachment.cgi?id=554046) udev events with libvirtd -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c31 Robert Milasan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO CC| |jfehlig@suse.com InfoProvider| |jfehlig@suse.com --- Comment #31 from Robert Milasan 2013-08-24 17:07:39 UTC --- Jim, do you know or heard something about this? Libvirtd issues with kernel and/or udev? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c33 James Fehlig changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|jfehlig@suse.com | --- Comment #33 from James Fehlig 2013-08-26 16:08:48 UTC --- (In reply to comment #31)

Jim, do you know or heard something about this? Libvirtd issues with kernel and/or udev?

Only what Andrey pointed to in #20. And after re-reading the thread it appears there is no resolution. But that particular issue was regarding events generated in a network namespace. According to #30, that is not the case here right? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c35 James Fehlig changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jdouglas@suse.com --- Comment #35 from James Fehlig 2013-09-06 16:18:09 UTC --- Looking at the libvirt code, I see that the LXC driver probes the system for container capabilities when it loads. I assume you no longer see the delay if libvirt-daemon-lxc and libvirt-daemon-driver-lxc packages are removed? But I'm not sure how to proceed since afaict there is no resolution/agreement to the issue described in the thread referenced in #20... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c37 Robert Milasan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO CC| |tittiatcoke@gmail.com InfoProvider| |tittiatcoke@gmail.com --- Comment #37 from Robert Milasan 2013-12-10 10:11:12 UTC --- Could we run an update for 13.1, or it's too late? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c39 --- Comment #39 from Robert Milasan 2013-12-10 10:20:35 UTC --- Sure, I agree, not problems with that. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=824442 https://bugzilla.novell.com/show_bug.cgi?id=824442#c41 Mark van Tinteren changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kigurame@opensuse.org --- Comment #41 from Mark van Tinteren 2014-02-06 02:09:00 UTC --- There's actually quite a few things I’ll be getting things straightened out over the next few days. (probably more around the weekend when i have the most time) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=824442 http://bugzilla.novell.com/show_bug.cgi?id=824442#c43 Robert Milasan changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #43 from Robert Milasan --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.