VNC Connection doesn't work on arm64 (Raspberry Pi 4 8Gb) in Ubuntu 22.04 LTS

[fprietog]

# lsb_release -rd
Description: Ubuntu 22.04 LTS
Release: 22.04

# apt-cache policy gnome-remote-desktop
gnome-remote-desktop:
  Instalados: 42.0-4ubuntu1
  Candidato: 42.0-4ubuntu1
  Tabla de versión:
 *** 42.0-4ubuntu1 500
        500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages
        100 /var/lib/dpkg/status

# uname -a
Linux fpgrpi 5.15.0-1005-raspi #5-Ubuntu SMP PREEMPT Mon Apr 4 12:21:48 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

Summary of the bug:
-------------------
When I try to connect to gnome-remote-desktop using VNC to a Raspberry Pi 4 Model B Rev 1.4 (8Gb) under Ubuntu 22.04 LTS the VNC client can't connect (connection is refused). The connection passes the Password check validation but don't connect (sometimes shows screen garbage before disconnecting).

I've used several VNC clients (Remmina in Ubuntu and Real VNC in Android) getting the same problem failing either in X11 or Wayland.

Notes:
- VNC connection does work in in previous Ubuntu 21.10 version with the same architecture (arm64) and same Raspberry Pi.
- VNC connection also does work in amd64 machines with Ubuntu 22.04 LTS and gnome-remote-desktop 42.0-4ubuntu1, exactly the same software version that doesn't work on arm64 (Raspberry Pi).

There is no apport info at all. Also there is almost no info in the journal regarding this problem. When I try to connect to VNC server it show this:

On Wayland:
-----------
abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 1884160 bytes), total 32768 (slots), used 3 (slots)
abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 4169728 bytes), total 32768 (slots), used 3 (slots)
abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 8130560 bytes), total 32768 (slots), used 83 (slots)
abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 8294400 bytes), total 32768 (slots), used 3 (slots)
abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 8294400 bytes), total 32768 (slots), used 3 (slots)
abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 8294400 bytes), total 32768 (slots), used 3 (slots)
abr 25 00:21:42 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 8294400 bytes), total 32768 (slots), used 3 (slots)
abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Main process exited, code=killed, status=11/SEGV
abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Failed with result 'signal'.
abr 25 00:21:43 fpgrpi gnome-shell[1497]: D-Bus client with active sessions vanished
abr 25 00:21:43 fpgrpi systemd[1381]: gnome-remote-desktop.service: Scheduled restart job, restart counter is at 1.
abr 25 00:21:43 fpgrpi systemd[1381]: Stopped GNOME Remote Desktop.
abr 25 00:21:43 fpgrpi systemd[1381]: Starting GNOME Remote Desktop...
abr 25 00:21:43 fpgrpi systemd[1381]: Started GNOME Remote Desktop.
abr 25 00:21:43 fpgrpi gnome-remote-desktop-daemon[2125]: Cannot load libcuda.so.1
abr 25 00:21:43 fpgrpi gnome-remote-desktop-daemon[2125]: Cannot load libnvidia-encode.so.1
abr 25 00:21:43 fpgrpi gnome-remote-de[2125]: RDP server started
abr 25 00:21:43 fpgrpi gnome-remote-de[2125]: VNC server started

On X11:
-------
abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Main process exited, code=killed, status=11/SEGV
abr 25 00:12:18 fpgrpi gnome-shell[3044]: D-Bus client with active sessions vanished
abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Failed with result 'signal'.
abr 25 00:12:18 fpgrpi systemd[2859]: gnome-remote-desktop.service: Scheduled restart job, restart counter is at 19.
abr 25 00:12:18 fpgrpi systemd[2859]: Stopped GNOME Remote Desktop.
abr 25 00:12:18 fpgrpi systemd[2859]: Starting GNOME Remote Desktop...
abr 25 00:12:18 fpgrpi systemd[2859]: Started GNOME Remote Desktop.
abr 25 00:12:19 fpgrpi gnome-remote-desktop-daemon[23876]: Cannot load libcuda.so.1
abr 25 00:12:19 fpgrpi gnome-remote-desktop-daemon[23876]: Cannot load libnvidia-encode.so.1
abr 25 00:12:19 fpgrpi gnome-remote-de[23876]: RDP server started
abr 25 00:12:19 fpgrpi gnome-remote-de[23876]: VNC server started

