How long since last dom0 update?

General Discussion
1

Is it me, or has it been weeks or maybe even months since dom0 needed updating?

1 Like
2

I was just thinking of making such a topic…especially because I think that there were no updates ever since this bug started appearing for me, if I remember correctly.

There are multiple users affected by this issue btw, which breaks the standard update method and potentially any updates for dom0…

1 Like
3

Could you elaborate which QubesOS version you are using?

1 Like
4

I’m using a pretty fresh install of Qubes 4.1.2. I have to use sudo qubes-dom0-update --console --show-output --releasever=4.1 for the update attempt to not fail (but it then says “No updates available”).

2 Likes
5

Sorry perhaps one of the core team can help I’m using 4.2.0-rc3.

I’ll ping @marmarek @deeplow see if this can get answered :slight_smile:

Just trying to help you.

2 Likes
6

You can see recent expected updates on Issues · QubesOS/updates-status · GitHub - those open issues (with labels cur-test) are about testing repository, and closed issues (with labels ending with stable) are about updates moved to stable repo already.

5 Likes
7

Thank you @marmarek sorry for the ping.

8

Okay great, thank you. So if I’m seeing things correctly, the last stable dom0 update was supposed to have happened 2 weeks ago…I’m not sure I had that update, but I’ll now watch that github category and see if on the next stable update I’ll get it.

9

I am quite certain I didn’t get that update.

Using what should be the latest version of 4.1–but as I haven’t been getting updates, I would be surprised if it were.

I am using debian 12 sys-net and sys-firewall (no whonix).

10

The bug bearillo pointed to is exactly what I am seeing on my Librem13 install. I will check on my NUC11 box later when I am near it.

On the Librem13 the workaround (sudo qubes-dom0-update --console --show-output --releasever=4.1) seems to function (albeit throwing two release version errors) but tells me there’s nothing to do. I don’t believe that.

edit to add: If memory serves I got the same errors when I tried to install the qubes tab completion package on this laptop (the first step was to do an update). On the other system, however, I was able to install it.

Edit again: On NUC box, I get ONE message about not knowing the release version…but it still says nothing to do.

11

You can easily see which dom0 updates you have received in the past with this command (in dom0):

dnf history

This will give you a numbered list of events, including the date and time of each event. By default, the most recent event is at the top. You can then view the details of any event with this command:

dnf history info <ID_NUMBER>

For example, if you wanted to view the details of event 25, the command would be:

dnf history info 25

This will show you a detailed view of that event, including a list of all packages altered, their version numbers, and even scriptlet output.

(Note: This is not a Qubes OS feature. It’s a DNF feature. Since dom0 is based on Fedora, we have inherited this feature.)

9 Likes
12

You can also check the version numbers of the packages you currently have installed with this command (in dom0):

dnf info <PACKAGE_NAME>

For example:

dnf info xen

This will provide information about the package(s) corresponding to the name you specified, including whether the package is installed and its version number. You can then compare this version number to the version numbers you see in updates-status and in QSBs to confirm that you have the latest package available. Keep in mind, however, that you won’t have packages that are still in the testing repositories unless you enable those repositories. For more information, see Testing repositories.

7 Likes
13

from dnf history: Nothing since August 28, yet my updater says there’s “nothing to do” even doing the workaround.

If that really is the last time dom0 updated, then there’s no issue. But I find that hard to believe since there have been a couple of Xen-related patches since then (one of them still in testing…but the other one should have been pushed long ago).

14

I received the update on August 28, then three more updates - last one on September 27, which installed xen version 4.14.6-2 and the related stuff.

Edit: to add, no workaround(s) used, just the stock graphical Qubes updater.

1 Like
15

Thank you for confirming it’s broken!

I now know I should have been getting certain specific updates, but am not.

Let me clarify: the stock Qubes updater doesn’t work either (big red X every time); that’s why I tried both the standard command line (which results in the messages Bearillo quoted above) and the workaround suggested in the bug report he linked. The workaround doesn’t give me errors about my repositories (or whatever it is), but after downloading about 100MB of stuff, it then says there’s nothing to update.

This is going to make fixing this bug hard…you can’t install the fix if you can’t get the updater to admit it needs to install it.

1 Like
16

Exactly the same for me as @SteveC laid out.

17

For those who aren’t receiving updates:

  • What is your dom0 update qube? What template is it based on?
  • If you normally update over Tor, have you tried updating over clearnet (or vice versa)?
  • Have you tried using the command-line interface to update? What is the output?
  • Have you tried using sudo qubes-dom0-update? What is the output?
3 Likes
18

Okay so I’ve gotten the updates to work again by switching the dom0 update qube to sys-whonix (before that I was updating via sys-firewall, based on debian-12-dvm) and got a huge 320 MB update, including kernel.

I rebooted now and so far everything seems fine.

By command line interface, do you mean sudo qubes-dom0-update or the salt states? I’ve tried the former, output is pretty much the same as posted in the Github thread I linked above, i.e. errors (404) as a result of the “releasever” variable being handed off as escaped “$releasever” in the URL. When using --releasever=4.1 in the command it will work but say 'No updates available` (incorrectly).

I definitely remember that my templates were getting updates for qubes-packages in the last couple of weeks, so it seems only dom0 was affected by this bug.

It’s pretty strange that it would now work over sys-whonix, as well…I just tried with the updater tool again, still using sys-whonix as the update vm of dom0 and it now seems to work as well strangely, so the issue for me is broken dom0 updates over clearnet using disposable sys-firewall as update vm, but not over tor using sys-whonix as update vm.

The output from the updater (after update and reboot) is a bit odd, however:

Updating dom0

local:
    ----------

It gives the green check-mark, but that message seems odd.

I almost thought not to apply the update (which I initiated using sudo qubes-dom0-update --clean --console --show-output --releasever=4.1), because of how strange this issue is, but if it doesn’t throw any errors when listing the packages then gpg verification will have worked, right? The download is also conducted over https, so I probably didn’t screw up approving the update, but please advise if I am mistaken.

19

Forgot to mention: during the dom0 update there were two “errors”, which I ignored, however, as I thought they’re most likely not a problem:

  1. during Running scriptlet: kernel-1000:6.1.43-1.qubes.fc32.x86_64 the next line is:
    /usr/lib/kernel/install.d/20-grub.install: line 81: grub2-get-kernel-settings: command not found

  2. directly after that the following line, which also popped up before in another place:
    cat: /sys/power/resume: No such file or directory

20

Likewise I was using a debian-12-minimal based sys-firewall and sys-net.

They have no trouble updating other VMs, this issue is solely with dom0

And I’ve tried the gui, the standard qubes-dom0-update and the same modified command line as bearillo.

Will try setting update qube to sys-whonix.