Hello,

i've installed the latest vendor version for Radxa ROCK 5 ITX.
 

When I want to change settings, the password entry pop-up appears briefly and immediately disappears again, preventing the settings from being saved.

I performed a completely fresh installation of the computer, and the problem still occurs. What is causing this?

Any help would be appreciated.

Best regards
Albrecht

Providing logs with 

armbianmonitor -u

 helps with troubleshooting and significantly raises chances that issue gets addressed.

On 9/30/2026 at 8:30 PM, aschaenz said:

When I want to change settings, the password entry pop-up appears briefly and immediately disappears again, preventing the settings from being saved.

 

Can you explain this more. Where? How to reproduce.

@Werner: https://paste.armbian.com/tategezeze
@Igor: I describe an example workflow in detail:
1. Open "System Settings"

2. Search for "Login Screen (SDDM)

3. I select another wallpaper and click "Apply"
4. A popup "Authenticating Required", "Save Settings in SDDM", "Authenticating as <my name> (username)" to enter the password appears for about one second and disappears immediately. So it is not possible for me to enter the password and so it's not possible to save the settings.

This happens with all settings where a authenticating is necessary.

Kindest regards
Albrecht

Written for: the Armbian forum thread, as a reply from defcom5-rockchip, for you to post.

 

Yes, we hit exactly this. Plaid Claude found it on the eMMC on September 27, and the fix is in test9 and in 4.0.

The forum poster's log confirms the same pairing: Armbian 26.8.6 resolute, Ubuntu 26.04's polkit 127, on the 6.1.172 vendor kernel. The KDE dialog vanishing in a second is what GNOME showed us as a spinner that never ended.

One new fact from checking the polkit release notes: the socket-activated helper arrived in polkit 127. So Debian 13 images, with polkit 126, are fine, while every Ubuntu 26.04 and Debian sid image on a Rockchip 6.1 kernel is broken this way. That's a lot of Armbian desktops, which makes this worth a build-framework fix upstream, not just a forum reply.

Here's the reply, also saved on the NAS. Nothing has been posted:

 

Hi Albrecht,

I think this is a bug I ran into on an Orange Pi 5B with the same combination: Armbian resolute (Ubuntu 26.04) on the vendor 6.1.172 kernel. Your log shows exactly that pairing, so it is worth a two-minute check.

What happens. Ubuntu 26.04 ships polkit 127, which runs its authentication helper through a systemd socket (polkit-agent-helper.socket). That helper asks the kernel for SO_PEERPIDFD, which only exists from Linux 6.5. On the 6.1 vendor kernel the helper exits at once with "Pidfd not supported on this platform", and the desktop's polkit agent (KDE's here, GNOME's in my case) treats that as a failed authentication and closes the dialog before you can type. sudo still works because it does not use polkit.

Check (no changes made):

journalctl -b | grep -m3 'Pidfd not supported' systemctl --failed | grep -c polkit-agent-helper
 

If the first prints the message and the second prints a number above zero, it is this bug. Left alone, the failed helper units pile up (I had 18,000 after 45 minutes) and the desktop gets sluggish.

Fix that worked for me, until a kernel ≥ 6.5 arrives for these boards:

sudo systemctl mask polkit-agent-helper.socket sudo dpkg-statoverride --update --add root root 4755 /usr/lib/polkit-1/polkit-agent-helper-1 sudo systemctl reset-failed 'polkit-agent-helper@*'
 

The first line makes libpolkit-agent fall back to the classic setuid helper; the second makes that helper setuid in a way package upgrades keep (dpkg-statoverride rather than chmod). After that the password box appears normally. This is the pre-127 configuration every Ubuntu release before 26.04 used, so nothing exotic. On a kernel 6.5 or newer you would undo both, since the socket route is the more hardened one there.

I believe this affects every Armbian resolute (and Debian sid/forky, polkit 127) desktop image on a Rockchip vendor 6.1 kernel; Debian trixie still has polkit 126 without the socket helper and should be fine. If the maintainers agree, I can prepare a build-framework change that applies the same two lines when the image pairs polkit ≥ 127 with a kernel older than 6.5.

Disclosure: an LLM assistant (Claude) helped me analyse the polkit source and write this up; the testing on the board is mine.

Peace

defcom5-rockchip

Edited October 3Oct 3 by defcom5-rockchip
bold

I have solved the problem with the following instructions (thx to AI):

•  sudo nano /etc/polkit-1/rules.d/49-desktop-bypass.rules

           Paste this exact configuration rule into the text editor:
 

polkit.addRule(function(action, subject) {
    if (subject.user == "<userId>") {
        return polkit.Result.YES;
    }
});

By explicitly declaring that your primary user account <userId>  is trusted by the underlying polkitd architecture, the system settings and the Discover store will instantly clear the action without demanding the bugged KDE graphical authentication prompt to draw on screen.
Try opening your System Settings now to see if they open cleanly. If it's still locked up, run this command and paste the errors it gives you:

• journalctl -b | grep polkit

That will pull the exact system log showing whether it is a session ownership issue or a library failure.
 

@aschaenz I wouldn't do that if I were you. You open up a whole bunch of security issues adding that rule.

The solution above your last post is way better, ie fall back on the old setuid helper and when newer kernel arrives, unmask again.

 

sudo systemctl mask polkit-agent-helper.socket

sudo dpkg-statoverride --update --add root root 4755 /usr/lib/polkit-1/polkit-agent-helper-1

sudo systemctl reset-failed 'polkit-agent-helper@*'

 

If you don't believe me, ask an AI what security implications adding the rule you use imposes.

Thanks bedna,
and to add the specific reason, since it's worse than it looks: that rule has no action check, so it isn't bypassing the one broken prompt — it returns YES for every polkit action for that user. Package installs, user management, mounting disks, systemd units, firmware updates, all without a password, permanently. There's also no subject.local && subject.active test, so a remote session logged in as that user gets the same silent admin rights. If you want to keep something like it while testing, at minimum scope it to the single action id you're hitting and add the local-and-active check — but you shouldn't need it at all.

The masking approach keeps authentication fully intact. You still get the password dialog, PAM still checks it, it's still logged; the only change is that polkit uses its classic helper instead of the socket-activated one that needs a kernel feature from 6.5. That's exactly how every Ubuntu release before 26.04 ran. When a 6.5-or-newer kernel reaches these boards:

sudo dpkg-statoverride --remove /usr/lib/polkit-1/polkit-agent-helper-1
sudo systemctl unmask polkit-agent-helper.socket

Albrecht — did the two commands actually fix it on your ITX? I've only been able to test this on an Orange Pi 5B, so a confirmation (or a "no, still broken") from different hardware would be genuinely useful. If it did work, it probably affects every Armbian resolute desktop image on a 6.1 vendor kernel, and that's worth fixing in the build rather than one board at a time.

defcom5-rockchip

An LLM assistant helped me track down the cause; the testing is mine.