http://bugzilla.suse.com/show_bug.cgi?id=1041443
Bug ID: 1041443 Summary: Raspberry Pi 3: zypper unclear conflict resolution problem message Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers@forge.provo.novell.com Reporter: jeroen.forums.opensuse.org@pluimers.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: ---
Created attachment 726808 --> http://bugzilla.suse.com/attachment.cgi?id=726808&action=edit part of zypper.solverTestCase files
# Steps leading into this
1. Install Tumbleweed on Raspberry Pi 3 from https://web.archive.org/web/20170526140155/http://download.opensuse.org/repo... 2. On 20170525 perform `zypper --versbose refresh --force` and `zypper dist-upgrade` 3. On 20170528 perform `zypper dist-upgrade --no-allow-vendor-change`
Expected: succeed
Actual:
``` # zypper dist-upgrade --no-allow-vendor-change Loading repository data... Reading installed packages... Computing distribution upgrade...
Problem: problem with installed package kernel-default-4.4.68-7.1.aarch64 Solution 1: keep obsolete kernel-default-4.4.68-7.1.aarch64
Choose the above solution using '1' or cancel using 'c' [1/c] (c): ```
Two important points:
1. Basically both the 1 and c will abort the upgrade so there is no way to perform `--no-allow-vendor-change` upgrades any more.
2. The reason for the "problem" is not revealed so it is unclear to get out of 1.
Details: https://gist.github.com/jpluimers/a9ed0802d4314ba3bd662663c2b219a9 which has all the zypper.solverTestCase files
http://bugzilla.suse.com/show_bug.cgi?id=1041443 http://bugzilla.suse.com/show_bug.cgi?id=1041443#c1
--- Comment #1 from Jeroen Pluimers jeroen.forums.opensuse.org@pluimers.com --- Created attachment 726809 --> http://bugzilla.suse.com/attachment.cgi?id=726809&action=edit part of zypper.solverTestCase files
http://bugzilla.suse.com/show_bug.cgi?id=1041443 http://bugzilla.suse.com/show_bug.cgi?id=1041443#c2
--- Comment #2 from Jeroen Pluimers jeroen.forums.opensuse.org@pluimers.com --- Created attachment 726810 --> http://bugzilla.suse.com/attachment.cgi?id=726810&action=edit part of zypper.solverTestCase files
http://bugzilla.suse.com/show_bug.cgi?id=1041443 http://bugzilla.suse.com/show_bug.cgi?id=1041443#c3
--- Comment #3 from Jeroen Pluimers jeroen.forums.opensuse.org@pluimers.com --- Created attachment 726812 --> http://bugzilla.suse.com/attachment.cgi?id=726812&action=edit part of zypper.solverTestCase files
http://bugzilla.suse.com/show_bug.cgi?id=1041443
Michael Andres ma@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED
http://bugzilla.suse.com/show_bug.cgi?id=1041443 http://bugzilla.suse.com/show_bug.cgi?id=1041443#c4
--- Comment #4 from Michael Andres ma@suse.com ---
kernel-default-4.11.1-1.1.aarch64 openSUSE-Ports-Tumbleweed-repo-oss vendor(openSUSE) kernel-default-4.11.1-1.1.aarch64 @System vendor(openSUSE) kernel-default-4.4.68-7.1.aarch64 @System vendor(obs://build.opensuse.org/devel:ARM)
(In reply to Jeroen Pluimers from comment #0)
- Basically both the 1 and c will abort the upgrade so there is no way to
perform `--no-allow-vendor-change` upgrades any more.
That's not true.
The conflict somehow tries to tell that there is no way to update kernel-default-4.4.68-7.1. The available update (4.11.1) would cause a vendor change, OTOH is this update already installed. We'll try to improve those messages.
Anyway, if you select '1' the dup proceeds. It's just that your system is already up-to-date, so there is actually nothing more to do. That's why it probably looks like it's doing the same as 'cancel'.
http://bugzilla.suse.com/show_bug.cgi?id=1041443 http://bugzilla.suse.com/show_bug.cgi?id=1041443#c5
--- Comment #5 from Jeroen Pluimers jeroen.forums.opensuse.org@pluimers.com --- Thanks for indicating my presumption was incorrect. However, this raises two more questions:
1. why does a plain `zypper dist-upgrade` indicate nothing should be done?
I just re-checked:
``` # zypper dist-upgrade Loading repository data... Reading installed packages... Computing distribution upgrade...
Nothing to do. ```
2. where did you get the list of kernels from?
You were definitely right about `1` and `c` giving different results as the exit code differs (which I didn't notice as I was confused both gave the same output):
``` # zypper dist-upgrade --no-allow-vendor-change ; echo $? Loading repository data... Reading installed packages... Computing distribution upgrade...
Problem: problem with installed package kernel-default-4.4.68-7.1.aarch64 Solution 1: keep obsolete kernel-default-4.4.68-7.1.aarch64
Choose the above solution using '1' or cancel using 'c' [1/c] (c): 1 Resolving dependencies... Computing distribution upgrade...
Nothing to do. 0 # zypper dist-upgrade --no-allow-vendor-change ; echo $? Loading repository data... Reading installed packages... Computing distribution upgrade...
Problem: problem with installed package kernel-default-4.4.68-7.1.aarch64 Solution 1: keep obsolete kernel-default-4.4.68-7.1.aarch64
Choose the above solution using '1' or cancel using 'c' [1/c] (c): c 4 ```
Thanks also for "We'll try to improve those messages." as the current ones definitely confuse me.
http://bugzilla.suse.com/show_bug.cgi?id=1041443 http://bugzilla.suse.com/show_bug.cgi?id=1041443#c6
--- Comment #6 from Michael Andres ma@suse.com --- (In reply to Jeroen Pluimers from comment #5)
- why does a plain `zypper dist-upgrade` indicate nothing should be done?
I just re-checked:
# zypper dist-upgrade Loading repository data... Reading installed packages... Computing distribution upgrade... Nothing to do.
It's due to the way the resolver operates. The 'job' is to make sure the kernel-default-4.11.1 is installed. As this is already true, both calls will perform no action. As 'dist-upgrade' per default allows vendor changes, the solver does not see any policy violation here.
When performing 'dist-upgrade --no-allow-vendor-change' the resolver sees a policy violation, as the vendor changes from 'obs://build.opensuse.org/devel:ARM' to 'openSUSE'.
It smells a bit like a false-alarm, because the package is already installed and no action needs to be performed. But I'll have to discuss this with the solver experts first.
- where did you get the list of kernels from?
You attached the solver-testcase. It contains all information that's needed to replay (and debug) the transaction locally.
This includes the dependency information of all packages installed (solver-system.xml) and available in repos (*-package.xml); also the resolver settings and the job you executed (solver-test.xml).
http://bugzilla.suse.com/show_bug.cgi?id=1041443 http://bugzilla.suse.com/show_bug.cgi?id=1041443#c7
Michael Schröder mls@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mls@suse.com
--- Comment #7 from Michael Schröder mls@suse.com --- I can somewhat explain the behavior: dist-upgrade makes sure that all of the installed packages come from the configured repositories. There's a bit of special handling for "multiversion" packages like the kernel, though.
With vendor changing allowed, the solver sees that kernel-default-4.4.68 is old and not in a repository, but there's a newer version available and the installed version can upgrade to it. So it forces the update, which is a no-op in your case because it is already installed. The old 4.4.68 kernel is considered "orphaned", i.e. the solver will deinstall it if it gets in the way, but it does not mind that it stays installed.
With vendor changing disabled, the solver does not have an valid update available for the old kernel. But there is a kernel with a different vendor. So it does not know what to do. The solution part is missing a "deinstall obsolete kernel" option, though.
The "distupgrade with restrictions" mode needs some more work, I admit. ;)
http://bugzilla.suse.com/show_bug.cgi?id=1041443 http://bugzilla.suse.com/show_bug.cgi?id=1041443#c8
--- Comment #8 from Jeroen Pluimers jeroen.forums.opensuse.org@pluimers.com --- Thanks all for the comments: I've learned a lot (:
To summarise:
- kernel-default 4.4.68-7.1 (old) was installed from @System - kernel-default 4.11.1-1.1 (current) was installed from openSUSE-Ports-Tumbleweed-repo-oss - both are from a different vendor - --no-allow-vendor-change dislikes the vendor difference and doesn't know what to do with kernel-default 4.4.68-7.1, but in the message forgets to tell there also is kernel-default 4.11.1-1.1 which is current - without --no-allow-vendor-change there is no problem: it allows the vendor difference
Aren't @System and openSUSE-Ports-Tumbleweed-repo-oss are effectively the same? If so: shouldn't the solver treat them like that?
For my own reference so I can query this stuff myself in the future:
# zypper packages --installed-only --sort-by-name | grep -e "kernel" i+ | @System | kernel-default | 4.4.68-7.1 | aarch64 i+ | openSUSE-Ports-Tumbleweed-repo-oss | kernel-default | 4.11.1-1.1 | aarch64 i+ | openSUSE-Ports-Tumbleweed-repo-oss | kernel-firmware | 20170511-1.1 | noarch
# zypper search --details kernel-default Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+----------------------+---------+------------+---------+----------------------------------- i+ | kernel-default | package | 4.4.68-7.1 | aarch64 | (System Packages) i+ | kernel-default | package | 4.11.1-1.1 | aarch64 | openSUSE-Ports-Tumbleweed-repo-oss | kernel-default-base | package | 4.11.1-1.1 | aarch64 | openSUSE-Ports-Tumbleweed-repo-oss | kernel-default-devel | package | 4.11.1-1.1 | aarch64 | openSUSE-Ports-Tumbleweed-repo-oss
https://forums.opensuse.org/showthread.php/500993-How-to-check-which-reposit... https://en.opensuse.org/SDB:Zypper_manual_(plain)
http://bugzilla.suse.com/show_bug.cgi?id=1041443 http://bugzilla.suse.com/show_bug.cgi?id=1041443#c9
--- Comment #9 from Michael Andres ma@suse.com --- (In reply to Jeroen Pluimers from comment #8)
Aren't @System and openSUSE-Ports-Tumbleweed-repo-oss are effectively the same? If so: shouldn't the solver treat them like that?
Please keep in mind that the list in comment#4 was just debug output. There '@System' simply indicates that the package is installed. The installed kernel-default-4.11.1 is in fact the same package as provided by openSUSE-Ports-Tumbleweed-repo-oss.
That's why zypper displays 'openSUSE-Ports-Tumbleweed-repo-oss' for the installed 4.11.1, but @System or (System Packages) for the installed 4.4.68. This means we don't know where 4.4.68 comes from, because none of the known repositories provides it. You probably disabled or removed the 'devel:ARM' repo.
http://bugzilla.suse.com/show_bug.cgi?id=1041443 http://bugzilla.suse.com/show_bug.cgi?id=1041443#c10
--- Comment #10 from Jeroen Pluimers jeroen.forums.opensuse.org@pluimers.com --- I am definitely sure I did not fiddle with the repository definitions, so 'devel:ARM' was untouched.
https://bugzilla.suse.com/show_bug.cgi?id=1041443 https://bugzilla.suse.com/show_bug.cgi?id=1041443#c11
Andreas Artz andide.linux@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED CC| |andide.linux@gmail.com Resolution|--- |WONTFIX
--- Comment #11 from Andreas Artz andide.linux@gmail.com --- closed due date
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com