[fprietog (fprietog)]

I managed to get a crash file from apport. It's attached.

[Sebastien Bacher (seb128)]

Thank you for your bug report. How did you enable the sharing? The default protocol and suggested one is RDP, did you try if that works better?

[fprietog (fprietog)]

* How did you enable the sharing?

Using the config page: see attached image.

I'm using exactly the same configuration and OS in 3 computers: 2 amd64 and the arm64 Raspberry Pi. In the amd64 ones VNC works. It only fails in the arm64 Raspberry Pi.

* The default protocol and suggested one is RDP, did you try if that works better?

In my case RDP just doesn't work in any of my machines (neither amd64 nor arm64). The RDP server gives these errors when I try to connect:

abr 25 19:06:26 fpglinux gnome-remote-desktop-daemon[4496]: [19:06:26:631] [4496:5565] [WARN][com.winpr.negotiate] - AcceptSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
abr 25 19:06:26 fpglinux gnome-remote-desktop-daemon[4496]: [19:06:26:731] [4496:5565] [WARN][com.winpr.negotiate] - AcceptSecurityContext status SEC_I_COMPLETE_NEEDED [0x00090313]
abr 25 19:06:26 fpglinux gnome-remote-desktop-daemon[4496]: [19:06:26:731] [4496:5565] [ERROR][com.winpr.sspi.NTLM] - Message Integrity Check (MIC) verification failed!
abr 25 19:06:26 fpglinux gnome-remote-desktop-daemon[4496]: [19:06:26:731] [4496:5565] [WARN][com.winpr.sspi] - CompleteAuthToken status SEC_E_MESSAGE_ALTERED [0x8009030F]
abr 25 19:06:26 fpglinux gnome-remote-desktop-daemon[4496]: [19:06:26:731] [4496:5565] [WARN][com.freerdp.core.nla] - CompleteAuthToken status SEC_E_MESSAGE_ALTERED [0x8009030F]
abr 25 19:06:26 fpglinux gnome-remote-desktop-daemon[4496]: [19:06:26:731] [4496:5565] [ERROR][com.freerdp.core.transport] - client authentication failure
abr 25 19:06:26 fpglinux gnome-remote-desktop-daemon[4496]: [19:06:26:731] [4496:5565] [ERROR][com.freerdp.core.peer] - peer_recv_callback: CONNECTION_STATE_INITIAL - rdp_server_accept_nego() fail
abr 25 19:06:26 fpglinux gnome-remote-desktop-daemon[4496]: [19:06:26:731] [4496:5565] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
abr 25 19:06:26 fpglinux gnome-remote-de[4496]: Unable to check file descriptor, closing connection

These errors may be related to this problem that I think is not solved in the Ubuntu current freerdp version:
https://github.com/FreeRDP/FreeRDP/issues/7722

[Pascal Nowack (pnowack)]

To be honest, the issue description is insufficient and the crash file useless.
The stacktrace does not contain any debug symbols and for the "sometimes shows screen garbage before disconnecting" part, a screenshot would be needed, because the screen content is not just garbage.
It has a pattern, and that is a wrong DRM format modifier. It may not be obvious for the user, but developers don't have a glass ball in front of them to see what happens on the other side of the screen, so a screenshot can be super helpful.

I found similar stacktraces in Ubuntus error tracker. Problem with Ubuntus error tracker is that a lot stacktraces cannot be retrieved and therefore leave only a single line of calls, where only the library name is shown.
And this is also here the case.

However, the issue could be fixed upstream and is fixed in the current master branch of g-r-d, due to kind help of a person in https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/96.
Personally, I don't have an arm64 device, which is why this issue could never been detected.
And without that help in form of testing patches and providing the stacktrace with debug symbols, the issue would still exist.

