On Fri, 06.03.15 14:22, Daniel Drake ([email protected]) wrote: > Hi, > > I'm looking at some issues with the plymouth boot splash system, and > why it intermittently fails to get graphics on screen. > > plymouth watches for the creation of drm display devices during boot. > If it finds one, it starts a graphical splash and that is that. > However, if the system finishes loading drivers and no drm device is > available, it falls back onto a fbdev-based splash or a text-based > boot. Once it has made that choice there is no turning back, it > basically ignores drm devices if they become available later.
To my knowledge newer versions don't do this anymore and actively watch drm devices coming. > Firstly, plymouth does the above when it loads in the initramfs. The > initramfs will trigger udev events for all devices, but if systemd > finds the root filesystem before plymouth finds the drm device, udevd > is immediately killed by systemd as it changes to > switch-root.target. > > udevd has not processed the drm device at this point, so > udev_device_get_is_initialized() returns false when plymouth inquires. > As udevd is killed, it removes /run/udev/queue in its exit path; > plymouth sees this and (like udevsettle would) assumes that this > apparently empty queue means that driver loading is complete. But no > drm devices are available and initialized, so it falls back to textual > boot for the rest of boot. > > The killing of udev seems heavy-handed here, and the way it removes > the queue file on exit (without first at least going through the > already-pending events) seems to kill any possibility of a program > like udevsettle or plymouth knowing if udev finished loading all > drivers while the initramfs transitions to the real root. No, applications should not watch the queue. And the file is internal to udev anyway. If you watch it, you get to keep the pieces. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
