Qubes Update does not work for Whonix 16 templates ...

[Viktor Ransmayr]

I've installed Whonix 16 on my Qubes OS R4.0 system - and - have switched 'sys-whonix' to 'whonix-gw-16' as well as 'anon-whonix' to 'whonix-ws-16'.

Everything seems to work fine - but - Qubes Updater reports that updates are available for 'whonix-[gw | ws]-16' but always fails to update the templates with error msgs similar to

###

    Updating whonix-gw-16
    
    Error on updating whonix-gw-16: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=whonix-gw-16', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20
    whonix-gw-16:
      ----------
                ID: update
          Function: pkg.uptodate
            Result: False
           Comment: E: Release file for tor+https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease is not valid yet (invalid for another 14min 36s). Updates for this repository will not be applied.
           Started: 11:15:16.396556
          Duration: 8366.294 ms
           Changes:   
      ----------
                ID: notify-updates
          Function: cmd.run
              Name: /usr/lib/qubes/upgrades-status-notify
            Result: False
           Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
           Started: 11:15:24.765086
          Duration: 2514.791 ms
           Changes:   
                    ----------
                    pid:
                        1782
                    retcode:
                        100
                    stderr:
                    stdout:
      
      Summary for whonix-gw-16
      ------------
      Succeeded: 0 (changed=1)
      Failed:    2
      ------------
      Total states run:     2
      Total run time:  10.881 s
    
    Updating whonix-ws-16
    
    Error on updating whonix-ws-16: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=whonix-ws-16', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20
    whonix-ws-16:
      ----------
                ID: update
          Function: pkg.uptodate
            Result: False
           Comment: E: Release file for tor+https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease is not valid yet (invalid for another 16min 48s). Updates for this repository will not be applied.
           Started: 11:13:10.907970
          Duration: 2607.219 ms
           Changes:   
      ----------
                ID: notify-updates
          Function: cmd.run
              Name: /usr/lib/qubes/upgrades-status-notify
            Result: False
           Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
           Started: 11:13:13.517469
          Duration: 2907.295 ms
           Changes:   
                    ----------
                    pid:
                        1789
                    retcode:
                        100
                    stderr:
                    stdout:
      
      Summary for whonix-ws-16
      ------------
      Succeeded: 0 (changed=1)
      Failed:    2
      ------------
      Total states run:     2
      Total run time:   5.515 s

###

What are the recommended steps to resolve this issue?

With kind regards,

Viktor

PS: I obviously tried this several time - but - the error msg stays the same - only - with changing "invalid for ..." times ...

[unman]

Fix the time on your update qube,( and possibly your target). It is, as you can see, wrong.

--
I **never** presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

[Viktor Ransmayr]

Hello 'unman',

Thanks a lot for your feedback! - Using 'timedatectl set-time ...' for  'whonix-[gw | ws]-16' did resolve the issue.

I started to read more on this topic now - but - did not (yet) find best practice recommendations on how to ensure that AppVMs & TemplateVMs are time-synced automatically, when they are started.

Do you have any recommendation?

With kind regards,

Viktor

[Viktor Ransmayr]

Any recommendation from someone in the community?

With kind regards,

Viktor

[TheGardner]

managed the download on 4.0.4 in the last days without any issues. Just did it with the qubes-dom0-update command and the enablerepo=community switch. No other commands or work. It just went through like it always do with downloads & installs of new templates.
Sorry, if I couldn't help more.

[Viktor Ransmayr]

Thanks for your feedback.

My initial problem was not with the 'upgrade' from 15 to 16 - but - with the way my Qubes OS instance behaved after having Whonix 15 & 16 installed in parallel. - 'Unman' did resolve that issue already.

What I'm still interested in & continue to struggeling with is "how to ensure that AppVMs & TemplateVMs are / can be time-synced " ...

With kind regards,

Viktor

[Viktor Ransmayr]

This time I have new information on the reported issue. - Template updates were reported for 'fedora-33' as well as 'whonix-gw-16'.

I started Qubes Updater w/o adjusting the time in both templates. - The update of 'fedora-33' succeeded, while 'whonix-gw-16' failed.

Relevant log from 'fedora-33':

    Updating fedora-33
    
    fedora-33:
      ----------
                ID: dnf-and-rpm
          Function: pkg.installed
            Result: True
           Comment: All specified packages are already installed and are at the desired version
           Started: 17:24:48.153995
          Duration: 1836.538 ms
           Changes:   

Relevant log from 'whonix-gw-16':

    Updating whonix-gw-16
    
    Error on updating whonix-gw-16: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=whonix-gw-16', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20
    whonix-gw-16:
      ----------
                ID: update
          Function: pkg.uptodate
            Result: False

           Comment: E: Release file for tor+https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease is not valid yet (invalid for another 33min 20s). Updates for this repository will not be applied.
           Started: 16:26:39.418126
          Duration: 14041.933 ms
           Changes:   

