Updating VMs throwing an ssh error. Any ideas?

User Support
1

I run Qubes Updater, but run into errors very quickly. So far, its only on the debian template, or a standalone based on debian. ED: Ticking boxes to update a fedora-32 template triggers the same error.

Updating debian-10

Error on updating debian-10: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=debian-10', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20
debian-10:
      ----------
      _error:
          Failed to return clean data
      retcode:
          1
      stderr:
          Traceback (most recent call last):
            File "/usr/lib/qubes-vm-connector/ssh-wrapper/ssh", line 101, in <module>
              sys.exit(main())
            File "/usr/lib/qubes-vm-connector/ssh-wrapper/ssh", line 94, in main
              return ssh(args)
            File "/usr/lib/qubes-vm-connector/ssh-wrapper/ssh", line 29, in ssh
              assert args[1] == '/bin/sh'
          AssertionError
      stdout:

I don’t really know where to start. Any advice?

2

It’s a known bug:

3

While this is not on the stable repository (won’t be for at least two weeks), if it prevents you from updating, I think you should update these VMs manually.

4

Thanks, I’ve just done.

1 Like
5

I’ve started experiencing this as well. So I’ve also started manually updating stuff.

6

I’m seeing a minimum of one week, not two:

The update remains in security-testing or current-testing for a minimum of one week.

1 Like
7

ok. Sorry. My bad. I misread it.

8

Assuming your templates have not updated to salt-3001.3 already, an option is to backup the template and use it until the fix is in current:

  1. Create a clone of your Fedora/Debian template that does not have the new version of salt that breaks updates
  2. Set the template for the default-mgmt-dvm in Qubes Manager to the clone
  3. Disable updates for this template/ensure this template does not get updated
  4. This will allow your normal template to continue getting OS/qubes updates, but it will not be usable for default-mgmt-vm/updates.

Once the qubes-mgmt-salt-vm-connector-4.1.8+ (or 4.0.24+ for R4.0) fix propagates to the current repos, your normal template should automatically get the fixed version, and then default-mgmt-vm can be switched back to your normal template.

Risk: your cloned default-mgmt-dvm will be “old” for at least a week. Assuming the cloned template is not used for any AppVMs, the risk is minimal. To avoid this risk, update your normal templates manually.

9

You can also do the reverse - create a clone of your normal template that’s fully up to date, update qubes-mgmt-salt* to the latest in current-testing, and use that clone for default-mgmt-dvm until your normal template is functioning again.

This assumes your normal template does not use current-testing and you’d wish to avoid using current-testing packages.

  1. Clone template
  2. Inside cloned template, update it to current-testing packages: dnf update --refresh --enablerepo=qubes-vm-r4.0-current-testing (change r4.0 to r4.1 if necessary)
  3. Use this cloned template for default-mgmt-dvm until qubes-mgmt-salt* 4.1.8+ (or 4.0.24+ for R4.0) comes into current.