The crash itself is kinda interesting, because it appears, that some instructions are completed in a different order on arm64.
It was fixed in https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/commit/bdc8d63bddf2ebb0da97e9277267b7398e49710e and https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/commit/b7b0597ba59072b718a78760c2732e64e080b4bf.

Then, to the part, what is here referred to as 'garbled content':
A screenshot for this is provided here: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/96#note_1435877
Without the screenshot, I wouldn't been able to have that modifier guess. So, please, for future reports provide screenshots for such things.
The issue here is that g-r-d always expected explicit DRM format modifiers. However, it is an implicit modifier here.
There is no such flag to indicate that and as a result the `DRM_FORMAT_MOD_INVALID` modifier is used to indicate an implicit modifier.
It is a weird thing though: In a screencast, submitting this specific modifier means, that an implicit modifier is used, while graphics APIs use this to indicate an error.
However, using `DRM_FORMAT_MOD_INVALID` as modifier was never a problem with other drivers, like Intel and so it was unnoticed.
The issue was fixed in https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/commit/60244e96333fbeabfee9c1a0e5ce56590dbb313d and https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/commit/d9923317f0b60621f0aeb219f4d10612a2178e63.

I'll ask Jonas to push another release tag (might be 42.1.1). 42.1 was pushed saturday, but does not contain these fixes. Personally, I see this issue as severe, but I am not one, who can push tags in g-r-d. So, I can only ask Jonas to push one.
In any case, Ubuntu can also build g-r-d from the master branch until commit https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/commit/d9923317f0b60621f0aeb219f4d10612a2178e63 to push the fix to Ubuntu here.

[Pascal Nowack (pnowack)]

As for the RDP connection problem, please provide enough information.
If you have an updated system, then your FreeRDP build should contain the NTLM fixes. Jeremy afaik backported them to Ubuntu in https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1968577.
Meanwhile, FreeRDP-2.7.0 was released, and distros should update to that version.

If you have your system updated (and therefore should have the NTLM fixes), then the issue is either you provided the wrong credentials or an error in the client.

Without providing the information, which client and which client settings are used, there is nothing, that can be said here.
Please the follow the official help: https://help.ubuntu.com/stable/ubuntu-help/sharing-desktop.html
It contains a section about recommended clients and client settings.

[Sebastien Bacher (seb128)]

Thanks Pascal for the details, we will make sure to do a stable update with the fixes you mentioned (or using 42.1.1)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Zakhar (alainb06)]

I am experiencing the exact same syndromes plus "Settings" does not seem to be recording correctly the VNC password, it keeps taking another value after reboot... strange, I'll have to reproduce it.

I am eagerly waiting for the fix to make its way to the official repos!

It is a pity Canonical is advertising super optimisations on Raspberry Pi 4 with 22.04 and this basic feature is totally broken as is: was never ever tested...

This is a complete show-stopper for me as remote access to the machine, be it through SSH (which works!) or graphically, is sort of a necessary feature for this kind of machines.

Probably some way of improvement in the QA... like suggesting Canonical to buy a Raspberry Pi 4 to the maintainers involved!.. That's a pretty inexpensive machine. :-)

[Prit Varmora (prit-varmora)]

hello guys,

This issue is really making ubuntu 22.04 useless on raspberry pi 4,

DOES ANYONE HAVE ANY ALTERNATE OR TEMPORARY SOLUTION TO IT?

we need to use raspberry pi remotely as it is mounted on our robot without connecting any screen.

 :)

It would help us a lot

[fprietog (fprietog)]

As a temporary (or final) solution just use another VNC or RDP Server. You can do that only if you use X11 because apart from gnome-remote-desktop there are no working desktop sharing utilities for Wayland.

You've more info here: https://help.ubuntu.com/community/VNC/Servers

For instance, I'm using vino VNC server, the old-but-gold sharing server for Ubuntu.

I'm not only using it to remotely access an started user session. I also use it to access gdm remotely so I can start users sessions remotely directly from the greeter. This is something that I haven't managed to do with genome-remote-desktop because of it's way of store/access credentials.

[fprietog (fprietog)]

Just updated to these packages:

