cursor not working in Ubuntu desktop vm (TrueNAS Core VM)

[Avion]

hey everyone, i got struck by covid, hence the absence from the board. Regarding the questions of "why": I agree, in that it is of course not for admin or any normal use of linux. For me, i constantly break my linux distros when I am too agressively *un-informed* install elements or change elements that i need for ai or cgi development. I am getting better of course to not fall into the trap but mostly it is like " this tool requires xyz version of java or python or this requires that dependencie but has another one (newer or older) installed already and it is impossibly hard for me to cut it out of the system or to get something running. Hence, with a VM instead of my root system on my workstations or notebook i could createe specific and more importantly clean VMs for specifc projects. OR when I actually try something and accidentially ruin a dependency or fry the system I could just reset it. I am/ where going to get into docker to create docker containers for that but along the way realized, that it is a)neccessary but steep learning curve and b) for this simple task maybe overkill.

But since I often have to deal with graphics, it is much much more convenient to have the GUI available and not need to switch to a different system etc.

the teamviewer / remote view alternatives are of course an option to bypass.

 

[murdok610]

hey everyone, i got struck by covid, hence the absence from the board. Regarding the questions of "why": I agree, in that it is of course not for admin or any normal use of linux. For me, i constantly break my linux distros when I am too agressively *un-informed* install elements or change elements that i need for ai or cgi development. I am getting better of course to not fall into the trap but mostly it is like " this tool requires xyz version of java or python or this requires that dependencie but has another one (newer or older) installed already and it is impossibly hard for me to cut it out of the system or to get something running. Hence, with a VM instead of my root system on my workstations or notebook i could createe specific and more importantly clean VMs for specifc projects. OR when I actually try something and accidentially ruin a dependency or fry the system I could just reset it. I am/ where going to get into docker to create docker containers for that but along the way realized, that it is a)neccessary but steep learning curve and b) for this simple task maybe overkill.

But since I often have to deal with graphics, it is much much more convenient to have the GUI available and not need to switch to a different system etc.

the teamviewer / remote view alternatives are of course an option to bypass.

Thanks for the info and we're glad you are feeling better!

I'm really hoping we find a solution here other than some of the cool kids feeling the need to offer solutions like "USE SSH instead" or "Use a different VNC program"

It's like hey your car is broke, just use a bike or walk instead, it's better for you. These solutions are not helpful AT ALL to something that WAS working and is no longer working.

 

[dilacerated]

Thankfully not C-19 here but I've been unpleasantly sick the past two weeks...

I mentioned in post #18 that this happens with my Ubuntu 20.04.6 VM's after they were updated to the latest 5.4 kernel update for 2023-12 (linux-image-5.4.0-169-generic). Happens with FreeNAS 11.2-U8 and 11.3-U5 as well as TrueNAS Core 12.0-U8.1 and 13.0-U6.1. I also tried the latest 5.15 and 5.19 kernels and another Ubuntu based distro (Pop_OS!) with the same result.

Booting my Ubuntu 20.04.6 VM's to the 5.4 kernel release prior to linux-image-5.4.0-169-generic fixes this. That reasonably eliminates our Free/TrueNAS environments as the source of the problem.

That said it's time to think of using a non-Ubuntu based distro. I've not had the time to install and test such out but AlmaLinux and Rocky Linux are looking like where I am going. If anyone beats me to trying another non-Ubuntu based distro please do tell.

 

[alephant]

Hi, my first post here
I found this discussion after upgrading TrueNAS from 12 to 13. Some Linux VMs now have the mouse not working.
It looks like it is a FreeBSD issue, exposed by a stricter check performed on recent Linux kernels.
In fact, I found this bug which seems to explain the root cause: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275760
There is a fix also available but I guess that, for those not willing or capable of rebuilding the OS by themselves, it means we need to wait for a TrueNAS update.

 

[Hutchca]

