On 24.08.2024 13:40, Robert McBroom via users wrote:

On 8/23/24 1:52 PM, Walter H. via users wrote:

...

These three kernels

kernel-6.10.4-200.fc40.x86_64 kernel-6.10.5-200.fc40.x86_64 kernel-6.10.6-200.fc40.x86_64

won't start my VM properly, ends in a black screen, where I can see mouse moventments, and that was it ... no login, nothing;

kernel-6.10.3-200.fc40.x86_64 works fine

using LXDM

Thanks

Walter

Similar system, doesn't initialize.  Have had to use

systemctl start libvirtd

from a command window. Works then.

libvirt isn't installed;

it is a VMware Guest

what happened, since these 3 kernels; after dnf update I just removed the last installed kernel in order to get kernel-6.10.3-200.fc40.x86_64 as the latest kernel and the system works;

is there a solution, to use the latest kernel?

Thanks,

Walter

On 24 Aug 2024, at 14:47, Walter H. via users users@lists.fedoraproject.org wrote:

it is a VMware Guest

I have not used vmware for a long time, but when I did it was sometimes necessary to wait for vmware to fix something before a new kernel would work.

Suspect you need to install a 6.9 kernel and test that.

Barry

On 25 Aug 2024, at 08:50, Walter H. via users users@lists.fedoraproject.org wrote:

...

I have not used vmware for a long time, but when I did it was sometimes necessary to wait for vmware to fix something before a new kernel would work.

I have nothing installed from vmware, the vmware tools

It’s the vmware hypervisor that may need a fix for the host to work. Not the vmware tools for the guest.

Barry

On 25 Aug 2024, at 11:43, Walter H. via users users@lists.fedoraproject.org wrote:

or the kernels later than 6.10.3 are buggy and this need to be fixed(!)

I tried the VM with latest VMware Wkstn. - same problem

As I said VMware has a history of breaking on new kernels. Their hypervisor appears to "know" about the linux kernel and some time what it knows needs updating I do not recall the linux kernel being fixed with VMware boot breaks.

Barry

Hi,

I'm also running VMWare Workstation, and am experiencing the exact same issue. On Fedora 40, using the kernels 6.10.4, 6.10.5, and 6.10.6 result in an unbootable vm, and the last Fedora 40 kernel that worked was 6.10.3.

Just to do some verification, I tried running an Arch Linux guest with kernel 6.10.6 using the same VMWare Workstation install, and that boots perfectly fine.

So whatever this turns out to be, it's not just a simple 'VMWare needs to be updated for the latest kernel' issue: latest Arch seems to be doing something different here than Fedora 40, resulting in the fact that the same kernel will boot in Arch and not in Fedora (and this needs to be investigated). Either that or, I have made different configuration choices when creating these VM's (I cannot recall what choices I made during VM configuration for Arch).

PS: For now, as a temporary workaround, you 'could' choose to add the following line to /etc/dnf/dnf.conf : exclude=kernel kernel-core kernel-devel kernel-modules kernel-modules-core kernel-modules-extra which will prevent dnf from updating the kernel when you do a 'sudo dnf update'.

So there's a common problem here with VMWare Workstation and f40?

What version of workstation are you both running? What are you running on, Windows 10, 11, something else?

When your VMs boot with the new kernels, but blank screens, are the IPs connected to the appropriate virtual network? Can you ping and/or SSH into the VMs?

Have you tried booting into text-only mode in case the issue is specifically display manager related?

https://www.reddit.com/r/Fedora/comments/1d18b6d/anyone_having_trouble_with_... looks promising?

Specifically: https://www.reddit.com/r/Fedora/comments/1d18b6d/comment/l78k8ag/?utm_source...

On Mon, 26 Aug 2024 at 22:10, Maarten Hoes hoes.maarten@gmail.com wrote:

Hi,

I'm also running VMWare Workstation, and am experiencing the exact same issue. On Fedora 40, using the kernels 6.10.4, 6.10.5, and 6.10.6 result in an unbootable vm, and the last Fedora 40 kernel that worked was 6.10.3.

Just to do some verification, I tried running an Arch Linux guest with kernel 6.10.6 using the same VMWare Workstation install, and that boots perfectly fine.

So whatever this turns out to be, it's not just a simple 'VMWare needs to be updated for the latest kernel' issue: latest Arch seems to be doing something different here than Fedora 40, resulting in the fact that the same kernel will boot in Arch and not in Fedora (and this needs to be investigated). Either that or, I have made different configuration choices when creating these VM's (I cannot recall what choices I made during VM configuration for Arch).

