xcp
xcp copied to clipboard
xcp-ng
Unable to install XCP-ng on some hardware with i915 compatible graphics card
i915 compatible graphics card has become common in many cases (Intel NUCs) and users are unable to do installation with default kernel or kernel-alt. Current iso build process strips i915 from both kernels which could be causing a black screen after Xen relinquishes VGA. This needs more testing from users who have only i915 compatible VGA.
Users can boot an already installed system as it has i915 module present.
It is not certain that having i915 module in the ISO will solve this issue.
It now has been tested that having the i915 module solves the issue. However we still don't know why on those specific computers the installer's kernel is not able to display text without the GPU driver. Adding that driver would be a workaround (and we can help users do it manually during installation), but not the complete solution.
In addition to that, the i915 module is blacklisted in dom0. We don't know the reason why yet.
Hello, I'm having this problem with comet lake and rocket lake processors. How can I manually solve it? Thanks
There are test installation images at https://xcp-ng.org/forum/topic/5492/xcp-ng-8-2-1-maintenance-update-ready-for-testing that are supposed to bring Rocket Lake support, but I don't think it's related to i915.
Same problem with 8.2.1. Black screen after relinquish VGA. I'm able to install only with PCIe GPU. Once installed and removed GPU tested lots of workarounds for CentOS 7 in grubs command line and i915.conf without success. Same result with comet lake (i5-10400) and rocket lake (i5-11400).
So even by un-blacklisting i915 in /etc/modprobe.d/i915.conf on the installed system you still don't have any display after reboot? This would differ from what other users experienced in a similar situation.
We still don't know why such hardware is not able to display a simple console without using the i915 module though.
Yes, un-blacklisting has no effect. Maybe the problem is with Intel B560 chipset?. Which CentOS release it's based on? I'm gonna try with CentOS to see if has the same problem.
Thanks
The CentOS release (7) wouldn't tell you much as we have a custom 4.19 kernel and there's also the Xen layer that might play a role.
I can confirm @vicsanca report that the black screen when relinquish VGA.
One thing of note is that the 8.2.1 release did render the GRUB install menu on my Intel 11th Gen NUC (NUC11PAHi7) which could open a path for hacking an i915 fix on those NUCs (with less hassle).
OK. I have done more tests with comet lake.
Updated 8.2 to 8.2.1 with yum, same problem, but now lspci shows a name for VGA (00:02.0 VGA compatible controller: Intel Corporation CometLake-S GT2 [UHD Graphics 630] (rev 03)), 8.2 only shows hardware identifier 9bc8
Un-Blacklisting i915 in /etc/modprobe.d/i915.conf has no effect, lsmod shows that i915 module is NOT loaded.
Tested "options i915 force_probe=9bc8" in i915.conf...same result. It's not loading i915.
I've read that the Intel Iris Xe Graphics require kernel version 5.4 or higher and I am seeing that reported for my specific device an 11th Gen Intel NUC i7 here: http://linux-hardware.org/?id=pci:8086-9a49-8086-3004
Could be a problem related to UEFI/CSM?
https://scottiestech.info/2021/04/13/why-cant-i-enable-csm-on-my-new-motherboard/
Adding that driver would be a workaround (and we can help users do it manually during installation)
@stormi , how can this be done manually during installation?
Adding that driver would be a workaround (and we can help users do it manually during installation)
@stormi , how can this be done manually during installation?
You attach a device with the driver on it, switch to a shell with ALT+RIGHT and insmod the driver.
There’s a new NUC Test 2 ISO that works on my NUC 11 w/ i915. You can find out more about it on this XCP-NG community forum thread
I came here because I've been trying to install XCP-ng on a Jasper Lake N5105 system which also uses i915 graphics and further has 4x i225 network cards and between the two it feels like I'm living on the bleeding edge. The "NUC Test 2" ISO linked above got me through to installation where the vanilla 8.2.1 installer failed. Is there an ETA for inclusion of the i915 driver in the official ISOs?
Our objective is to product nightly ISO with latest updates (and maybe even test drivers), especially for people with non-server hardware.
Note: this is not about including the i915 drivers as they are not required to get a display. The fixes are related to console display in the linux kernel.
@stormi You're right, I should have used more precise language; my question was if there was a timeline to incorporate these improvements to the installer or iso build process such that the installation can complete as normal on Intel NUC and other devices using i915 graphics.
@olivierlambert That's great! I take it this isn't the case yet, or have I missed them?
I am also running into this issue with a Jasper Lake N6005 CPU very similar to @danieltwagner's. Once the 1165g7 version shows up, I will let you know if it's also affected. Likely will be, based on this and the forum threads. Unfortunately there is no legacy mode in the new intel chipsets. (EDIT: Confirmed, also broken with regular and fixed by custom iso from forums.)
They are becoming popular partially because more affordable models from AliExpress (and occasionally Amazon) are showing up now and have been reviewed on YouTube by a few channels, generating at least a little interest. (Between ServeTheHome && Level1Techs combined, I'm sure there's more than one following a similar path.)
XCP-Ng devs, many sysAdmins use desktops to test newer versions of hypervisors before rolling out. I would think this would effect many users. Isn’t there an ALT XCP-Ng version the below solution might belong in?
David,
I happened to notice this kernel mailing list post having to do with Intel Integrated Graphics and a particular patch. I would Google for part of what I quote below to get the full thread. A later posting encourages users to contact Linus himself.
Reverting the kernel patch bdd8b6c98239 fixes the problem.
BELOW IS COPIED FROM A LINUX KERNEL MAILING LIST
Update: On affected hardware, you do not need to run in a Xen PV Dom0 to see the regression caused by bdd8b6c98239.
All you need to do is run, on the bare metal, on the affected hardware, with the Linux kernel nopat boot option.
Jan mentions in his commit message the function in the i915 driver that was touched by bdd8b6c98239 and that causes this regression. That is, any Intel IGD that needs to execute the function that Jan mentions in the commit message of his proposed patch when the i915 driver is setting up the graphics engine will most likely be hardware that is affected. My Intel IGD was marketed as HD Graphics 4600, I think.
So find an a system with these hardware characteristics, and try running, with the nopat option, the Linux kernel, with and without bdd8b6c98239. You will see the regression I am experiencing, I predict.
On Mon, Sep 5, 2022 at 9:18 AM David Pesce @.***> wrote:
Any updates on this? Has it been integrated into nightly build?
— Reply to this email directly, view it on GitHub https://github.com/xcp-ng/xcp/issues/436#issuecomment-1237108757, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACX7F5JPSW4XYQQU5C2WF3V4X6MJANCNFSM4RMU72BQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hey, is the changes from the NUC test2 iso going to be merged in any time soon?
So, regarding the graphics themselves, the next ISOs we build will have the fix:
- upcoming 8.3 Beta (probably end of 2022)
- refreshed 8.2 ISOs
Regarding refreshed 8.2 ISOs, the display issue is not the only issue that needs fixing before we release any: we also need backported network drivers. This is where we're not advancing right now. The initial plan, devised back in May IIRC, was that @andrew64k would contribute pull requests to the XCP-ng project so that we can include these drivers. I also offered help to accompany the process. But I think both sides have been busy and nothing was done.
Another solution is I can do the packaging work myself. I just need some input from Andrew, as we already discussed it on the forum, in the dedicated forum thread: the upstream code that was extracted from the linux kernel + patches that were necessary to make them work on our older 4.19 kernel, and explanations of the rationale behind the changes because we need traceability.
The last resort would be doing it all by myself without @andrew64k, but this doesn't look like a good solution in my eyes, and is likely to happen later than the other solutions.
I actually have paid contracting work this summer so I have been busy.
The network coding/testing is not a problem. I have real hardware for testing so I can debug issues. It's git where I'm not an expert and it should be quick and easy, but it's not (at least to do it correctly).
I have updated the 8125 driver and it seems to work ok (where it works) and better than the current XCP included version. The i225 has been so solid I bought myself a new mini machine as a home XCP server that uses the i225 interface (and dual M.2, it's crazy fast and small)!
I'll put in an effort to get a PR for the network drivers so they can be added to testing and 8.3. The three issues (EFI, i225, 8125) are very common now for most new machines.
GRUB should also be updated (2.03) or patched to better support 64bit EFI FB but an update not directly "required" for XCP as Xen sends the right 64bit FB data to Dom0 (as tested).
I know the 8125 and driver is having big problems in the FreeBSD world. TrueNAS pulled out the 8125 driver because of iSCSI data corruption.
-- Andrew Lindh @.***
Quoting Samuel Verschelde @.***>:
So, regarding the graphics themselves, the next ISOs we build will
have the fix:
- upcoming 8.3 Beta (probably end of 2022)
- refreshed 8.2 ISOs
Regarding refreshed 8.2 ISOs, the display issue is not the only
issue that needs fixing: we also need backported network drivers.
This is where we're not advancing right now. The initial plan,
devised back in May IIRC, was that @andrew64k would contribute pull
requests to the XCP-ng project so that we can include these drivers.
I also offered help to accompany the process. But I think both sides
have been busy and nothing was done.Another solution is I can do the packaging work myself. I just need
some input from Andrew, as we already discussed it on the forum, in
the dedicated forum thread: the upstream code that was extracted
from the linux kernel + patches that were necessary to make them
work on our older 4.19 kernel, and explanations of the rationale
behind the changes because we need traceability.The last resort would be doing it all by myself without @andrew64k,
but this doesn't look like a good solution in my eyes, and is likely
to happen later than the other solutions.-- Reply to this email directly or view it on GitHub: https://github.com/xcp-ng/xcp/issues/436#issuecomment-1254716864 You are receiving this because you were mentioned.
Message ID: @.***>
PR submitted for new IGC and r8125 drivers.
It should be plug and play for the XCP 8.2 build (and 8.3, I think).
-- Andrew Lindh @.*** NETPLEX 860-233-1111
Quoting Samuel Verschelde @.***>:
So, regarding the graphics themselves, the next ISOs we build will
have the fix:
- upcoming 8.3 Beta (probably end of 2022)
- refreshed 8.2 ISOs
Regarding refreshed 8.2 ISOs, the display issue is not the only
issue that needs fixing: we also need backported network drivers.
This is where we're not advancing right now. The initial plan,
devised back in May IIRC, was that @andrew64k would contribute pull
requests to the XCP-ng project so that we can include these drivers.
I also offered help to accompany the process. But I think both sides
have been busy and nothing was done.Another solution is I can do the packaging work myself. I just need
some input from Andrew, as we already discussed it on the forum, in
the dedicated forum thread: the upstream code that was extracted
from the linux kernel + patches that were necessary to make them
work on our older 4.19 kernel, and explanations of the rationale
behind the changes because we need traceability.The last resort would be doing it all by myself without @andrew64k,
but this doesn't look like a good solution in my eyes, and is likely
to happen later than the other solutions.-- Reply to this email directly or view it on GitHub: https://github.com/xcp-ng/xcp/issues/436#issuecomment-1254716864 You are receiving this because you were mentioned.
Message ID: @.***>
So, regarding the graphics themselves, the next ISOs we build will have the fix:
- upcoming 8.3 Beta (probably end of 2022)
- refreshed 8.2 ISOs
I have been trying this with the Alpha. It installs and boots cleanly (unlike the previous version which had the relinquish issue). I am still having issues in one of my VMs. I think it is when the Guest OS (Windows 10) probes graphics.
I raised this for 8.2.1 on my N5105. It works fine bare metal. More recently I tried a 12th Gen i7-1260P with the same issue. I will go back and test my N5105 but I strongly suspect I will see the same issue.
https://github.com/xcp-ng/xcp/issues/565
8.2.1 gave me black screen after the "relinquishing vga console" message. 8.3a2 booted the installation with no problem. I'm on a ODROID-H3+.
Yes, it's somehow expected :) Thanks for your feedback confirming it's the case :+1:
I just purchased a bunch of N5105 based units intending to install xcp-ng on them for light duty stuff. I SHOULD have bought one and tested first, but I didn't. Now I can't install XCP-ng on any of them, and this is the issue that I'm bumping into.
Is there a solution for this yet? Or are the various hacks in this thread still the only workaround?