No easy way to patch an already installed Ubuntu desktop?
Or even a fresh install of a patched version? An updated driver?

Any way to adjust the way FreeBSD or KVM setting to avoid this stricter check?

 

[emsicz]

Just nuked one of my servers 600 miles away. I thought that the U6.1 was out for a good while, so I upgraded. Went to search what the hell is going on and of course found the lordship advice "and why do you need GUI anyway, I do everything in SSH so you should too." Attached is Ubuntu Server VM boot sequence. That entire box is useless now until somebody goes down there and reinstalls the functional release of TrueNAS on it. This is LTS Ubuntu running on stable train of TrueNAS Core. How this kind of screwup is not caught before destructive update is released is beyond me.

 

[dilacerated]

Hi, my first post here
I found this discussion after upgrading TrueNAS from 12 to 13. Some Linux VMs now have the mouse not working.
It looks like it is a FreeBSD issue, exposed by a stricter check performed on recent Linux kernels.
In fact, I found this bug which seems to explain the root cause: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275760
There is a fix also available but I guess that, for those not willing or capable of rebuilding the OS by themselves, it means we need to wait for a TrueNAS update.

Stellar find! Never came up in my Googling. Seeing that this happens with Fedora for one poster in that thread that means my weekend plans just got less involved.

No easy way to patch an already installed Ubuntu desktop?
Or even a fresh install of a patched version? An updated driver?

Any way to adjust the way FreeBSD or KVM setting to avoid this stricter check?

This requires a change in the usb_mouse.c file for bhyve based on the bug thread alephant linked to.

 

[dilacerated]

Just nuked one of my servers 600 miles away. I thought that the U6.1 was out for a good while, so I upgraded. Went to search what the hell is going on and of course found the lordship advice "and why do you need GUI anyway, I do everything in SSH so you should too." Attached is Ubuntu Server VM boot sequence. That entire box is useless now until somebody goes down there and reinstalls the functional release of TrueNAS on it. This is LTS Ubuntu running on stable train of TrueNAS Core. How this kind of screwup is not caught before destructive update is released is beyond me.

Sorry. Not sure why you did that considering posts were made illuminating the fact that this wasn't a FreeNAS/TrueNAS directetly induced problem. This was caused by a change/patch in the Linux kernel in December that is making the rounds throughout all Linux distros.

Thanks to the link from alephant we know that the bhyve usb_mouse.c file requires a change for this to be resolved from the hypervisors end.

Known working solution for FreeBSD systems ATM: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=247158&action=diff

 

[emsicz]

Not sure why you did that

* truenas proposes stable update
* anon updates server
* update destroys the server
* "not sure why you did that"

 

[alephant]

Personally, I am evaluating switching to TrueNAS Scale, which seems superior in terms of virtualization.

 

[dilacerated]

* truenas proposes stable update
* anon updates server
* update destroys the server
* "not sure why you did that"

