related to
child of
duplicate of
 |
The working build OS is SMP Debian 5.15.15-2kali1 (2022-01-31) |
|
|
The working OS build details: VERSION=2022.1, kali-rolling |
|
|
The not working build OS is SMP PREEMPT_DYNAMIC Debian 6.0.12-1kali1 (2022-12-19) |
|
|
Same situation on Intel i7-6820 HQ processor, Hyper-V based on Windows 10 Pro 22H2, OS build 19045.2364. |
 |
In a previous report about this I gave an xorg snippet to use fbdev for the display driver - https://bugs.kali.org/view.php?id=7892 can you see if that works for you as well? I don't have a system where I have hyper-v to test what exactly is breaking, but could you please post your xorg log files both before and after adding the snippets? I do believe this is the same as 7892, but unfortunately, this seems like it's possibly a kernel bug or perhaps an xorg packaging change in that previously it may have been falling back on the fbdev driver and now does not. |
|
|
Could you tell me, are your HyperV VMs gen1 or gen2? |
|
|
Sure. It's Gen1 Hyper-V machine. |
|
|
@steev , could you tell me where I can find Xorg logs on KALI Linux? |
|
|
the default should be /var/log/Xorg.0.log or possibly it's in /var/log/lightdm/x-0-log.log or some such if it's failing via lightdm. |
|
|
This is pretty much a "we know what the issue is, but there isn't a simple fix" kind of fix. The kernel has 2 different drivers for hyperv - there's the framebuffer driver that gen1 hyperv VMs use, and then there's a DRM driver that gen2 hyperv VMs use. Unfortunately, if the driver for the framebuffer driver is enabled, then the kernel will always load it first, and skip using the DRM driver, even on gen2 VMs. We will be discussing this in our next meeting, but the holidays need to conclude first. |
 |
Yet another wrongly cloned issue... Dup of 0008112 |