- gnome-remote-desktop (42.1.1-0ubuntu1)
- libfreerdp2-2:arm64 (2.6.1+dfsg1-3ubuntu2.1)
- libfreerdp-server2-2:arm64 (2.6.1+dfsg1-3ubuntu2.1)
- libfreerdp-client2-2:arm64 (2.6.1+dfsg1-3ubuntu2.1)

And VNC and RPD sharing are working now in arm64 (Raspberry Pi 4B). So bug seems to be fixed.

[Jeremy Bícha (jbicha)]

The gnome-remote-desktop 42.1.1 release is rolling out in updates over the next few days.

[fprietog (fprietog)]

Well, as I stated above the fix is working and now VNC and RDP connections are working again.

But I've tested gnome-remote-desktop under X11 and Wayland and there is a real performance problem in Wayland compared to X11 (key presseds are shown with a lag of seconds because refresh takes too much time). While you are connected to a gnome-remote-desktop session (using VNC or RDP) and only under Wayland the system log is populated several times per second with these messages that may be related to the performance problem:

...
jun 08 10:13:08 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 14 (slots)
jun 08 10:13:08 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 106 (slots)
jun 08 10:13:08 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 8294400 bytes), total 32768 (slots), used 2 (slots)
jun 08 10:13:08 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 8294400 bytes), total 32768 (slots), used 2 (slots)
jun 08 10:13:08 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 8294400 bytes), total 32768 (slots), used 2 (slots)
jun 08 10:13:08 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 8294400 bytes), total 32768 (slots), used 2 (slots)
jun 08 10:13:09 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 1933312 bytes), total 32768 (slots), used 2 (slots)
jun 08 10:13:09 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 14 (slots)
jun 08 10:13:09 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 106 (slots)
jun 08 10:13:09 fpgrpi kernel: vc4-drm gpu: swiotlb buffer is full (sz: 8294400 bytes), total 32768 (slots), used 2 (slots)
jun 08 10:13:13 fpgrpi kernel: swiotlb_tbl_map_single: 82 callbacks suppressed
...

These messages stops when you disconnect to gnome-remote-desktop.

Please, tell me if it's necessary to open another bug for this problem or can be followed here.

[Pascal Nowack (pnowack)]

fprietog, that's a driver issue. Nothing what g-r-d can do about (nor even knows about). It should be reported against the RPi gpu driver here.
This is something, that Ubuntus Raspberry Pi team should actually test, before advertising RPi support.

Possible related issues:
https://github.com/raspberrypi/linux/issues/3416
https://github.com/raspberrypi/linux/issues/3411

[Dave Jones (waveform)]

> It is a pity Canonical is advertising super optimisations on
> Raspberry Pi 4 with 22.04 and this basic feature is totally broken
> as is: was never ever tested...

Graphical remote desktop is far from a "basic" feature, in my opinion
(an opinion bolstered by the fact it is only a recent addition to the
set of seeded packages on the desktop).

Booting, graphical session starting successfully, login operating, web
browser launching, video and audio playback working, ethernet, wifi,
and bluetooth communication working, USB peripherals functioning.
These are "basic" features. These are the sorts of things on the ISO
test list [1] that get tested on all supported Pis prior to release
and which, should they fail, will either constitute a release blocker
or, at the very least, are added to the release notes.

[1]: http://iso.qa.ubuntu.com/qatracker/milestones/433/builds/250034/testcases

> This is a complete show-stopper for me as remote access to the
> machine, be it through SSH (which works!) or graphically, is sort of
> a necessary feature for this kind of machines.

Are you aware of X-forwarding over SSH, which incidentally works
happily on the Pi desktop images? What remote graphical functionality
do you require that is not supported by this?

> Probably some way of improvement in the QA... like suggesting
> Canonical to buy a Raspberry Pi 4 to the maintainers involved!..
> That's a pretty inexpensive machine. :-)

As I hope is clear from the above, we do have Pi 4s (quite a lot of
them, as we need to cover numerous models and board revisions), and
testing does indeed occur.

Coincidentally, though remote desktop is not on the "mandatory" list
of testing, I was aware of this bug shortly before jammy's release
(and went back and re-verified it after the release, confirming it).
However, I felt it didn't warrant inclusion on the release notes
because it's simply not "basic" functionality, and there were far more
important things that were (and in some cases still are), broken at
release time.

