tigervnc-1.10.90-1 changed how users launch the VNC server. Since this was included in stable Fedora releases, we should at least provide a /usr/bin/vncserver script that points users to the new directions. See https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/C7YFCJOQ4AT2TPRK4YQ4LSJ2FXB377D3/ for an example of user confusion. Realistically, we shouldn't ship these kinds of changes post-release, but since this is out we can minimize the user impact by providing a script. For F33 and Rawhide, this isn't necessary, although we should include this in the release notes.
FEDORA-2020-98137c59f8 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-98137c59f8
*** Bug 1879740 has been marked as a duplicate of this bug. ***
Seems they are taking something that works just fine, and making it more complicated for no real benefit. I've copied the Xvnc command that the vncserver ends up running, and if forced, will just go with that. Looked at the documentation, and it seems to be a lot of stuff to do. Additionally, they earlier came up with another method that was mentioned, but I tried it, and about halve the time it wouldn't start the vnc session, so went back to the old vncserver :xx method that always worked. Started with Redhat 9 long ago, and gone thru all the versions on Fedora, but perhaps need to look at other distros...
(In reply to Michael Setzer II from comment #3) > Seems they are taking something that works just fine, and making it more > complicated for no real benefit. > I've copied the Xvnc command that the vncserver ends up running, and if > forced, will just go with that. > Looked at the documentation, and it seems to be a lot of stuff to do. > Additionally, they earlier came up with another method that was mentioned, > but I tried it, and about halve the time it wouldn't start the vnc session, > so went back to the old vncserver :xx method that always worked. Started > with Redhat 9 long ago, and gone thru all the versions on Fedora, but > perhaps need to look at other distros... This is upstream change, it's not what we came up with. Switching to another distribution won't fix your problem unfortunately.
FEDORA-2020-98137c59f8 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-98137c59f8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-98137c59f8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Not sure exactly what you mean by upstream. I'm on the tigervnc list, and it just had a post from a user that had the same problem with vncserver being gone. I replied and gave him the info about this bug link. It seems that the vncserver just links to Xvnc, so I've copied the complete command that it has running after the vncserver loads, so think I should be able to run that directly. I've also seen the note mentions just gnome, but I run the vncserver using xfce not gnome, so not sure what this upstream change is going to do. Force everyone to use it with gnome only. The saved command is: /usr/bin/Xvnc :xx -auth /home/user/.Xauthority -desktop machine.dyndns.org:xx (user) -fp catalogue:/etc/X11/fontpath.d -geometry 1600x845 -pn -rfbauth /home/user/.vnc/passwd -rfbport 59xx -rfbwait 30000 changed port and user and machine info Will see what happens. Have an old notebook with fc32 on it, perhaps play with it on that. But know a number of people that remote access to machine with vnc, and if machine is rebooted after the update, they will loose the vnc access completely.
(In reply to Michael Setzer II from comment #6) > Not sure exactly what you mean by upstream. I'm on the tigervnc list, and it > just had a post from a user that had the same problem with vncserver being > gone. > I replied and gave him the info about this bug link. > > It seems that the vncserver just links to Xvnc, so I've copied the complete > command that it has running after the vncserver loads, so think I should be > able to run that directly. Yes, vncserver was just a wrapper around Xvnc. The reason why it changed now to using systemd (which was sort of supported even before) is that using systemd you get a proper/valid session for your DE. For example GNOME will misbehave most like if you run it this way, like not being able to unlock the session because of no PAM initialization etc. > I've also seen the note mentions just gnome, but I run the vncserver using > xfce not gnome, so not sure what this upstream change is going to do. Force > everyone to use it with gnome only. > You can use xfce of course, just change session=xfce in the configuration. The name should match desktop file name in /use/share/xsessions. > The saved command is: > /usr/bin/Xvnc :xx -auth /home/user/.Xauthority -desktop > machine.dyndns.org:xx (user) -fp catalogue:/etc/X11/fontpath.d -geometry > 1600x845 -pn -rfbauth /home/user/.vnc/passwd -rfbport 59xx -rfbwait 30000 > > changed port and user and machine info > This should still work just fine.
Well, that was a shock, to update a package and get a system collapse (I use my Fedora box only through vnc!). I have followed the instructions for adapt to the new start-up, but it runs only when session=gnome. Setting session=plasma you get a black screen! https://bugzilla.redhat.com/show_bug.cgi?id=1880773
I enabled the advisory from testing, installed via dnf update Now /usr/bin/vncserver is a binary pointing me to: /usr/share/doc/tigervnc/HOWTO.md However, that file does not exist. Instead the directory holds a README.rst containing an intro to tigevnc which again references vncserver as a wrapper skript (as it used to be).
FEDORA-2020-98137c59f8 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.