Interesting... any idea why this only affected the ArchLinux-supplied versions of Raspberry Pi Imager and didn't affect the pre-compiled AppImages that we supply? (see e.g. #1502 (comment) )

There are a few things at play here, so bear with me..

The thing that I'm the most certain of

This is what my PR addresses, and might be best explained by this:
QT 6.9 Docs

QT 6.10 (latest) Docs

My original PR comment suggesting this being about strictness was incorrect.
In 5.15, they deprecated fileURLin favor of fileUrl.
In 6.10, they removed fileURL.
By convention, the removal of a deprecated feature doesn't get announced when removed, since it is announced at the time of deprecation. It also seems like qmllint would have been silent about this.

I don't have a view of your build system, but I pulled the AppImage from the latest release, and was able to determine that it is running Qt 6.9.3:

$ ./Raspberry_Pi_Imager-v2.0.6-desktop-x86_64.AppImage --appimage-extract
$ strings squashfs-root/usr/lib/libQt6Core.so.6 | grep "Qt 6" | head
Qt 6.9.3 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 11.4.0)

The Arch repo is currently providing Qt 6.10.2.

The difference in behavior between versions aligns with what they show in their docs.

Things I'm less certain about

I believe prior versions of rpi-imager used udisks2 to allow the application to run as a regular user, but I don’t think that’s the case anymore. Since the GUI now makes calls that require elevated permissions directly, the entire GUI itself needs to be run with sudo, which has implications for D-Bus.

I’m not a D-Bus expert, but the default policy on EndeavourOS and Arch uses auth: EXTERNAL. According to Gemini 3 Pro, this means it “triggers the kernel-level UID check.” I did quite a bit of testing, and neither sudo, sudo -E, nor pkexec was able to access my user’s D-Bus session, which appears to be by design.

As a result, I was unable to get my native build, the Arch repository package, or the AppImage to use my system’s native file picker. All of them fail with No D-Bus session bus available. The application does set XDG* and DBUS_SESSION_BUS_ADDRESS environment variables correctly, but it still fails, so Gemini’s explanation seems plausible to me.

I’d be interested to know whether anyone on another distribution is able to use their system’s native file picker instead of the QML fallback.

any idea why this only affected the ArchLinux-supplied versions of Raspberry Pi Imager and didn't affect the pre-compiled AppImages that we supply?

In 5.15, they deprecated fileURLin favor of fileUrl. In 6.10, they removed fileURL. By convention, the removal of a deprecated feature doesn't get announced when removed, since it is announced at the time of deprecation. It also seems like qmllint would have been silent about this.

I don't have a view of your build system, but I pulled the AppImage from the latest release, and was able to determine that it is running Qt 6.9.3:

The Arch repo is currently providing Qt 6.10.2.

Ah excellent! Thank you so much for your digging on this; "In 6.10, they removed fileURL" certainly explains why this only affects the ArchLinux supplied packages.

I'll try to find some time next week to test that AppImages built with your suggested fix included still work okay on Raspberry Pi OS (arm64) and Ubuntu (amd64).

I believe prior versions of rpi-imager used udisks2 to allow the application to run as a regular user, but I don’t think that’s the case anymore.

Correct, there's more info about that in #1336 (comment)

But of course as Raspberry Pi Imager is open-source software, the ArchLinux developers are welcome to maintain a downstream patch that re-enables that functionality in the packages that they provide for their distro.

Good catch, @wallentx - thanks for the submission.

As rpi-imager will migrate to 6.10 fairly soon, this is an extremely valuable catch. Critically, it looks safe to use even in our current vendored 6.9 environment.

believe prior versions of rpi-imager used udisks2 to allow the application to run as a regular user, but I don’t think that’s the case anymore. Since the GUI now makes calls that require elevated permissions directly, the entire GUI itself needs to be run with sudo, which has implications for D-Bus.

That's correct - at least in the current architecture. We observed in internal testing that UDisks2 was completely inoperable in Ubuntu 25.10 - not only did it not prompt, but it threw an auth error back to Imager that presented a UX dead-end. The only viable workaround was to sudo the application - which led to this current architectural workaround.