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-vesa | Assignee: | Adam Jackson <ajax> | ||||||||||||||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||||||||||||||||
Severity: | urgent | Docs Contact: | Marie Hornickova <mdolezel> | ||||||||||||||||||||||
Priority: | urgent | ||||||||||||||||||||||||
Version: | 7.6 | CC: | airlied, ajax, alanm, ayadav, btissoir, jniu, jsolomon, peter.hutterer, tpelka, wangjie69 | ||||||||||||||||||||||
Target Milestone: | rc | Keywords: | 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: | --- | Target Upstream Version: | |||||||||||||||||||||||
Embargoed: | |||||||||||||||||||||||||
Bug Depends On: | |||||||||||||||||||||||||
Bug Blocks: | 1297611, 1685873, 1707454 | ||||||||||||||||||||||||
Attachments: |
|
Description
wangjie
2018-09-03 12:35:47 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. 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. 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. (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? Yes, please 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. Created attachment 1566079 [details]
screenshot
I uploaded the screenshot. If any specific log is needed ,please let me know. 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. Created attachment 1566501 [details]
output of "ls /sys/devices/platform/"
(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? > 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 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 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 (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. |