Bug 1624847 - [RHEL 7.6 Bug] Can not install with graphic mode or boot into graphic mode
Summary: [RHEL 7.6 Bug] Can not install with graphic mode or boot into graphic mode
Status: ON_QA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xorg-x11-server   
(Show other bugs)
Version: 7.6
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Adam Jackson
QA Contact: Desktop QE
Marie Dolezelova
URL:
Whiteboard:
Keywords: ZStream
Depends On:
Blocks: 1297611 1685873
TreeView+ depends on / blocked
 
Reported: 2018-09-03 12:35 UTC by wangjie
Modified: 2019-04-18 15:37 UTC (History)
10 users (show)

Fixed In Version: xorg-x11-drv-vesa-2.4.0-2.el7
Doc Type: Known Issue
Doc Text:
Installation in and booting into graphical mode are not possible on Huawei servers When installing RHEL 7.6 in graphical mode on Huawei servers with AMD64 and Intel 64 processors, the screen becomes blurred and the install interface is no longer visible. After finishing the installation in console mode, the operating system cannot be booted into graphical mode. To work around this problem: 1. Add kernel command line parameter "inst.xdriver=fbdev" when installing the system, and install the system as "server with GUI". 2. After the installation completes, reboot and add kernel command line "single" to make the system boot into maintenance mode. 3. Run the following commands: rpm -e xorg-x11-drivers rpm -e xorg-x11-drv-vesa init 5
Story Points: ---
Clone Of:
: 1685873 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg (359.06 KB, text/plain)
2018-09-04 07:12 UTC, wangjie
no flags Details
lscpi -nn output (115.43 KB, text/plain)
2018-09-05 02:07 UTC, wangjie
no flags Details
Xorg.0.log (40.73 KB, text/plain)
2018-09-05 02:11 UTC, wangjie
no flags Details
blurred screen (106.33 KB, image/png)
2018-09-15 01:35 UTC, wangjie
no flags Details
x (39.40 KB, text/plain)
2018-09-15 01:38 UTC, wangjie
no flags Details
xorg log of xorg-x11-server-xxx-1.20.1-2 (38.93 KB, text/plain)
2018-09-20 09:26 UTC, wangjie
no flags Details
install error (106.04 KB, image/png)
2018-09-20 11:58 UTC, wangjie
no flags Details

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 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 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 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 UTC
Created attachment 1483420 [details]
blurred screen

Comment 21 wangjie 2018-09-15 01:38 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 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 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.


Note You need to log in before you can comment on or make changes to this bug.