Red Hat Bugzilla – Bug 1624847
[RHEL 7.6 Bug] Can not install with graphic mode or boot into graphic mode
Last modified: 2018-10-26 10:35:16 EDT
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:
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.
Created attachment 1480679 [details] dmesg
(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.
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
It's some of huawei console, which we don't have driver support for yet, but it tries to use efifb.
Please supply the server details.
and /var/log/Xorg.0.log
Created attachment 1480939 [details] lscpi -nn output
(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.
Created attachment 1480940 [details] Xorg.0.log
(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?
(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.
Hi, Any update? or what I can offer now to help analyse?
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/
(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.
(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.
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.
Created attachment 1483420 [details] blurred screen
Created attachment 1483421 [details] x
(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.
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?
(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.
Hi， Is there anything else I could try?
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/
(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.
(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?
(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?
(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
Created attachment 1485084 [details] xorg log of xorg-x11-server-xxx-1.20.1-2
(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.
(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.
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.
Created attachment 1485111 [details] install error
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.
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.
Seems c40 just confirmed this is a dup of bug #1625229.
(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.
(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.
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.
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.
(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.
Can you put this into next snapshot?
Hi Wangjie, We just released snapshot 5 today. Please test this bz.
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.
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?
Hi Adam, Please check comment 50
(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.
(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.
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.