That said, remote desktop is (now) seeded and it would be useful to
add it to an optional list of tests to run through before release. To
that end I've opened LP: #1978113 to remind myself to write an
"optional" set of tests for the desktop images. Please feel free to
make the case (on LP: #1978113) that remote desktop should be on the
"mandatory" list of tests, if you feel it is genuinely critical
functionality (I can just about see the case for X-forwarding over
SSH; I cannot, currently, for full remote desktop).

[fprietog (fprietog)]

@waveform

I think that the meaning of "basic" feature in an OS is something that can't be stated universally because it depends of the usage done by each set of users. In my opinion remote desktop is a "basic" feature because I use the Raspberry Pi remotely. And for a Raspberry Pi that's nothing unusual at all.

I don't know what you mean when said that remote desktop is a recent addition to the desktop... gnome-remote-desktop is a recent software and also Raspberry Pi Desktop official support, but I've using Ubuntu's default remote desktop for years: vino-server (in fact, I'm still using to connect to the greeter).

I agree with you that testing remote desktop before release is a good idea. You may think that it's not a "basic" feature as it can be sorted using other software, but it creates a problem for the users (we're lazy bast*rds!) but also gives "bad press" to the distribution when something that is managed in the main settings of the distribution just don't work.

Also wanted to thank you for all the effort done for Raspberry Pi users with your work in this distribution.

[Dave Jones (waveform)]

> I don't know what you mean when said that remote desktop is a recent addition to the desktop...

I'll just address this point, but continue the discussion of what should be included in the mandatory testing over on LP: #1978113.

