Note: this is largely informational, as I have a possible solution. But that solution may not work in every case. The current version of plymouth relies on udev to inform it when drm or framebuffer devices become available. When a drm device becomes available, it will be immediately chosen as the output device for the splash screen. When a framebuffer device becomes available, however, it will be ignored until a programmable timeout has expired. Obviously the intent here is to choose drm devices in preference to framebuffer devices (as they will generally give a higher quality display). The default value for the timeout is 5 seconds. This leads to a problem on both machines in my possession. udev reports the availability of the framebuffer device as soon as plymouthd starts. But when the timeout expires, udev reports that the framebuffer device is not initialised. Experimenting with different timeouts, I've found that there is a window between roughly 2.5 seconds and 5.5 seconds after plymouthd starts when this happens. My unconfirmed theory is that this coincides with the handover from the initial ramdisk to the real file system. This is a particular issue for the Live DVDs because they exclude the radeon, nouveau, and i915 drivers from the initial ramdisk. The comment in the dracut configuration file that does this is that this is to allow display-driver-helper to work. My assumption is that this is to do with selecting between free and proprietary drivers. So, on most hardware, the Live DVDs will cause Plymouth to fall back to using the framebuffer device, and, due to this bug, that may cause it to further fall back to text mode. This can be fixed on my hardware by increasing the timeout value to 6 seconds (although this does hit another problem on the machine with Optimus graphics, and that needs 7 or 8 seconds in order for the splash to be displayed on the right screen). But finding a delay that works for all hardware could be tricky... My proposed solution is to include the radeon, nouveau, and i915 drivers in the initial ramdisk. After all, we now default to using the free drivers (and at the moment, there are almost no working proprietary drivers anyway...). If a user chooses to enable use of the proprietary drivers, we can always use the rd.driver.blacklist option to prevent the free drivers being loaded.
commit adc242e6351cee613f2494ba7261f414d120e9f0 Author: Martin Whitaker <mageia@...> Date: Sun Dec 4 20:20:02 2016 +0000 live-dracut.conf: no longer omit radeon, nouveau, i915 (mga#19890). Plymouth no longer works reliably if the drm drivers are not present in the initial ramdisk. This will need wider testing to be sure it doesn't have any unwanted side effects. See the bug report for more details. --- Commit Link: http://gitweb.mageia.org/software/build-system/draklive-config/commit/?id=adc242e6351cee613f2494ba7261f414d120e9f0
(In reply to Mageia Robot from comment #1) > commit adc242e6351cee613f2494ba7261f414d120e9f0 > Author: Martin Whitaker <mageia@...> > Date: Sun Dec 4 20:20:02 2016 +0000 > > live-dracut.conf: no longer omit radeon, nouveau, i915 (mga#19890). > This should most likely be done now as: add_drivers+=" amdgpu radeon nouveau i915 " to ensure they are all available really early in boot process...
CC: (none) => tmb
Actually looking on -sta1 isos shows thats exactly what I did :)
CC: (none) => anaselli
(In reply to Thomas Backlund from comment #2) > This should most likely be done now as: > > add_drivers+=" amdgpu radeon nouveau i915 " > > to ensure they are all available really early in boot process... OK. They appear to get added by default, but it never hurts to make sure! My only concern was whether this might prevent harddrake switching to the nvidia drivers. I don't have any suitable hardware to test this.
A similar problem is described in bug https://bugs.mageia.org/show_bug.cgi?id=15230 (see comment #32) and was caused by the plymouth invoked with the command line option "hide-splash".
CC: (none) => ghibomgx
(In reply to Giuseppe Ghibò from comment #5) > A similar problem is described in bug > https://bugs.mageia.org/show_bug.cgi?id=15230 (see comment #32) and was > caused by the plymouth invoked with the command line option "hide-splash". That bug has to do with too many installed kernels slowing down dkms checks on boot, which is completely unrelated to this.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=19984
commit 1e3611bee44cae58bc5278061e9cabebfbecec71 Author: Martin Whitaker <mageia@...> Date: Sun Dec 18 09:03:25 2016 +0000 live-dracut.conf: ensure drm drivers are available early in boot sequence. As advised by tmb in mga#19890. This is needed to ensure plymouth doesn't fall back to text mode. --- Commit Link: http://gitweb.mageia.org/software/build-system/draklive-config/commit/?id=1e3611bee44cae58bc5278061e9cabebfbecec71
I have only seen the proper splash screen during bootup about 4 or 5 times since July 2016, after installing STA1. Otherwise I only get the grey/??? screen on every boot... for more than half a year now. :(
CC: (none) => jdchoate
Using the following set of workarounds/hacks/swiss-knife in the boot cmdline, as well as removing or disabling some service/package I was able to prevent or get rid of boot timeouts and grey screens: 1) Add "nouveau.modeset=0 rd.plymouth=0 plymouth.enable=0" in /etc/default/grub (for grub2), appending in the GRUB_CMDLINE_LINUX_DEFAULT="..." this will disable plymouth at boot and in the initrd. You have to rebuild the initrd image with dracut as well as the grub.cfg with grub2-mkconfig -o /boot/grub2/grub.cfg). Sometimes you have to also append "nomodeset". It will also disable the nouveau kernel module auto loading (for those having nvidia+intel card where nouveau interferes). 2) Uninstall the package s2u and disable or uninstall avahi; this will get rid of 2 minutes timeout each provided from scripts in /etc/sysconfig/network-scripts/hostname.d/*; one of those 2 minutes timeout comes from avahi when the hostname is "localhost", and you have the network topology that might change at each boot, such as, for instance, a network card that comes from a pluggable device, such as an USB->ethernet adapter. 3) Replace the string "hide-splash" with "debug" in /usr/share/harddrake/service_harddrake; this will avoid the modeset change again from plymouth calls.
There is a slightly newer package of plymouth in updates_testing/ for caudron. Might be worthwhile to try it.
(In reply to Giuseppe Ghibò from comment #10) > There is a slightly newer package of plymouth in updates_testing/ for > caudron. Might be worthwhile to try it. Why? The upstream commit log doesn't show anything related to this bug. Bugs don't magically fix themselves :-(
Don't they? ;-)
I think that the upstream commit log DOES show a 'fix' candidate which seems likely to resolve the problem: 2017-01-18 renderer: export device name from plugin Ray Strode 3 -1/+15 'Right now the renderer keeps its own copy of the device name, which may be NULL or out of date after the renderer is opened. This commit makes sure the device name gets updated to be current.' There's a slightly related fix, but I don't think this one matters in Mageia, because Plymouth is not crashing - it's just fialing to write the pretty picture and 'boot progress' updates. That one is: 2017-01-18 device-manager: handle NULL renderer better Ray Strode 1 -8/+10 'Right now we'll pass a NULL device name and crash if the renderer fails to open. This commit fixes that'. I SWAG that out Plymouth is attempting to write to an out-of-date device name. - - - - My box currently runs openSUSE 'tumbleweed' and has the same problem (3 characters, no pretty graphics, no "boot progress" bar at the bottom.) I haven't built a new Plymouth yet, and the Plymouth they provide has only the 2016-12-15 fixes: not the new ones from 2017-01-08. If I were competent (I'm not), I'd move updates_testing forward to include these fixes, and try the resulting package. But I'm not. Still, I can test anything you've got, in only a few hours. I can copy my 'MGA 5.1 legacy disk' to a scratch disk, and upgrade the scratch to Cauldron as many times as we need.
CC: (none) => rickstockton
(In reply to Rick Stockton from comment #13) > I think that the upstream commit log DOES show a 'fix' candidate which seems > likely to resolve the problem: > > 2017-01-18 renderer: export device name from plugin Ray Strode 3 -1/+15 > 'Right now the renderer keeps its own copy of the device name, which > may be NULL or out of date after the renderer is opened. This commit makes > sure the device name gets updated to be current.' I don't think so. In our case, plymouth is failing to find a valid frame buffer device, so never creates a frame buffer renderer. So the above fix never comes into play. > If I were competent (I'm not), I'd move updates_testing forward to include > these fixes, and try the resulting package. But I'm not. Still, I can test > anything you've got, in only a few hours. I can copy my 'MGA 5.1 legacy > disk' to a scratch disk, and upgrade the scratch to Cauldron as many times > as we need. These fixes are included in the latest plymouth package in cauldron, along with a fix for one of the other causes of plymouth falling back to text mode, as described on the dev and qa-discuss mailing lists. N.B. This bug describes one specific cause of the fallback to text mode that only applies to the Live DVDs (see my original bug description). If the latest version of plymouth doesn't fix the problem for you, please add details of your system to bug 19642.
CC: (none) => egc
CC: egc => (none)
what about this bug ? is it still valid ?
CC: (none) => mageia
I think we can close this one now. The things that made the Live ISOs particularly susceptible to this problem have been fixed. The more general problem is covered by bug 19642. That problem will never entirely go away because it is inherent in the plymouth design.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED