Bug 1624847

Summary: [RHEL 7.6 Bug] Can not install with graphic mode or boot into graphic mode
Product: Red Hat Enterprise Linux 7 Reporter: wangjie <wangjie69>
Component: xorg-x11-drv-vesaAssignee: Adam Jackson <ajax>
Status: CLOSED CURRENTRELEASE QA Contact: Desktop QE <desktop-qa-list>
Severity: urgent Docs Contact: Marie Dolezelova <mdolezel>
Priority: urgent    
Version: 7.6CC: airlied, ajax, alanm, ayadav, btissoir, jniu, jsolomon, peter.hutterer, tpelka, wangjie69
Target Milestone: rcKeywords: OtherQA, ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: xorg-x11-drv-vesa-2.4.0-3.el7 Doc Type: Bug Fix
Doc Text:
.Installation in and booting into graphical mode are now possible on Huawei servers When installing RHEL 7.6 in graphical mode on Huawei servers with AMD64 and Intel 64 processors, the screen became blurred and the install interface was no longer visible. After finishing the installation in console mode, the operating system could not be booted into graphical mode. With this update, the implementation of the X Window System provided by the `xorg-x11-drv-vesa` package has been fixed. As a result, installation in graphical mode and booting into graphical mode on Huawei servers with AMD64 and Intel 64 processors now works as expected.
Story Points: ---
Clone Of:
: 1685873 (view as bug list) Environment:
Last Closed: 2019-07-22 07:24:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1297611, 1685873, 1707454    
Attachments:
Description Flags
dmesg
none
lscpi -nn output
none
Xorg.0.log
none
blurred screen
none
x
none
xorg log of xorg-x11-server-xxx-1.20.1-2
none
install error
none
screenshot
none
output of "ls /sys/devices/platform/"
none
xorg-x11-drv-vesa-2.4.0-3.el7 for test none

Description wangjie 2018-09-03 12:35:47 UTC
Description of problem:
RHEL 7.6 Beta, when I install it in the default graphic mode, the sreen become blurred and I can't see the install interface. So I add inst.text to the kernel command line to complete the install with a text mode.
And also, after installing, the system can not boot into the graphic mode (blurred), I can only boot into multi-user.target to use the system.

Version-Release number of selected component (if applicable):
RHEL 7.6 Beta

How reproducible:
Ad described above.

Steps to Reproduce:
1.
2.
3.

Actual results:
the sreen is blurred.

Expected results:
graphic mode works normally.

Additional info:

Comment 2 Peter Hutterer 2018-09-04 04:37:43 UTC
what graphics device do you have in this machine? The elographics driver is a touch input driver and doesn't affect the output, so we need to find the right component to change this to. Please attach a dmesg output, thanks.

Comment 3 wangjie 2018-09-04 07:12:38 UTC
Created attachment 1480679 [details]
dmesg