The difference is that 'fedora-33' is using CET, while 'whonix-gw-16' is using UTC.

If I set the time in the 'whonix-gw-16' template to the current CET value, the update succeeds ...

Relevant log from 'whonix-gw-16':

    Updating whonix-gw-16

    
    whonix-gw-16:
      ----------
                ID: update
          Function: pkg.uptodate

            Result: True
           Comment: Upgrade ran successfully
           Started: 17:55:42.134676
          Duration: 24195.111 ms
           Changes:   

I don't want to adjust the time for the two Whonix templates manually to the (wrong?) CET values, whenever an update is necessary.

I don't think I had this issue with Whonix 15 & believe it only started with Whonix 16.

Do you have any ideas or suggestions?

With kind regards,

Viktor

[awokd]

Viktor Ransmayr:

> I don't want to adjust the time for the two Whonix templates manually to
> the (wrong?) CET values, whenever an update is necessary.
>
> I don't think I had this issue with Whonix 15 & believe it only started
> with Whonix 16.
>
> Do you have any ideas or suggestions?

Check dom0's clockvm with "qubes-prefs" in a terminal. It's probably
sys-net. Confirm the timezone and time are set correctly inside sys-net
(or your clockvm if different). If that doesn't do it, and you can
afford it, might try a fresh install of 4.1rc2, and making sure to set
the correct timezone on install. Hard to know which time zone setting is
incorrect.

--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

[Viktor Ransmayr]

Hello awokd,

awokd schrieb am Samstag, 20. November 2021 um 17:47:44 UTC+1:

Viktor Ransmayr:

> I don't want to adjust the time for the two Whonix templates manually to
> the (wrong?) CET values, whenever an update is necessary.
>
> I don't think I had this issue with Whonix 15 & believe it only started
> with Whonix 16.
>
> Do you have any ideas or suggestions?

Check dom0's clockvm with "qubes-prefs" in a terminal. It's probably
sys-net.

Yes it is. Here are the complete preferences:

    [vr@dom0 ~]$ qubes-prefs
    check_updates_vm          D  True
    clockvm                   -  sys-net
    default_dispvm            -  fedora-34-dvm
    default_kernel            -  5.4.143-1.fc25
    default_netvm             -  sys-firewall
    default_pool              D  lvm
    default_pool_kernel       -  linux-kernel
    default_pool_private      D  lvm
    default_pool_root         D  lvm
    default_pool_volatile     D  lvm
    default_qrexec_timeout    D  60
    default_shutdown_timeout  D  60
    default_template          -  fedora-34
    management_dispvm         -  default-mgmt-dvm
    stats_interval            D  3
    updatevm                  -  sys-firewall
    [vr@dom0 ~]$

Confirm the timezone and time are set correctly inside sys-net
(or your clockvm if different).

Here are the results of 'timedatectl':

    [user@sys-net ~]$ timedatectl
                   Local time: Sat 2021-11-20 18:34:11 CET
               Universal time: Sat 2021-11-20 17:34:11 UTC
                     RTC time: Sat 2021-11-20 17:34:11
                    Time zone: Europe/Berlin (CET, +0100)
    System clock synchronized: no
                  NTP service: inactive
              RTC in local TZ: no
    [user@sys-net ~]$

If that doesn't do it, and you can
afford it, might try a fresh install of 4.1rc2, and making sure to set
the correct timezone on install. Hard to know which time zone setting is
incorrect.

A check with / upgrade to  4.1rc2 is not an option for me. - At least not in November ...

With kind regards,

Viktor

[awokd]

Viktor Ransmayr:

> System clock synchronized: no
> NTP service: inactive

Any idea why this isn't running? If your hardware clock is close enough
to the right time, it might not matter, but can't be helping things.
It's showing as synchronized & active on my sys-net. I'm running 4.1,
but pretty sure it showed the same on 4.0.

[Insurgo Technologies Libres / Open Technologies]

On November 20, 2021 8:46:58 PM UTC, 'awokd' via qubes-users <qubes...@googlegroups.com> wrote:
>Viktor Ransmayr:
>> System clock synchronized: no
>> NTP service: inactive
>
>Any idea why this isn't running? If your hardware clock is close enough to the right time, it might not matter, but can't be helping things. It's showing as synchronized & active on my sys-net. I'm running 4.1, but pretty sure it showed the same on 4.0.
>

Dom0 (timedatctl) doesn't know dom0 has time synchronization, since its provided per sys-net by default which is provided as a qubesos service.

You can force time sync once sys-net is network connected by doing the following from dom0 Terminal Emulator:
sudo qvm-sync-clock

Now, sys-net and dom0 are time synced.
Time to restart all qubes:
qvm-shutdown --all --wait

Then all new qubes launched will have dom0 new synced time.

Hope that helps.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.