What I specifically meant by "recent addition" is that, prior to impish (I'd thought it was jammy, but checked back on the manifests and it was actually impish this occurred), while gnome-remote-desktop was available, it wasn't installed by default. If you look at the project page (https://launchpad.net/ubuntu/+source/gnome-remote-desktop) you'll see that the focal release has "release (universe)" after it, while the impish, jammy, etc. releases have "release (main)".

In order for something to be included in the Ubuntu images at release it has to be in the "main pocket" (theoretically at least, there are some minor exceptions to this, mostly firmware related). If something's in the main pocket some team in Canonical has to take responsibility for looking out for its bugs and maintaining the package. If it's in "universe" that's "community support". You can install it, you can file bugs against it, but there's no guarantee anyone's going to look at them. Hence, prior to impish there's no chance gnome-remote-desktop could be in the ISO tracker tests, because it wasn't installed by default and those tests are all about ensuring the functionality of the image (not anything users choose to install after the fact).

In other words, I should've been more specific: it's a recent(ish) addition to the Ubuntu image (rather than the Ubuntu repositories), and thus a recent addition to the set of packages we have a commitment to test and fix bugs in.

[wendellgee (wendellgee)]

Can confirm, both VNC and RDP have started to work with the latest update.

Many many thanks, I had to postpone Ubuntu upgrades on Raspberry Pi 4 since 20.10 because of remote desktop issues.

Hint that solved inability to connect with the screen locked:
$ flatpak install flathub com.mattjakeman.ExtensionManager
$ flatpak run com.mattjakeman.ExtensionManager
Through Gnome Extension Manager install "Allow Locked Remote Desktop" and it works.

[Zakhar (alainb06)]

Sorry @Dave Jones to have considered Remote Desktop as "basic". It has been in "settings" for a while now in Ubuntu, so I was taking it for granted.

And yes I'm aware of X-forwarding... it does NOT provide a full desktop but only discrete graphical applications, and I have used it in some occasion. The trouble here is that 22.04 comes with Wayland, and as the name says, X-Forwarding works only on X11 isn't it! I wanted to test the most "out of the box" possible, and not start messing up with graphical environment.

That being said, unfortunately this is not at all fixed for me!

Several bugs are still there after a full upgrade, and having checked the packages above at #11 are at the latest version.

- "Settings" do NOT remember the password I set! It keeps changing after a reboot...
- Connecting via VNC loops at the screen where it asks for a password, and keeps saying the password I pass is incorrect (related to previous bug?)
- Connecting with RDP keeps crashing on the client (the windows closes immediately after password input, "Domain" stays blank...we are not on W$, I don't have a "Domain"!)

My client is Remmina 1.4.2 (snap) running on Ubuntu Desktop 20.04 with X11.

So... any chance someone could test that combo: Raspberry Pi 22.04 Wayland + Desktop (amd64) 20.04 on X11

The "not saving password" on settings on Raspberry PI 22.04 is probably independent of graphical environment and a bug on it's own certainly.

I'll try in another 6 month... and by the time continue happily with the good old Raspbian-Buster 32 bits.

[Zakhar (alainb06)]

New test on January 14th 2023!

VNC from another Ubuntu machine using Remmina as client is now working with severe limitations.

Documentation I found after some more research:
- Probably a security feature:

Remote Desktop does NOT work when:
- the session is locked
- even when screen is blanked via for instance the command

dbus-send --session --dest=org.gnome.ScreenSaver --type=method_call /org/gnome/ScreenSaver org.gnome.ScreenSaver.SetActive boolean:true

That is understandable and would not be a blocker on my use case.

Another thing, though that is a blocker, is that the password keeps changing!

Steps to reproduce:
- Switch remote desktop on
- Allow VNC (legacy method), tick "requires a password"
- Set your user ID and password
- Click on the button to view your password, and check this is indeed what you have set
- Without locking your session or even blanking the screen, connect from another Ubuntu machine (Remmina-VNC) typing your ID and Password
- This should now work

- Now reboot your Raspberry Pi 4 Ubuntu 22.04
- Display again the settings about remote connection
- Click on the button to view the password
- It is now a whole new password apparently randomly set at start up.

So now, either you need a method to get that password from command line, or set it back from command line (since you can still SSH and fortunately the SSH password is not messed around the same) or you are blocked!

Questions:
- Is this resetting of the remote password intended?
- If so, how can we retrieve/reset it from command line (gsettings, dconf,...)
- If not, should I file a different bug report?

[Zakhar (alainb06)]

Sorry for the incomplete search...

Apparently this is sort of a "known bug", due to the fact that when in "auto-login" the keyring is not unlocked then VNC server cannot access the stored password and creates a new random one.

https://askubuntu.com/questions/1403943/22-04-remote-desktop-sharing-authentication-password-changes-every-reboot

There is a semi-insecure fix proposed.

I'll try that until a better fix is proposed!

[fprietog (fprietog)]

@Zakhar

Don't waste your time with this application. In kinetic the VNC support has been dropped because GNOME rules, and Ubuntu, as a GNOME sub-brand, blindly followed that decission.

You can still use another VNC server if you are using X11 (I don't know a VNC server that works for Wayland).

[Zakhar (alainb06)]

@fprietog

Indeed I regret the open VNC standard is dropped in favour of the proprietary Microsoft's protocol RDP, itself using H.264 licence ridden compression. It might be a more efficient standard (I hope so at least), but it does not go in the direction of freedom!

This issue about RDP would be pretty much the same. On a clean 22.04 RaspbPi 4, the keyring only has 2 keys: the one for VNC password, and the one for RDP configuration.

So, in all probability, if the server machine you want to access remotely via RDP has been set as auto-login, which is convenient for a headless Raspberry Pi 4, the machine won't be able to access whatever RDP configuration you have set for the reason explained above (follow the link), and would probably use a default, and possibly a random password when needed.

Then, you probably won't be able to access the machine with RDP also without doing the same trick.

[Zakhar (alainb06)]

Unrelated to the current report, anyway I'll stick to my old Raspbian 32 bits (Buster) since Ubuntu 22.04 currently lacks video hardware acceleration:

https://ubuntuforums.org/showthread.php?t=2478838

... one of the main uses of my RaspbPi being to watch videos without having run my Desktop PC!

So yes, Ubuntu on Raspberry Pi 4 is a nice proof of concept, but there is some work to do to catch up with the Raspeberry Pi OS... and not only on VNC that is so much better integrated on Raspbian.

Keep up the good job!