Comment # 8 on bug 1189590 from Fabian Vogt

(In reply to Fabian Vogt from comment #7)
> What I noticed is that sometimes it uses
> /var/cache/zypp/solv/openSUSE-1-0/solv and sometimes
> /mnt/var/cache/zypp/solv/openSUSE-1-0/solv.
> 
> This looks odd too, and probably reinforces comment 5:
> 
> 2021-08-19 09:56:37 <1> install(3874) [Pkg]
> Source_Load.cc(SourceLoadImpl):452 Resolvables from 'openSUSE-1-0' are
> already present, not loading
> 2021-08-19 09:56:37 <1> install(3874) [Pkg]
> Source_Resolvables.cc(LoadResolvablesFrom):67 Loading resolvables from
> 'openSUSE-1-0', pool size at start: 5936
> 2021-08-19 09:56:37 <1> install(3874) [zypp]
> Repository.cc(eraseFromPool):300 sat::repo(openSUSE-1-0){prio -99.2, size
> 3773} removed from pool
> 2021-08-19 09:56:37 <1> install(3874) [zypp::satpool]
> PoolImpl.cc(setDirty):253 _deleteRepo openSUSE-1-0
> 2021-08-19 09:56:37 <1> install(3874) [zypp::satpool]
> PoolImpl.cc(setDirty):253 _createRepo openSUSE-1-0
> 2021-08-19 09:56:37 <1> install(3874) [zypp::satpool]
> PoolImpl.cc(setDirty):253 _addSolv openSUSE-1-0
> 
> It probably gets confused because the installation medium results in a repo
> called "openSUSE-1-0" and the to be upgraded system also contains
> /mnt/etc/zypp/repos.d/openSUSE-1-0.repo.
> 
> This would explain why it only causes issues in staging, where the version
> number is always "1-0".

I just realized that this isn't accurate, and caused by my method of local
testing. After reproducing the issue, I did not rollback the source .qcow2 to
its original state, but YaST actually writes into the target system's zypp conf
at the installation overview, even before the upgrade starts. That changed the
behaviour of the following tests, which then had only the openSUSE-1-0 repo in
the target system. Originally, the target system does not have any
"openSUSE-1-0" repo, but it's added when computing the upgrade. In that
scenario
I also got the crash again instead of the broken calculated upgrade.

This means my theory about why it only seems to fail in stagings is invalid,
it affects hit all upgrades. It does still confirm that there is some confusion
with repos and caches from the inst-sys and the target system.