Bug 1431141

Summary: plymouth doesn't fall back to text mode if DRM/FB devices exist but don't work as expected
Product: Red Hat Enterprise Linux 7 Reporter: Deepu K S <dkochuka>
Component: plymouthAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: cww, d.bell, dkochuka, mclasen, tpelka
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: plymouth-0.8.9-0.29.20140113.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 18:38:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1420851, 1479818    

Description Deepu K S 2017-03-10 13:07:14 UTC
Description of problem:
plymouth doesn't fall back to text mode if DRM/FB devices exist but don't work as expected (e.g. nvidia binary driver).

There is a defect in Plymouth's logic. It uses udev of course to look for devices, and if it finds a DRM device or a FB device it uses them, and if not, it falls back to text mode. It does not cope with a scenario where a DRM or FB device exists but doesn't work, in that scenario it does not fall back to text mode. It /should/.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux 7.3
plymouth-0.8.9-0.26.20140113.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
It happens when you use the NVIDIA binary/third party drivers. The nvidia driver provides a DRM device (although it doesn't provide an fbdev device) and plymouth sees that and tries to use it, of course, it doesn't work because the nvidia driver doesn't support proper kernel mode setting or fbdev. So plymouth simply fails, and the user doesn't see anything during boot up until X starts. 

Actual results:
Plymouth does not cope with a scenario where a DRM or FB device exists but doesn't work, in that scenario it does not fall back to text mode.

This is a huge problem on RHEL7 if you use the PackageKit/systemd offline updates because the system starts, it begins an automatic update, and plymouth has failed so you see nothing at all, not even a text output! There is no visual indication that the system is working at all even though underneath its doing a yum update! This has led to our users rebooting systems which are mid-update, and then breaking horribly.

Expected results:
This bug thus requests that a patch be written and applied to Plymouth to cope with this scenario.
It should fall back to text mode in scenario of where DRM/FB devices exist but don't work as expected. eg (NVIDIA or any third party display driver)

Additional info:
Most people, in fact nearly all info on the internet, suggest setting the vga=<mode> flag on the kernel command line to set up a vesafb framebuffer which plymouth will then use, but this is a bad idea for many reasons (NVIDIA don't support it, the mode depends on what the card and/or monitor support, etc.). We can't do this, and don't want to.

Comment 2 Deepu K S 2017-03-10 13:15:12 UTC
There is a workaround shared by David from checking plymouth source code.

If you set the kernel command line flag "plymouth.ignore-udev" then plymouth doesn't ask udev for DRM or FB devices at all and defaults to text mode. This fixes plymouth on nvidia - and any system/driver where the DRM driver doesn't support KMS.

Comment 12 errata-xmlrpc 2018-04-10 18:38:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0999