dependency problem after upgrading standalone debian 11 VM

[qubes...@riseup.net]

Hello!

a while ago when migrating Qubes 4.0 to Qubes 4.1
I restored a standalone debian VM (created on r4.0) on a fresh r4.1 system and did not
notice that I also should replace the r4.0 repos _in_ the VM to r4.1 repos
but it still worked fine.

Today I replaced this line:
deb [arch=amd64] https://deb.qubes-os.org/r4.0/vm bullseye main

with this:
deb [arch=amd64] https://deb.qubes-os.org/r4.1/vm bullseye main

in the standalone VM.

After an
apt update
apt upgrade
apt dist-upgrade

I'm running into this error:


The following additional packages will be installed:
xen-utils-guest
The following NEW packages will be installed:
xen-utils-guest
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
36 not fully installed or removed.
Need to get 0 B/30.1 kB of archives.
After this operation, 53.2 kB of additional disk space will be used.
Do you want to continue? [Y/n]
(Reading database ... 242630 files and directories currently installed.)
Preparing to unpack .../xen-utils-guest_4.14.5-20+deb11u1_amd64.deb ...
Unpacking xen-utils-guest (4.14.5-20+deb11u1) ...
dpkg: error processing archive /var/cache/apt/archives/xen-utils-guest_4.14.5-20+deb11u1_amd64.deb (--unpack):
trying to overwrite '/lib/systemd/system/xendriverdomain.service', which is also in package xen-utils-common 2001:4.8.5-42+deb11u1
Errors were encountered while processing:
/var/cache/apt/archives/xen-utils-guest_4.14.5-20+deb11u1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


Do you have any recommendation on how to solve this issue?

thanks!

[qubes...@riseup.net]

> Do you have any recommendation on how to solve this issue?

I also tried:
https://github.com/QubesOS/qubes-dist-upgrade/blob/release4.0/scripts/upgrade-template-standalone.sh#L37-L72

found via:
https://github.com/QubesOS/qubes-issues/issues/7865#issuecomment-1407236960

but running:
apt-get install --allow-downgrades -y \
'xen-utils-common=4.14*' \
'libxenstore3.0=4.14*' \
'xenstore-utils=4.14*'

fails because I did run
'apt upgrade; apt dist-upgrade'
already:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '4.14.5+94-ge49571868d-1' (Debian-Security:11/stable-security [amd64]) for 'xen-utils-common'
Selected version '4.14.5+94-ge49571868d-1' (Debian-Security:11/stable-security [amd64]) for 'libxenstore3.0'
Selected version '4.14.5+94-ge49571868d-1' (Debian-Security:11/stable-security [amd64]) for 'xenstore-utils'
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
qubes-core-agent : Depends: xen-utils-guest but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
exit


Is there a way out?

[unman]

Exactly this issue arose on GitHub - it is, as you say, because you did
not update the qubes repository definition in timely way.
You can read the issue [here](https://github.com/qubesos/qubes-issues/issues/7865)

The resolution is to follow the steps in the upgrade script - courtesy
of Marek:
```
The source of the problem is that in R4.1 we actually stopped shipping own duplicated xen packages, and are relying on those from official Debian repositories. But the upgrade path requires manual step because of that.
The in-place R4.0 -> R4.1 upgrade tool handle that automatically, but in case of manual upgrade, see this part:
https://github.com/QubesOS/qubes-dist-upgrade/blob/release4.0/scripts/upgrade-template-standalone.sh#L37-L72
```

[qubes...@riseup.net]

Hi uman,

thanks for your reply.

'unman' via qubes-users:

Yes I know about this github ticket, I mentioned in my last email, but
I have the impression that these step can not be used _after_
running 'apt update; apt upgrade; apt dist-upgrade' anymore - which is the situation I'm in.

Is there also a way to recover a system after the 'apt upgrade' step happened already?

[unman]

I'd probably be rolling back most of your recent changes, and starting
again, after making sure that I have a decent backup of the qube in its
current state.
You need to roll back those packages, and -f should work for the
install. I have some old templates hanging about - if you can wait until
tomorrow I'll pull one and work through the process in the morning.

[qubes...@riseup.net]

Hi unman,

> I'd probably be rolling back most of your recent changes, and starting
> again, after making sure that I have a decent backup of the qube in its
> current state.
> You need to roll back those packages, and -f should work for the
> install. I have some old templates hanging about - if you can wait until
> tomorrow I'll pull one and work through the process in the morning.

thanks that is very kind, I'll wait until tomorrow then.

thank you!

[qubes...@riseup.net]

When creating a backup while the broken VM was still
running I noticed the text saying that the VM backup will contain
the VM's state before it booted, which was a perfect solution to revert
everything I did since the VM started.

This should solve my problem by restoring that newly created backup.

thank you anyway for your help!