Has anyone observed that occassionally (this may have disappeared & reappeared as a problem across a larger but discontinuous period of time but it’s back) issues with updating only to get a simple failed to update nod (for this purpose let’s assume you are using the alternative to CLI graphical updater but I’m just beginning to bring up rough details of this so bear with me) & with some digging you learn that a simple log file being owned by root was the cause. Then learning that simply deleting or changing the ownership to user allows the graphical update to be retried without problem but presumably this only occurred because previously you used the CLI update method that - from version A, to version B, to version whatever, has sometimes not used the same standard as the graphical one.
For anyone wanting to dig on their systems, under /var/log/qubes you have possibly many log files relating to the updating of qubes where the prefix of update- is the beginning of the filename & the owner of the file seems to cause issues for the graphical update route (using the python-scripted dialog that is possible vs. the salt-powered CLI that many use). Either the CLI method has sometimes had issues or the graphical method has had issues but if the standard is that the owner be user or be root & the update can be borked for the ownership of a log file, I think that needs a little love.
Addendum: here’s a little snippet of seeing this in action from the CLI perspective -
[user@dom0 ~]$ ls -alh /var/log/qubes/update-personal-f41.log
-rw-r–r-- 1 root qubes 1006 Dec 7 18:44 /var/log/qubes/update-personal-f41.log
[user@dom0 ~]$ sudo rm /var/log/qubes/update-personal-f41.log
[user@dom0 ~]$ ls -alh /var/log/qubes/update-sys-f41.log
-rw-r–r-- 1 user qubes 13K Dec 7 08:31 /var/log/qubes/update-sys-f41.log
[user@dom0 ~]$ ls -alh /var/log/qubes/update-sys-dvm-f41.log
ls: cannot access ‘/var/log/qubes/update-sys-dvm-f41.log’: No such file or directory