"qubes-gui-daemon-4.1.15 is already installed" when attempting to update to qubes-gui-daemon-4.1.18

[ydirson]

After reading QSB-073 I decided to have a try at installing this update.

First, the links for "how to update" are plain-text at the end of a scrolling-area and would benefit from being href'd somewhere more easily accessible.

Then launching qubes-dom0-update --enablerepo=qubes-dom0-security-testing qubes-gui-daemon, in the terminal that briefly opens I have the time to glimpse the 4.1.18 version number, but then...

[root@dom0 ~]# qubes-dom0-update --enablerepo=qubes-dom0-security-testing qubes-gui-daemon
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
Qubes OS Repository for Dom0                                                                                                                                  2.9 MB/s | 3.0 kB     00:00    
Qubes OS Repository for Dom0                                                                                                                                  2.9 MB/s |  28 kB     00:00    
Package qubes-gui-daemon-4.1.15-1.fc32.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

I'm not yet sure why --console --show-output is not the default with qubes-dom0-update, it seems to me that information it shows should just be always shown, and it does not seem to be available in any log to get after the fact.

So here we go for another try, which only shows that indeed the previous run did download the RPM. But with the missing information from that run I'd say we can't really be sure the original output was the same we have how.

[root@dom0 ~]# qubes-dom0-update --console --show-output --enablerepo=qubes-dom0-security-testing qubes-gui-daemon
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
Warning: Enforcing GPG signature check globally as per active RPM security policy (see 'gpgcheck' in dnf.conf(5) for how to squelch this message)
Fedora 32 - x86_64 - Updates                     60 kB/s |  21 kB     00:00    
Fedora 32 - x86_64                              372 kB/s |  23 kB     00:00    
Qubes Dom0 Repository (updates)                  39 kB/s | 2.7 kB     00:00    
Qubes Dom0 Repository (security-testing)         37 kB/s | 2.9 kB     00:00    
Qubes Templates repository                       41 kB/s | 2.7 kB     00:00    
Package qubes-gui-daemon-4.1.15-1.fc32.x86_64 is already installed.
Dependencies resolved.
================================================================================
 Package           Arch    Version           Repository                    Size
================================================================================
Upgrading:
 qubes-gui-daemon  x86_64  4.1.18-1.fc32     qubes-dom0-security-testing   74 k

Transaction Summary
================================================================================
Upgrade  1 Package

Total size: 74 k
DNF will only download packages for the transaction.
Downloading Packages:
[SKIPPED] qubes-gui-daemon-4.1.18-1.fc32.x86_64.rpm: Already downloaded        
Complete!
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Qubes OS Repository for Dom0                                                                                                                                  2.9 MB/s | 3.0 kB     00:00    
Qubes OS Repository for Dom0                                                                                                                                  2.8 MB/s |  28 kB     00:00    
Package qubes-gui-daemon-4.1.15-1.fc32.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

This one in fact looks much like #4792, and indeed --action=update at last allows to install the update.

[unman]

And yet I was able to install the update without `--action=update`. I have security-testing enabled by default - does this make a difference, as opposed to enabling on the call? I wouldn't have thought so. Nor the fact that you were on 4.1.15 - had you not picked up 4.1.17 from current?

[ydirson]

No, but the update run I launched just prior (only to check if 4.1.18 would come that way, and decided to decline the global update for now) would have included 4.1.17.

But I did not (and still do not) see any pending dom0 update in the taskbar widget, whereas qubes-dom0-update still would update a bunch of packages when I run it.

[andrewdavidwong]

I'm having trouble understanding this report.

First of all, it seems to me that the main problem is that it's trying to install qubes-gui-daemon-4.1.18 (which sounds like the one you want, which implies that you're on 4.1), then failing with the reason that qubes-gui-daemon-4.1.15 is already installed (18 vs. 15). Strangely, though, no one has explicitly said that this is a problem, let alone the main problem. So, is this the main problem? If not, why not?

Secondly, It's unclear to me how this is a UX issue, as it sounds more like some kind of internal bug in the update code. You mention some other possibly-UX-related things in passing, but those should be filed as separate issues, since every issue must be about a single, actionable thing. (I'll update the issue title accordingly.)

Finally, there seems to be an implicit assumption that a big problem here (possibly even the main problem) is that of #4792, namely that the desired package is being downloaded but not installed. But this is even more puzzling, for two reasons:

1. If the system thinks that the package being downloaded is already installed, then this is expected behavior. The fault lies in the system failing to recognize that the package being downloaded is newer than the one already installed, not in the general policy of refraining from reinstalling packages that are already installed (in the absence of some kind of --reinstall option).
2. I forgot the second reason while typing out the first one. 🙃

---

And yet I was able to install the update without --action=update.

As was I.

I have security-testing enabled by default

Same here, FWIW.

No, but the update run I launched just prior (only to check if 4.1.18 would come that way, and decided to decline the global update for now)

I wonder if declining it somehow messed up the internal state of the system and resulted in the aforementioned confusion.

But I did not (and still do not) see any pending dom0 update in the taskbar widget, whereas qubes-dom0-update still would update a bunch of packages when I run it.

That might have to do with the frequency of update checking and which qube(s) are performing the check (e.g., if not running or lacking internet access, there would be no successful check).

[DemiMarie]

I wonder if this is a consequence of the update code encountering an error and failing to retrieve the updates.

[ydirson]

It's unclear to me how this is a UX issue, as it sounds more like some kind of internal bug in the update code.

I think the bug in the update code is already handled as #4792, my point for this one (although I probably diluted it too much with the update problem) is the necessity to add --console --show-output to be able to understand what is going on. In fact, I cannot see a use for not passing them.

[DemiMarie]

@ydirson It increases dom0’s attack surface, as it displays untrusted text (from the UpdateVM) in a dom0 terminal.

[marmarek]

This one in fact looks much like #4792, and indeed --action=update at last allows to install the update.

Kind of yes. Specifically: when you want to update specific package (you give package name on the command line), you need to add also --action=update, as the default action if package name is given is to install (some version) of that package only.

[ydirson]

It increases dom0’s attack surface, as it displays untrusted text (from the UpdateVM) in a dom0 terminal.

Then it seems to me that at least we should make sure the window never closes without user interaction, or maybe, if dnf is not predictable enough, have the logs recorded in the download vm and point the user to this log.

[ydirson]

Kind of yes. Specifically: when you want to update specific package (you give package name on the command line), you need to add also --action=update, as the default action if package name is given is to install (some version) of that package only.

OK, so maybe we should have this spelled out in the docs in the docs pointed to by a QSB ?

[DemiMarie]

Kind of yes. Specifically: when you want to update specific package (you give package name on the command line), you need to add also --action=update, as the default action if package name is given is to install (some version) of that package only.

OK, so maybe we should have this spelled out in the docs in the docs pointed to by a QSB ?

That is probably a good idea.

[ydirson]

I'm not really sure where we stand on that ticket, but "only affects 4.1" should clearly not be a suitable reason to close it - I indeed had to search github to get here and add the --action=update on 4.2.

IMHO there is really a UI issue to be dealt with.