PS: For now, as a temporary workaround, you 'could' choose to add the following line to /etc/dnf/dnf.conf : exclude=kernel kernel-core kernel-devel kernel-modules kernel-modules-core kernel-modules-extra which will prevent dnf from updating the kernel when you do a 'sudo dnf update'. -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

If you can ping the VM and SSH in, then your VM's starting. Just not quite as fully as it does with the previous kernels, which is weird.

Do you normally boot into a Gnome or KDE session (graphical.target https://docs.fedoraproject.org/en-US/quick-docs/systemd-understanding-and-administering/#_mapping_runlevels_to_targets) for login? Or do you just get to multi-user.target and login through a text-based console?

Might be worth looking into the changelog for the kernel package, see if there's anything obvious between this current release and your last previously fully working version? e.g.:

root@fedora:~# rpm -q --changelog kernel-6.10.6-200.fc40.x86_64 | head -50 * Mon Aug 19 2024 Justin M. Forbes jforbes@fedoraproject.org [6.10.6-0] - Add to BugsFixed (Justin M. Forbes) - selinux: revert our use of vma_is_initial_heap() (Paul Moore) - Linux v6.10.6

* Wed Aug 14 2024 Justin M. Forbes jforbes@fedoraproject.org [6.10.5-0] - Revert "ata: libata-scsi: Honor the D_SENSE bit for CK_COND=1 and no error" (Niklas Cassel) - Linux v6.10.5

* Sun Aug 11 2024 Justin M. Forbes jforbes@fedoraproject.org [6.10.4-0] - wifi: brcmfmac: cfg80211: Handle SSID based pmksa deletion (Janne Grunau) - New config for 6.10.3 (Justin M. Forbes) - Linux v6.10.4

That might at least narrow down the likely problem space.

On Tue, 27 Aug 2024 at 13:23, Maarten Hoes hoes.maarten@gmail.com wrote:

I'm running VMware Workstation 17.5.2 on Windows 11.

I don't have '3D Acceleration' enabled (like suggested in the reddit post you linked to), it's already off, so that is not the solution for me.

I'm not sure how to go about booting into text-only mode; I've run 'sudo systemctl set-default multi-user.target', would that be the way, or is there something better to achieve that ?

When booting with '6.10.6-200.fc40', I get a blank (black) screen, but: I can ping the vm and ssh into it. (sorry I didn't try this earlier, I just assumed the system was hung without verifying, but you know what happens when we assUme). -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Well, just because it got annoying, I tried out some different settings for the VM in VMWare, to see if that changed anything. I tried out some different 'Guest Operating System (version)' settings, under 'options->general->guest operating system->version', but that did not change anything.

Then I remembered the reddit post about *disabling* '3D Acceleration" in the VM settings (under display) (which seemed to be of no help, as I already had that turned off), and thought: 'hey, what would happen if I turned that setting on instead of off ?'. And guess what, that did the trick. I now get the login screen again, both for 'multi-user.target' and 'graphical.target'. Weird.

Well, I guess that is enough of a work-around for me, although I'm still not sure or what is at fault here, especially since my Arch Linux vm gets to a graphical login-screen without having this setting enabled.

Oh, well. Thanks for all the help.

On 07.09.2024 14:18, Maarten Hoes wrote:

I have no idea when this will be fixed (or not). However, I personally was able to work around it by *enabling* '3D Acceleration" in the VM settings (under display) for my Fedora 40 VM. You could try to see if that works for you.

I enabled '3D Acceleration' and it worked;

so there should be done a ReadMe or similar, where this should be noted, that for VMware Guests, and X the '3D Acceleration' must be enabled;

just for info: can you look, whether your VM with Arch also has '3D Acceleration' enabled

Greetings,

Walter

Well, looks like I spoke too soon when I said that Arch works 'fine' without enabling '3D Acceleration'. Yes, I get to a graphical login screen on Arch without that setting, but when I actually try to log in I never get to a usable desktop state. In order to achieve that, I also have to enable that setting for Arch.

So it looks like both distro's run into graphical issues when you leave that setting disabled; it's just that they appear at different stages due to installation/distribution differences. I just didn't notice until now because I normally login through SSH, and assUmed that a graphical login screen for Arch also meant that you got a usable desktop environment (without verifying that by actually logging in). Sorry for the noise.