"update destroys the server" meaning your VM not the NAS right? You posted that your problem is with an Ubuntu "Server" VM (which I assume you've installed a GUI on top of since Ubuntu Server is GUI-less):

Attached is Ubuntu Server VM boot sequence. That entire box is useless now until somebody goes down there and reinstalls the functional release of TrueNAS on it. This is LTS Ubuntu running on stable train of TrueNAS Core. How this kind of screwup is not caught before destructive update is released is beyond me.

As mentioned this was caused by a Linux kernel change/patch last month and was not a FreeNAS/TrueNAS induced problem. You can press ESC at the VM boot, go to Advanced options and boot the previous kernel for the time being while a fix to the bhyve hypervisor comes.

Boot into an Older Kernel By Default in Ubuntu & Other Linux

Want to boot into an older available Linux kernel version by default? Here's how to downgrade the Linux kernel.

itsfoss.com

 

[Hutchca]

Pardon my ignorance, but is there a difference between choosing esc at startup and using system/boot to choose an earlier boot environment?
I tried switching back to 13.0-U6 and it didn't help.

 

[dilacerated]

Pardon my ignorance, but is there a difference between choosing esc at startup and using system/boot to choose an earlier boot environment?
I tried switching back to 13.0-U6 and it didn't help.

Booting to the previous TrueNAS release on your NAS wouldn't help because in the current state of things FreeNAS/TrueNAS is not responsible for this. The bhyve hypervisor will need to be updated to incorporate the fix and such included in a FreeBSD update.

What I mentioned to do was to press ESC at the VM boot, go to Advanced options and boot the previous kernel. If your VM is set to boot right up you'll want to change the boot behavior:

Virtual Machines -> Your Machine -> Devices -> VNC -> Edit -> check "Delay VM Boot Until VNC Connects".

 

[Patrick M. Hausen]

Just nuked one of my servers 600 miles away. I thought that the U6.1 was out for a good while, so I upgraded. Went to search what the hell is going on and of course found the lordship advice "and why do you need GUI anyway, I do everything in SSH so you should too." Attached is Ubuntu Server VM boot sequence. That entire box is useless now until somebody goes down there and reinstalls the functional release of TrueNAS on it. This is LTS Ubuntu running on stable train of TrueNAS Core. How this kind of screwup is not caught before destructive update is released is beyond me.

Can't you navigate to System > Boot, reactivate the last working version, and reboot the server to working state?

 

[dilacerated]

Personally, I am evaluating switching to TrueNAS Scale, which seems superior in terms of virtualization.

If running VM's via your NAS is a top purpose that's definitely the way. KVM is better maintained that bhyve.

 

[truenas]

This was caused by a change/patch in the Linux kernel in December that is making the rounds throughout all Linux distros.

I installed ubuntu-22.04.3-desktop-amd64.iso today under a truenas vm today with the intention of setting up a pi-hole server and encountered this mouse error. So I installed ubuntu-20.04.6-desktop-amd64.iso, which was last modified 3-16-2023. Without doing any updates during the install process, the error is the same. No mouse under VNC using a browser or TIght VNC.

So I installed ubuntu-20.10-desktop-amd64.iso which is out of date. This worked but I could not get any updates nor install pi-hole properly. After running some special commands I was able to update the OS which again broke mouse functionality after a restart.

CentOS 7 works. About to try CentOS 9 next.

 

[Patrick M. Hausen]

If the intention is running PiHole, I recommend installing Ubuntu 22.04 LTS server.

 

[victort]

lol. I can’t believe no one has ever had that username @truenas

 

[truenas]

If the intention is running PiHole, I recommend installing Ubuntu 22.04 LTS server.

Ubuntu Server worked brilliantly. 10 minutes after installing as a Truenas VM, I now have a working pi-hole server. Have a great weekend Patrick

 

[dilacerated]

I installed ubuntu-22.04.3-desktop-amd64.iso today under a truenas vm today with the intention of setting up a pi-hole server and encountered this mouse error. So I installed ubuntu-20.04.6-desktop-amd64.iso, which was last modified 3-16-2023. Without doing any updates during the install process, the error is the same. No mouse under VNC using a browser or TIght VNC.

So I installed ubuntu-20.10-desktop-amd64.iso which is out of date. This worked but I could not get any updates nor install pi-hole properly. After running some special commands I was able to update the OS which again broke mouse functionality after a restart.

CentOS 7 works. About to try CentOS 9 next.

Can't explain that. My 20.04.6 VM's were fine up to 5.4.0-169 and are fine on TrueNAS 13.0-U6.1 with 5.4.0-167.

Not shocking that CentOS 7 works considering it's on life support/soon to be EOL and IBM cannot wait for that to happen.

The linked thread alephant found over in the FreeBSD forum has people reporting this with bhyve on FreeBSD 13.2 and 14.0 using:

• Debian 12.4.0
• Ubuntu 22.0.4 and 23.10
• Fedora 39
• Gentoo (version unknown)