The Qubes GUI updater in 4.2 is great and helps keep track of which qubes should be restarted after an update. Does it indicate when dom0 should be restarted which I think means rebooting the hardware?
No. Not yet (as far as I am aware).
Yes. For example if Xen is updated, you would better reboot the hardware.
p.s. I have to look at “needs restarting plugin” of DNF5. This is a feature which would better be implemented in r4.3
I don’t see many dom0 updates coming through the GUI. Why would it be updated less frequently than the templates?
If something like systemd is updated in a template wouldn’t it likely need to be updated in dom0 as well?
There are two major reasons. 1st of all, there is an effort to keep dom0 as minimal as possible. There is much less software installed on it compared to a full-fledged XFCE template. Hence less updated compared to it. 2nd reason is that dom0 is Fedora 37 based on Qubes r4.2 and it mostly receives back-ported security related updates by Qubes OS team. Not functionality updates.
Not necessarily at the same time. The new systemd update might land at different times on Fedora vs. Debian. Or it might not ship at all for Fedora 37 based dom0 (if the update is not security related). It should be noted that users would most likely experience more dom0 updates on Qubes r4.3 (next release) which will have Fedora 41 for dom0.
2 Likes
@qubesrocks does make a good point, though.
Is there any mechanism at all to “remind” the user that dom0 has been updated, and that they should reboot when convenient?
I mean, experienced Qubes OS veterans will know that it’s time to reboot the machine when dom0 updates break qrexec, and nothing works any more. (Or, at least, restart every running qube)
But maybe a new user might need a bit of a nudge?
1 Like
No. Not at the moment. Related:
opened 03:39PM - 01 Oct 24 UTC
closed 05:22AM - 02 Oct 24 UTC
R: duplicate
T: enhancement
P: default
[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/)
#… ## The problem you're addressing (if any)
Currently neither `qubes-dom0-update` nor Qubes Update (GUI) and not even `qui-update` widget alert user about required restart after a dom0 update. For example in case Xen is updated.
### The solution you'd like
It should be possible to utilize [needs-restarting](https://dnf5.readthedocs.io/en/latest/dnf5_plugins/needs_restarting.8.html) plugin to alert users about required update via `qui-update` widget.
### The value to a user, and who that user might be
Users will know if a reboot is required after dom0 upgrade for the changes to take effect.
### Completion criteria checklist
(This section is for developer use only. Please do not modify it.)
opened 01:37AM - 13 Jun 21 UTC
T: enhancement
P: major
ux
C: updates
**The problem you're addressing (if any)**
Many users are misinterpreting t… he "User action required" section at the top of each QSB. Specifically, they interpret it to mean that they must take some special action besides just updating normally. This is *not* true for most users. Most should just keep updating normally and receive the associated packages when they land in `current`.
In particular, they are interpreting it to mean that they should all be enabling the `security-testing` repo in order to get the updates immediately. In other words, they see each QSB as giving them a "job" to do. Before our recent text change, they interpreted the "job" as saying, "In order to fix your system, enter this command: `sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing`."
Now that we no longer print that exact command in the QSB, they interpret the "job" as saying, "Figure out how to enable something called `security-testing`, then figure out how to use it to update." They see the recent text change as making their "job" harder because it no longer just gives them the exact command they need to enter. A lot of these users see `security-testing` as a "cheat code" to getting security updates faster.
Of course, none of this makes any sense. If we wanted every user to enable `security-testing`, we would just ship Qubes with that repo enabled. Better yet, we would just send all security updates directly to `current` and bypass `security-testing`. In fact, this is what we used to do, before we introduced `security-testing` in the first place! However, we found that (surprise) software updates can have bugs, and it's better to discover and fix the bugs before sending updates to the entire userbase. Hence, `security-testing` was born. It exists for a reason. It would make no sense to have every user figure out how to manually enable it for each QSB. That is clearly not what we intended, but that is what many users are doing.
See these threads for more context:
QSB-068: https://qubes-os.discourse.group/t/qsb-068-disconnecting-a-video-output-can-cause-xscreensaver-to-crash/4354
QSB-069: https://qubes-os.discourse.group/t/qsb-069-multiple-xen-and-intel-issues/4418
**Describe the solution you'd like**
We need to find some way to say, "If you're a normal user, just keep updating normally" while still providing the specific package list for technical readers.
One idea is to split the first section into two: the first for any special user action required (usually nothing special), the second for technical info (including the specific package list). But there is a problem with this idea (explained below).
Here's an example of how this would have looked for QSB-069:
```
User action required
=====================
Users should continue to update normally via the Qubes Update Tool or
its command-line equivalents. [1]
After the packages associated with this QSB have been installed, dom0
must be restarted in order for the updates to take effect.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Patching
=========
The specific packages that address the issues discussed in this bulletin
are as follows:
For Qubes 4.0, in dom0:
- Xen packages, version 4.8.5-34
- Linux kernel packages, versions 5.12.9-1 (for users of the "latest"
kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.1-5
- Linux kernel packages, versions 5.10.42-1, 5.12.9-1 (for users of
the "latest" kernel flavor)
- microcode_ctl package, version 2.1-33.qubes1 (for Intel CPU users)
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [2]
[...]
References
===========
[1] https://www.qubes-os.org/doc/updating-qubes-os/
[2] https://www.qubes-os.org/doc/testing/
```
As you can see, the problem is that a lot of our QSBs require the user to restart something after the packages are installed in order for the update to take effect (in this case, dom0; for QSB-068, it was XScreenSaver). How are regular users who wait for the packages to land in `current` supposed to know when exactly to restart when the updater doesn't tell them? I guess the only option is for them to closely watch the update output over the next couple of weeks after each QSB is released and carefully compare the package names and versions to those mentioned in the QSB, but we can't honestly expect anyone to do this. The best solution would be to implement some kind of notification system so that we can say: "Security updates have been installed. System restart is required."
Then, most QSBs can just look like this:
```
User action required
=====================
No special user action required. Continue to update normally and restart your system when notified. [1]
[...]
```
This notification should work with both the Qubes Update tool and its command-line equivalents. I think it would be simpler just to have something like `update_requires_reboot: [0|1]` to handle all cases. Situations like QSB-068 requiring an XScreenSaver restart would be handled by simply saying that a system restart is required. (Even though it's technically possible to restart only the XScreenSaver daemon or relog the user account, such nuance is just likely to confuse non-technical users, and the marginal benefits are not worth the additional complexity.)
This mechanism is most important for security updates, but even non-security updates for Xen and the kernel also require a reboot to take effect.
**Where is the value to a user, and who might that user be?**
Regular users would be less confused about what to do in response to QSBs and how to handle security updates. This would benefit all regular users who don't already know exactly what to do.
**Describe alternatives you've considered**
Merely rewording QSBs. See above for why this is problemtic.
**Additional context**
See these threads for more context:
QSB-068: https://qubes-os.discourse.group/t/qsb-068-disconnecting-a-video-output-can-cause-xscreensaver-to-crash/4354
QSB-069: https://qubes-os.discourse.group/t/qsb-069-multiple-xen-and-intel-issues/4418
**Relevant [documentation](https://www.qubes-os.org/doc/) you've consulted**
https://www.qubes-os.org/doc/updating-qubes-os/
https://www.qubes-os.org/doc/testing/
**Related, [non-duplicate](https://www.qubes-os.org/doc/reporting-bugs/#new-issues-should-not-be-duplicates-of-existing-issues) issues**
https://github.com/QubesOS/qubes-issues/issues/3430 is closely related but distinct. This issue is only about the Qubes Update tool and its command-line equivalents notifying the user when a restart is required after a update, whereas https://github.com/QubesOS/qubes-issues/issues/3430 also includes things like, "The OS used in this template has reached EOL. Time to replace it with or upgrade it to a supported release."
3 Likes