Comment 4 wangjie 2018-09-04 07:13:58 UTC
(In reply to Peter Hutterer from comment #2)
> what graphics device do you have in this machine? The elographics driver is
> a touch input driver and doesn't affect the output, so we need to find the
> right component to change this to. Please attach a dmesg output, thanks.

Hi Peter,

  I uploaded the dmesg, please help to find the right component, thanks.

Comment 5 Tomas Pelka 2018-09-04 12:51:38 UTC
elographics is an input device, changing component to xorg-x11-drivers. Lets move to the correct one once we know what video device it is.

lspci -nn output would be handy as well

Comment 6 Dave Airlie 2018-09-05 00:51:20 UTC
It's some of huawei console, which we don't have driver support for yet, but it tries to use efifb.

Comment 7 Dave Airlie 2018-09-05 00:52:09 UTC
Please supply the server details.

Comment 8 Dave Airlie 2018-09-05 00:58:16 UTC
and /var/log/Xorg.0.log

Comment 9 wangjie 2018-09-05 02:07:57 UTC
Created attachment 1480939 [details]
lscpi -nn output

Comment 10 wangjie 2018-09-05 02:08:50 UTC
(In reply to Tomas Pelka from comment #5)
> elographics is an input device, changing component to xorg-x11-drivers. Lets
> move to the correct one once we know what video device it is.
> 
> lspci -nn output would be handy as well

Hi Peter,

   I uploaded the lspci -nn output in Comment 9.

Comment 11 wangjie 2018-09-05 02:11:16 UTC
Created attachment 1480940 [details]
Xorg.0.log

Comment 12 wangjie 2018-09-05 02:12:16 UTC
(In reply to Dave Airlie from comment #7)
> Please supply the server details.

Hi Dave,

   I uploaded the Xorg.0.log. And what server details do you need?

Comment 13 wangjie 2018-09-05 02:13:54 UTC
(In reply to Dave Airlie from comment #6)
> It's some of huawei console, which we don't have driver support for yet, but
> it tries to use efifb.

RHEL 7.5 and all versions earlier is ok.

Comment 15 wangjie 2018-09-06 07:31:02 UTC
Hi,

  Any update? or what I can offer now to help analyse?

Comment 16 Adam Jackson 2018-09-06 16:47:38 UTC
The root cause here is that vesa is trying to run on an UEFI framebuffer. It happens to think it can, because the system apparently still provides a legacy video BIOS ROM that responds to int10 services. I'm pretty sure that's not a legal move as far as UEFI compliance is concerned, but that's the platform's bug, not mine.

Fortunately, we can make the vesa driver smarter. Please install this test build atop 7.6:

https://people.redhat.com/~ajackson/1624847/

Comment 17 wangjie 2018-09-07 06:33:52 UTC
(In reply to Adam Jackson from comment #16)
> The root cause here is that vesa is trying to run on an UEFI framebuffer. It
> happens to think it can, because the system apparently still provides a
> legacy video BIOS ROM that responds to int10 services. I'm pretty sure
> that's not a legal move as far as UEFI compliance is concerned, but that's
> the platform's bug, not mine.
> 
> Fortunately, we can make the vesa driver smarter. Please install this test
> build atop 7.6:
> 
> https://people.redhat.com/~ajackson/1624847/

Hi,

   this build doesn't work.

Comment 18 wangjie 2018-09-07 06:39:29 UTC
(In reply to wangjie from comment #17)
> (In reply to Adam Jackson from comment #16)
> > The root cause here is that vesa is trying to run on an UEFI framebuffer. It
> > happens to think it can, because the system apparently still provides a
> > legacy video BIOS ROM that responds to int10 services. I'm pretty sure
> > that's not a legal move as far as UEFI compliance is concerned, but that's
> > the platform's bug, not mine.
> > 
> > Fortunately, we can make the vesa driver smarter. Please install this test
> > build atop 7.6:
> > 
> > https://people.redhat.com/~ajackson/1624847/
> 
> Hi,
> 
>    this build doesn't work.

I installed the xorg-x11-drv-vesa-2.4.0-1.el7.jx1.x86_64.rpm ,and reboot the system, but screen was still blurred.

Comment 19 Benjamin Tissoires 2018-09-14 08:26:23 UTC
Can you attach a picture of the 'blurred' screen?

Also, would you mind providing again the Xorg log after upgrading to the latest Xorg-server from the latest snapshot (1.20.1)?

Looking at Bug #1620157, it seems VESA is not in the middle anymore, but the modesetting driver now fails at providing a correct scanline.

Comment 20 wangjie 2018-09-15 01:35:01 UTC
Created attachment 1483420 [details]
blurred screen

Comment 21 wangjie 2018-09-15 01:38:29 UTC
Created attachment 1483421 [details]
x

Comment 22 wangjie 2018-09-15 01:39:52 UTC
(In reply to Benjamin Tissoires from comment #19)
> Can you attach a picture of the 'blurred' screen?
> 
> Also, would you mind providing again the Xorg log after upgrading to the
> latest Xorg-server from the latest snapshot (1.20.1)?
> 
> Looking at Bug #1620157, it seems VESA is not in the middle anymore, but the
> modesetting driver now fails at providing a correct scanline.

Hi Benjamin,

  I uploaded the blurred screen picture and  the Xorg log.

Comment 23 Benjamin Tissoires 2018-09-17 08:23:40 UTC
Thanks. This bug looks quite similar than bug #1625229 and bug #1620157.

Can you check if the same workaround than https://bugzilla.redhat.com/show_bug.cgi?id=1620157#c20 works here too?

Comment 24 wangjie 2018-09-19 09:06:43 UTC
(In reply to Benjamin Tissoires from comment #23)
> Thanks. This bug looks quite similar than bug #1625229 and bug #1620157.
> 
> Can you check if the same workaround than
> https://bugzilla.redhat.com/show_bug.cgi?id=1620157#c20 works here too?

It doesn't work in my server.

Comment 25 wangjie 2018-09-20 02:19:44 UTC
Hi,

  Is there anything else I could try?

Comment 28 jingjing niu 2018-09-20 06:33:43 UTC
Hi Wangjie,

There are fixes build in bug #1625229 ?

Can you try if below can work for your server?

http://people.redhat.com/jniu/data/.1624847/

Comment 29 wangjie 2018-09-20 07:31:22 UTC
(In reply to jingjing niu from comment #28)
> Hi Wangjie,
> 
> There are fixes build in bug #1625229 ?
> 
> Can you try if below can work for your server?
> 
> http://people.redhat.com/jniu/data/.1624847/

Thanks,jingjing, but these two packages can't solve my problem as I tested.

Comment 30 Benjamin Tissoires 2018-09-20 07:33:52 UTC
(In reply to wangjie from comment #29)
> 
> Thanks,jingjing, but these two packages can't solve my problem as I tested.

Thanks for testing and sorry for not finding the issue on the first attempt. Can you upload a new xorg.0.log with the xorg-x11-server-Xorg-1.20.1-2 package installed?

Comment 31 wangjie 2018-09-20 07:49:59 UTC
(In reply to Benjamin Tissoires from comment #30)
> (In reply to wangjie from comment #29)
> > 
> > Thanks,jingjing, but these two packages can't solve my problem as I tested.
> 
> Thanks for testing and sorry for not finding the issue on the first attempt.
> Can you upload a new xorg.0.log with the xorg-x11-server-Xorg-1.20.1-2
> package installed?

OK, but I also tried some xorg related operations, I think the xorg.0.log is not so clear now, should I delete it and reboot my system and then upload the xorg.0.log?

Comment 32 Benjamin Tissoires 2018-09-20 09:15:04 UTC
(In reply to wangjie from comment #31)
> (In reply to Benjamin Tissoires from comment #30)
> > (In reply to wangjie from comment #29)
> > > 
> > > Thanks,jingjing, but these two packages can't solve my problem as I tested.
> > 
> > Thanks for testing and sorry for not finding the issue on the first attempt.
> > Can you upload a new xorg.0.log with the xorg-x11-server-Xorg-1.20.1-2
> > package installed?
> 
> OK, but I also tried some xorg related operations, I think the xorg.0.log is
> not so clear now, should I delete it and reboot my system and then upload
> the xorg.0.log?

I guess a clean start would be better, if it is not too much to ask

Comment 33 wangjie 2018-09-20 09:26:31 UTC
Created attachment 1485084 [details]
xorg log of xorg-x11-server-xxx-1.20.1-2

Comment 34 wangjie 2018-09-20 09:27:04 UTC
(In reply to Benjamin Tissoires from comment #32)
> (In reply to wangjie from comment #31)
> > (In reply to Benjamin Tissoires from comment #30)
> > > (In reply to wangjie from comment #29)
> > > > 
> > > > Thanks,jingjing, but these two packages can't solve my problem as I tested.
> > > 
> > > Thanks for testing and sorry for not finding the issue on the first attempt.
> > > Can you upload a new xorg.0.log with the xorg-x11-server-Xorg-1.20.1-2
> > > package installed?
> > 
> > OK, but I also tried some xorg related operations, I think the xorg.0.log is
> > not so clear now, should I delete it and reboot my system and then upload
> > the xorg.0.log?
> 
> I guess a clean start would be better, if it is not too much to ask

Hi, I upload the clean log.

Comment 35 wangjie 2018-09-20 09:29:25 UTC
(In reply to wangjie from comment #29)
> (In reply to jingjing niu from comment #28)
> > Hi Wangjie,
> > 
> > There are fixes build in bug #1625229 ?
> > 
> > Can you try if below can work for your server?
> > 
> > http://people.redhat.com/jniu/data/.1624847/
> 
> Thanks,jingjing, but these two packages can't solve my problem as I tested.

Sorry I didn't describe it clear:
I successfully upgraded these two packages, but the blurred screen problem still existed.

Comment 36 wangjie 2018-09-20 11:55:47 UTC
Hi,

  I tried 7.6 snapshot 4:
  (1) when I install in a normal way (without inst.text kernel cmdline), still got a blurred install interface, so I still can't perform a graphic installation.
  (2) I add inst.text kernel cmdline when installing, but after I completed all the installing configuration and enter "b" to begin installation, the progress started and finally failed at this error:

Starting package installation process
   Error populating transaction, anaconda is retrying (1/10)
   Error populating transaction, anaconda is retrying (2/10)
   ....
   Error populating transaction, anaconda is retrying (10/10)

   I tried 2 times, both failed.

Comment 37 wangjie 2018-09-20 11:58:08 UTC
Created attachment 1485111 [details]
install error

Comment 39 Benjamin Tissoires 2018-09-20 15:44:19 UTC
The anaconda install errors seems entirely unrelated.
However, I can confirm that words-3.0-22.el7 is in snapshot 5, so snapshot 5 should fix this issue (hopefully). If not, please open a separate bug.

Comment 40 wangjie 2018-09-21 04:21:23 UTC
Sorry, my bad, maybe something was wrong during my iso downloading, I download the iso again and now I can install snapshot 4 successfully( in a text mode).

Now I will try if the packages in Comment 28 can work in snapshot 4.

Comment 41 Tomas Pelka 2018-09-21 06:38:15 UTC
Seems c40 just confirmed this is a dup of bug #1625229.

Comment 42 wangjie 2018-09-21 06:41:59 UTC
(In reply to wangjie from comment #40)
> Sorry, my bad, maybe something was wrong during my iso downloading, I
> download the iso again and now I can install snapshot 4 successfully( in a
> text mode).
> 
> Now I will try if the packages in Comment 28 can work in snapshot 4.

Still not solved, updating xorg-x11-server didn't work.

Comment 43 wangjie 2018-09-21 06:44:00 UTC
(In reply to Tomas Pelka from comment #41)
> Seems c40 just confirmed this is a dup of bug #1625229.

Hi Tomas, the solution in bug #1625229 doesn't work here.

Comment 44 wangjie 2018-09-26 07:35:47 UTC
Hi,

  What's more we can do now to help analyse this issue? This bug is quite serious because it makes RHEL 7.6 unusable in Kunlun server.

Comment 45 Adam Jackson 2018-09-26 17:28:21 UTC
Please try removing the xorg-x11-drv-vesa package (and xorg-x11-drivers, if necessary) and restarting X. We shouldn't be running vesa at all on EFI machines, I don't think.

Comment 46 wangjie 2018-09-27 01:20:25 UTC
(In reply to Adam Jackson from comment #45)
> Please try removing the xorg-x11-drv-vesa package (and xorg-x11-drivers, if
> necessary) and restarting X. We shouldn't be running vesa at all on EFI
> machines, I don't think.

Good news, this solution works, I removed these two packages, and restarted X, my screen is fine now.

Comment 47 wangjie 2018-09-27 01:48:02 UTC
Can you put this into next snapshot?

Comment 48 jingjing niu 2018-09-27 02:34:30 UTC
Hi Wangjie,

We just released snapshot 5 today. Please test this bz.

Comment 49 wangjie 2018-09-29 01:59:04 UTC
I tested snapshot 5, also I should install the system in a text mode.
Can I put some kernel command line parameters to disable the vesa driver before installing ? so that I can install in a graphic mode.

Comment 50 wangjie 2018-09-29 04:05:39 UTC
And in snapshot 5, the solution of removing vesa also works.

Now can anyone help to tell whether a kernel command line can disable vesa driver, so that it's can be acceptable workaround?

Comment 51 jingjing niu 2018-09-29 05:39:07 UTC
Hi Adam,

Please check comment 50

Comment 52 Adam Jackson 2018-10-03 14:36:33 UTC
(In reply to wangjie from comment #50)
> And in snapshot 5, the solution of removing vesa also works.
> 
> Now can anyone help to tell whether a kernel command line can disable vesa
> driver, so that it's can be acceptable workaround?

If you pass 'inst.xdriver=fbdev' on the kernel command line when installing, anaconda should write out an xorg.conf file forcing the use of the fbdev driver.

Comment 53 wangjie 2018-10-09 03:30:36 UTC
(In reply to Adam Jackson from comment #52)
> (In reply to wangjie from comment #50)
> > And in snapshot 5, the solution of removing vesa also works.
> > 
> > Now can anyone help to tell whether a kernel command line can disable vesa
> > driver, so that it's can be acceptable workaround?
> 
> If you pass 'inst.xdriver=fbdev' on the kernel command line when installing,
> anaconda should write out an xorg.conf file forcing the use of the fbdev
> driver.

Thanks, it works.

Comment 54 wangjie 2018-10-09 09:23:07 UTC
Now, my workaround is:

1. Add kernel command line parameter "inst.xdriver=fbdev" when install OS (and install the OS as "server with GUI").
2. After the installing completes, reboot and add kernel command line "single" to ask system to boot into maintenance mode.
3. "rpm -e  xorg-x11-drivers" and then "rpm -e xorg-x11-drv-vesa".
4. init 5.

Comment 67 jingjing niu 2019-05-08 02:50:34 UTC
Hi Wangjie,

Since we don't have Huawei server in Red Hat lab, we set it as OtherQA and need Huawei to test it.

Thanks.

Comment 69 wangjie 2019-05-08 08:08:03 UTC
(In reply to jingjing niu from comment #67)
> Hi Wangjie,
> 
> Since we don't have Huawei server in Red Hat lab, we set it as OtherQA and
> need Huawei to test it.
> 
> Thanks.

Hi Jingjing,

   You mean that huawei can test this issue with rhel 7.7 Alpha now, right?

Comment 70 jingjing niu 2019-05-09 03:09:10 UTC
Yes, please

Comment 71 wangjie 2019-05-09 08:24:52 UTC
I'm sorry to tell that, rhel 7.7 Alpha still has the same problem: I got a blurred screen as I described in Description of the bz.

Comment 72 wangjie 2019-05-09 10:45:06 UTC
Created attachment 1566079 [details]
screenshot

Comment 73 wangjie 2019-05-09 10:46:34 UTC
I uploaded the screenshot. If any specific log is needed ,please let me know.

Comment 74 Benjamin Tissoires 2019-05-09 14:28:29 UTC
Thanks a lot for the test.
The patch we thought that fixes your issue is actually in 7.6 alpha, so there is something wrong here.

Would it be possible to have the output of "ls /sys/devices/platform/"?

Our patch looks for a specific path here and if your system doesn't have it, it would explain why the patch isn't working.

Comment 75 wangjie 2019-05-10 03:05:00 UTC
Created attachment 1566501 [details]
output of "ls /sys/devices/platform/"

Comment 76 wangjie 2019-05-10 03:06:40 UTC
(In reply to Benjamin Tissoires from comment #74)
> Thanks a lot for the test.
> The patch we thought that fixes your issue is actually in 7.6 alpha, so
> there is something wrong here.
> 
> Would it be possible to have the output of "ls /sys/devices/platform/"?
> 
> Our patch looks for a specific path here and if your system doesn't have it,
> it would explain why the patch isn't working.

Hi Benjamin,

   I uploaded the output of "ls /sys/devices/platform/",please check.
   By the way, you mean the patch is actually in 7.6 alpha? or 7.7 alpha?

Comment 77 Benjamin Tissoires 2019-05-10 06:33:23 UTC
> I uploaded the output of "ls /sys/devices/platform/",please check.

Thanks a lot. Our patch was looking for /sys/devices/platform/efi-framebuffer.0 while on your platform the framebuffer device is actually /sys/devices/platform/efifb.0

It should be easy to fix.

> By the way, you mean the patch is actually in 7.6 alpha? or 7.7 alpha?

Sorry, I was meaning 7.7 alpha, yes

Comment 83 jingjing niu 2019-05-13 08:14:14 UTC
Created attachment 1567814 [details]
xorg-x11-drv-vesa-2.4.0-3.el7 for test

We need Huawei to test xorg-x11-drv-vesa-2.4.0-3.el7 as per comment 80

Comment 84 jingjing niu 2019-05-13 08:16:04 UTC
Hi Wangjie,

Please try below steps to test our latest fix.
- install the current alpha/beta in text mode
- upgrade xorg-x11-drv-vesa-2.4.0-3.el7 in https://bugzilla.redhat.com/attachment.cgi?id=1567814
- init 5

Comment 86 wangjie 2019-05-14 03:21:43 UTC
(In reply to jingjing niu from comment #84)
> Hi Wangjie,
> 
> Please try below steps to test our latest fix.
> - install the current alpha/beta in text mode
> - upgrade xorg-x11-drv-vesa-2.4.0-3.el7 in
> https://bugzilla.redhat.com/attachment.cgi?id=1567814
> - init 5

Hi, it works.