[BUG] Linux: in-app self-update always fails for .deb installs in /opt/unigetui (swap helper runs without elevation)
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 43/100
Piste de recherche
Start by locating the Linux swap helper embedded in the UniGetUI binary and the self-update flow that invokes it; the issue does not name source files or tests. Check how updates are handled for root-owned /opt/unigetui installs and whether dpkg-managed installs have a supported update path. Done means the reported .deb update no longer fails silently and the installed package state is handled correctly.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Please confirm these before moving forward
- I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
- I have tested that this issue has not been fixed in the latest (beta or stable) release.
- I have checked the FAQ section for solutions.
- This issue is about a bug (if it is not, please use the correct template).
UniGetUI Version
2026.3.1 (official .deb), updating to 2026.3.3. The swap helper is unchanged in 2026.3.3.
Windows version, edition, and architecture
Linux Mint 22.3 (Ubuntu 24.04 base), Cinnamon, x86_64, kernel 7.0.0-42-generic. Seen on two different machines.
Describe your issue
When UniGetUI is installed from the official .deb package (which installs to /opt/unigetui, owned by root), the in-app self-update never works:
- The update notification appears and I click Update now.
- UniGetUI downloads
UniGetUI Updater.tar.gzto~/.local/share/UniGetUI/and extracts it to~/.local/share/UniGetUI/update-staging/<guid>/. This step works, and the staged binary is 2026.3.3. - UniGetUI closes, then reopens still on 2026.3.1 and says the update could not be installed.
Root cause (as far as I can tell): the Linux swap helper script embedded in the binary runs as the current (non-root) user and does:
rm -rf "$dir.old"
if mv "$dir" "$dir.old"; then
if mv "$newroot" "$dir"; then
...
else
rm -rf "$dir"
mv "$dir.old" "$dir"
With $dir = /opt/unigetui and /opt being root:root 755, mv /opt/unigetui /opt/unigetui.old fails with "permission denied". The helper then relaunches the old version. No sudo/pkexec prompt is shown, and the system journal has no elevation request from UniGetUI around the update.
There is also a second problem: even if the swap worked (e.g., with elevation), replacing /opt/unigetui behind dpkg's back would leave dpkg -l unigetui reporting the old version.
Steps to reproduce the issue
- Install
UniGetUI.linux-x64.deb2026.3.1 withsudo apt install ./UniGetUI.linux-x64.deb. - Launch UniGetUI as a normal user.
- When the update to 2026.3.3 is offered, click Update now.
- UniGetUI restarts on 2026.3.1 and reports that the update failed.
~/.local/share/UniGetUI/update-staging/still holds the extracted 2026.3.3 files, and no/opt/unigetui.oldexists.
Workaround: download the new .deb and run sudo apt install ./UniGetUI.linux-x64.deb. That works fine.
UniGetUI Log
Not captured during the failed attempt. I can attach it if needed.
Package Managers Logs
Not relevant (the failure is in UniGetUI's own self-updater, not in a package manager operation).
Relevant information
Suggested fix: when the app runs from a directory the user cannot write to (or when it was installed by dpkg/rpm), either:
- download the matching
.deb/.rpmand install it viapkexec apt install ./file.deb(or the equivalent), or - run the swap helper through the existing elevation path (
pkexec/sudo -Awith askpass), or at least - skip self-update and show "Update via your package manager / download the new .deb" instead of failing silently.
Screenshots and videos
No response
- Langage dominant
- C#
- Étoiles
- 27k
- Forks
- 976
- Merge moyen
- 17 h 26 min
- PR mergées (30 j)
- 134
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de Devolutions/UniGetUI
-
bug
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
Devolutions/UniGetUI#5723 · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour
-
bug priority: low winget
Difficulté 3/5 1-2 jours Accessibilité débutants 56/100
Devolutions/UniGetUI#5722 · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour
-
bug winget
Difficulté 4/5 3-5 jours Accessibilité débutants 45/100
Devolutions/UniGetUI#5721 · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour
-
[IMPROVEMENT] Lower GPU usageOuverteenhancement
Difficulté 4/5 3-5 jours Accessibilité débutants 42/100
Devolutions/UniGetUI#5718 · 2 commentaires · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour
-
[FEATURE REQUEST] Add WebDAV as a backup target for Package Backup (self-hosted cloud backups)Ouvertenew-feature priority: medium
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
Devolutions/UniGetUI#5705 · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de Devolutions/UniGetUI
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 67/100
nopSolutions/nopCommerce#8459 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
criticalmanufacturing/cli#909 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
RadicalCSG/com.chisel#312 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
eyalgolan/statecraft-israel#3093 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour