View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008112||Kali Linux||[All Projects] General Bug||public||2022-12-22 13:45||2023-01-04 08:22|
|Target Version||Fixed in Version|
|Summary||0008112: Kali Linux 2022.4 - kernel 6.0.0 - stopped the OS from start in GUI on Hyper-V VM|
I've upgraded my Kali Linux 2022.1/kernel 5.15.0-kali3-amd64 VM (based on Hyper-V) to the 2022.4 (kernel 6.0.0) and it stopped to start.
The VM doesn't start to the GUI Gnome anymore (black screen and blinking cursor).
I've tried to perform a brand new installation based on the 2022.4 installer multiple times and the issue is always the same.
I can switch to the text consoles - e.g. Alt-F2 - and login there to the text consoles but the GUI Gnome is not working at all.
I think the problem is related to the 6.0.0 kernel as when I went to the advanced start options on the 2022.1 upgraded machine and selected kernel 5.15.0-kali3-amd64 manually which was there still available the GUI Gnome started without any issues.
|Steps To Reproduce||Install Kali Linux 2022.4 with the Gnome GUI only (uncheck Xfce and KDE) with kernel 6.0.0. on fully updated Windows 10 with Hyper-V.|
My test physical machine was: AMD FX-8320 8 cores, Win 10 Pro 21H2 OS build 19044.2364.
Issue observed always with this build and kernel.
|Additional Information||Kali Linux 2022.1 with kernel 5.15.0-kali3-amd64 works well without start issues.|
||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)
The not working OS build details: VERSION=2022.4, kali-rolling
Same situation on Intel i7-6820 HQ processor, Hyper-V based on Windows 10 Pro 22H2, OS build 19045.2364.
So it is both AMD and Intel CPU related issue.
||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?
As I checked the standardized locations like /var/log (*.log files) or /var/log/xorg - doesn't exist.
||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.
|2022-12-22 13:45||SkullZ_||New Issue|
|2022-12-22 13:55||SkullZ_||Note Added: 0017272|
|2022-12-22 13:57||SkullZ_||Note Added: 0017273|
|2022-12-22 14:47||SkullZ_||Note Added: 0017274|
|2022-12-22 14:50||SkullZ_||Note Added: 0017275|
|2022-12-23 06:45||steev||Note Added: 0017277|
|2022-12-24 06:03||steev||Note Added: 0017282|
|2022-12-28 18:45||SkullZ_||Note Added: 0017287|
|2022-12-29 16:08||SkullZ_||Note Added: 0017288|
|2022-12-30 03:49||steev||Note Added: 0017291|
|2022-12-30 03:51||steev||Note Added: 0017292|
|2022-12-31 16:20||NO_NAME_BLANK_098||Issue cloned: 0008129|
|2023-01-04 08:22||daniruiz||Relationship added||has duplicate 0008129|