No NOVNC. Changing Port did not fix. Anyone have success with nightlies?

[RSVP]

Hi,
So I blindly updated and overlooked the known bug. I read some successes about changing the port to 5900. I had no success on existing VM and on trying to install a new VM. I read you can change the train to nighly, but I no longer see the option to change trains. So curious if anyone has done this? If so how? And did it fix the VNC issue. Thanks

 

[sretalla]

If so how?

You need to go to the manual update file and download that for the master branch here:

https://download.freenas.org/13.0/MASTER/latest/

Then on the updates page, apply manual update and supply the file and tell it where to temporarily store.

 

[RSVP]

You need to go to the manual update file and download that for the master branch here:

https://download.freenas.org/13.0/MASTER/latest/

Then on the updates page, apply manual update and supply the file and tell it where to temporarily store.

Good Morning and thank you for a resopnse. Making my first cuppa, so pardon me not catching on here. I tried the file at the bottom there. And I get

EFAULT] Unable to downgrade from TrueNAS-13.0-RELEASE to TrueNAS-13.0-MASTER-202205050459​

FAILED. Am I using the wrong file? Really bumbed I updated. I dont know why I do that anymore LOL.

Updated to say got caffeine and still stuck here. Thanks

 

[sretalla]

Looks like that "latest" file is from before the release date, so maybe there's a need to wait for a new MASTER to come post RELEASE.

 

[Charles Anderson]

Seems as though the fix for this issue has been checked-in to the STABLE branch. I don't know what that means in terms of availability.

NAS-114595 / 13.0 / Fix vnc args in 13 by sonicaj · Pull Request #8964 · truenas/middleware

This commit brings change to middleware to provide new/updated args to bhyve for vnc as this changed when switching from 12->13.

github.com

 

[mav@]

It means it will be in 13.0-U1 in June, and 13.1 nighlty builds as soon as they are fixed (appear to not upload images since May 5th, I've notified QE team).

 

[Punderino]

Really sucks I went through the same rollercoaster of emotions, trying to update to the nightly and it being older than the release. I guess we just play the waiting game? Changing the port to 5900 didn't fix it for me either.

 

[awasb]

It's quite easy to fix. Browse to the solution/commit in the repo, get the committed changes:

NAS-114595 / 13.0 / Fix vnc args in 13 by sonicaj · Pull Request #8964 · truenas/middleware

This commit brings change to middleware to provide new/updated args to bhyve for vnc as this changed when switching from 12->13.

github.com

Open terminal and search vor vm.py:

Code:

root@truenas ~ # find / -name vm.py

edit file deleting the erroneous lines, add in the corrected ones:

Code:

root@truenas ~ # vi /usr/local/lib/python3.9/site-packages/middlewared/plugins/vm.py

Restart middlewared:

Code:

root@truenas ~ # service middlewared restart

Try to restart the VM and connect to it. It worked for me (though the port reference is still wrong: second digit reading from left to right in the connect URL is still diminished by 1 for the real connect URL; changing by hand works).

 

[Punderino]

It's quite easy to fix. Browse to the solution/commit in the repo, get the committed changes:

NAS-114595 / 13.0 / Fix vnc args in 13 by sonicaj · Pull Request #8964 · truenas/middleware

This commit brings change to middleware to provide new/updated args to bhyve for vnc as this changed when switching from 12->13.

github.com

Open terminal and search vor vm.py:

Code:

root@truenas ~ # find / -name vm.py

edit file deleting the erroneous lines, add in the corrected ones:

Code:

root@truenas ~ # vi /usr/local/lib/python3.9/site-packages/middlewared/plugins/vm.py

Restart middlewared:

Code:

root@truenas ~ # service middlewared restart

Try to restart the VM and connect to it. It worked for me (though the port reference is still wrong: second digit reading from left to right in the connect URL is still diminished by 1 for the real connect URL; changing by hand works).

That's what I ended up doing except I just replaced the entire vm.py file. I found it easiest to just delete the vnc device and readd it without touching it and it'll work.

 

[Whattteva]

Fix worked great, thanks for the help!

However, I think I may have found another bug if someone else could confirm it.
Basically, after using the VM for some time through VNC, one of the next reconnects (randomly) will crash bhyve.
I posted about it in more details here.

 

[Punderino]

Fix worked great, thanks for the help!

However, I think I may have found another bug if someone else could confirm it.
Basically, after using the VM for some time through VNC, one of the next reconnects (randomly) will crash bhyve.
I posted about it in more details here.

I replaced the vm.py with the latest from GitHub entirely and am not experiencing that issue, but I'm also using a different VNC client.

 

[Whattteva]

I replaced the vm.py with the latest from GitHub entirely and am not experiencing that issue, but I'm also using a different VNC client.

Yeah. As I noted on the other thread. There's another bug logged against this and other people besides me also experienced it.

For now, I've worked around the issue by simply installing a VNC server on the guest OS itself so I can avoid using the bhyve VNC. It works great and I have not crashed bhyve since then.