[Bug 1206042] New: [Build 20221204] zdup from 15.4 to Tumbleweed falls on removing 15.4 kernel
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 Bug ID: 1206042 Summary: [Build 20221204] zdup from 15.4 to Tumbleweed falls on removing 15.4 kernel Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/2929149/modules/zdup /steps/166 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: dimstar@opensuse.org QA Contact: qa-bugs@suse.de Found By: openQA Blocker: Yes ## Observation (1580/2514) Removing kernel-default-optional-5.14.21-150400.22.1.x86_64 [...[ 580.054161] [RPM][8690]: Transaction ID 638df844 started [ 580.120327] [RPM][8690]: erase kernel-default-optional-5.14.21-150400.22.1.x86_64: success /var/tmp/rpm-tmp.RH7ho2: line 1: /usr/lib/module-init-tools/kernel-scriptlets/inkmp-preun: No such file or directory [ 580.131156] [RPM][8690]: scriptlet %preun(kernel-default-optional-5.14.21-150400.22.1.x86_64) failure: 2 [ 580.132144] [RPM][8690]: erase kernel-default-optional-5.14.21-150400.22.1.x86_64: failure [ 580.132880] [RPM][8690]: 1 elements failed, 1 scripts failed Upgrades from 15.3 to TW do not have this problem openQA test in scenario opensuse-Tumbleweed-NET-x86_64-zdup-Leap-15.4-gnome@64bit fails in [zdup](https://openqa.opensuse.org/tests/2929149/modules/zdup/steps/166) ## Test suite description ## Reproducible Fails since (at least) Build [20221204](https://openqa.opensuse.org/tests/2929000) ## Expected result Last good: (unknown) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=NET&machine=64bit&test=zdup-Leap-15.4-gnome&version=Tumbleweed) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 Dominique Leuenberger <dimstar@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel |Kernel Version|Current |Leap 15.4 Product|openSUSE Tumbleweed |openSUSE Distribution -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c1 Dominique Leuenberger <dimstar@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.wilck@suse.com --- Comment #1 from Dominique Leuenberger <dimstar@opensuse.org> --- Martins change from https://build.opensuse.org/request/show/1038933#tab-pane-changes is possibly related -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c2 --- Comment #2 from Dominique Leuenberger <dimstar@opensuse.org> --- The tumbleweed kernel guards the scripts with run_if_exists, which is not done in the 15.4 kernel (yet) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c3 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com --- Comment #3 from Takashi Iwai <tiwai@suse.com> --- (In reply to Dominique Leuenberger from comment #2)
The tumbleweed kernel guards the scripts with run_if_exists, which is not done in the 15.4 kernel (yet)
Right, this is a fallout of commit ab8dd2da7f85757e683150af604f388b64e64c46, as the kernel-*-optional handling is SLE15-SPx specific. I'm going to fix it up for the next MU. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c4 --- Comment #4 from Takashi Iwai <tiwai@suse.com> --- Looking at the changes again, the current SLE15-SP4 kernel already contains the right fix with %run__if_exists prefix for */inkmp-preun calls. I believe that the problem is rather it's the old Leap15.4/SLE15-SP4 GM kernel (5.14.21-150400.22.1) that doesn't have the fix. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c5 Lubos Kocman <lubos.kocman@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lubos.kocman@suse.com --- Comment #5 from Lubos Kocman <lubos.kocman@suse.com> --- So recommendation would be to update && reboot prior to the upgrade right? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c6 --- Comment #6 from Takashi Iwai <tiwai@suse.com> --- The problem is indeed due to the split of suse-module-tools-scriptlets, I guess. It seems that suse-module-tools is updated (but *-scriptlets isn't yet), then kernel-default-* is updated. It appears to be some missing dependency in suse-module-tools-scriptlets. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c7 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@suse.com --- Comment #7 from Martin Wilck <martin.wilck@suse.com> --- What dependency would be missing here? The TW kernel "Requires(pre): suse-kernel-rpm-scriptlets". The problem is IMO that zdup uninstalls the kernel-default-optional before it pulls in the new kernel (and thus, suse-module-tools-scriptlets).
$ egrep 'suse-mod|kernel-def' /tmp/zdup-journal.log Dec 05 08:51:29.774682 susetest [RPM][4378]: erase suse-module-tools-15.4.12-150400.1.4.x86_64: success Dec 05 08:51:30.533447 susetest [RPM][4378]: install suse-module-tools-6.0.28-1.1.x86_64: success Dec 05 08:51:31.272031 susetest [RPM][4378]: erase suse-module-tools-15.4.12-150400.1.4.x86_64: success Dec 05 08:55:16.481755 susetest [RPM][8687]: erase kernel-default-optional-5.14.21-150400.24.33.2.x86_64: success Dec 05 08:55:16.618869 susetest [RPM][8687]: erase kernel-default-optional-5.14.21-150400.24.33.2.x86_64: success Dec 05 08:55:16.904701 susetest [RPM][8690]: erase kernel-default-optional-5.14.21-150400.22.1.x86_64: success Dec 05 08:55:16.915267 susetest [RPM][8690]: scriptlet %preun(kernel-default-optional-5.14.21-150400.22.1.x86_64) failure: 2 Dec 05 08:55:16.915287 susetest [RPM][8690]: erase kernel-default-optional-5.14.21-150400.22.1.x86_64: failure
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c8 --- Comment #8 from Martin Wilck <martin.wilck@suse.com> --- Note that erasing kernel-default-optional-5.14.21-150400.24.33.2 worked but erasing kernel-default-optional-5.14.21-150400.22.1.x86_64 does not. This is because the update kernel has the run_if_exists, whereas the GA kernel does not. So it'd be sufficient to uninstall the GA kernel first before doing the zypper dup. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c9 --- Comment #9 from Dominique Leuenberger <dimstar@opensuse.org> --- (In reply to Martin Wilck from comment #8)
Note that erasing kernel-default-optional-5.14.21-150400.24.33.2 worked but erasing kernel-default-optional-5.14.21-150400.22.1.x86_64 does not.
Ui - fun.... kernel is a multiversion() package - and as the disk image is newly generated and updated, we seem to have two kernels present for openQA I can probably 'fix' that test by providing a disk image that does not have the old kernel installed anymore, but users might actually run into this at any time -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c10 --- Comment #10 from Takashi Iwai <tiwai@suse.com> --- (In reply to Martin Wilck from comment #8)
Note that erasing kernel-default-optional-5.14.21-150400.24.33.2 worked but erasing kernel-default-optional-5.14.21-150400.22.1.x86_64 does not.
This is because the update kernel has the run_if_exists, whereas the GA kernel does not.
Oh right, somehow I messed up the git history and wrongly thought it's been already included.
So it'd be sufficient to uninstall the GA kernel first before doing the zypper dup.
The migration should be done without multiversion, and that'll suffice? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c11 --- Comment #11 from Ludwig Nussel <lnussel@suse.com> --- what if we added a "Conflicts: kernel < [whatever version introduced run_if_exists]" to suse-module-tools in Factory? Would that force uninstall the old kernel first? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c12 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ma@suse.com Flags| |needinfo?(ma@suse.com) --- Comment #12 from Martin Wilck <martin.wilck@suse.com> --- Michael, can you answer comment 11, or provide another suggestion? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c13 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ma@suse.com) | --- Comment #13 from Michael Andres <ma@suse.com> --- In ordinary installs (except dup) 'Conflict' raises a problem report and the user has to resolve it. It's interactive. In `dup` the package might be removed silently IFF the package is orphaned. I.e. 'kernel < [whatever version introduced run_if_exists]' packages are not available in any repo. Otherwise it's interactive like above. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c14 --- Comment #14 from Martin Wilck <martin.wilck@suse.com> --- So there's no user-friendly solution? I think a "conflicts" is difficult here, as we're looking at a leap->factory update. Having "conflicts: kernel < 5.14.21-150400.24" would mean a conflict not only with the SLE15-SP4 GA kernel, but with *every* SLE15-SP3 and older kernel, do we want that? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c15 --- Comment #15 from Martin Wilck <martin.wilck@suse.com> --- (In reply to Michael Andres from comment #13) I misread your comment, sorry.
In `dup` the package might be removed silently IFF the package is orphaned. I.e. 'kernel < [whatever version introduced run_if_exists]' packages are not available in any repo. Otherwise it's interactive like above.
In view of comment 7, the question is in which order this would happen. If the "silent remove" deterministically happens early on (before upgrading suse-module-tools), we'd be fine. Otherwise, we'd run into the same error. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1206042 http://bugzilla.opensuse.org/show_bug.cgi?id=1206042#c16 --- Comment #16 from Michael Andres <ma@suse.com> --- (In reply to Martin Wilck from comment #14)
update. Having "conflicts: kernel < 5.14.21-150400.24" would mean a conflict not only with the SLE15-SP4 GA kernel, but with *every* SLE15-SP3 and older
If there is a significant provides indicating that the run_if_exists is included, a conflict against this would hit only the kernel versions that provide it.
If the "silent remove" deterministically happens early on (before upgrading suse-module-tools)
Well, this very much depends on package dependencies. The package is not removed as long as installed packages require it (e.g. for their %postun). You can just tell how long the solver tries to keep this package. Cyclic dependencies which need to be broken up may cause an earlier deletion. A later deletion is always possible. A somewhat deterministic point of deletion is just given for obsoletes. An obsoleted package is treated as an old (not multiversion) version. When installing the new package rpm itself removes the old (and obsoleted) ones. ----- What you could try if it must happen `before upgrading suse-module-tools`: - let the new suse-module-tools pre-require `( suse-module-tools-cleanup if kernel < [whatever....] ). - create suse-module-tools-cleanup as a task package which just obsoletes the 'kernel < [whatever....' caused it's installation. As a pre-requires the solver will always try to keep it before suse-module-tools. Unless you have really ugly dependency cycles, this should do. Question is how to get rid of suse-module-tools-cleanup again. You have to try out or ask Michael Schr�der (mls) whether this works within the same transaction: a) suse-module-tools could immediately obsolete suse-module-tools-cleanup again. b) suse-module-tools-cleanup could provide `libsolv-self-destruct-pkg()`. By this the package requests it's own removal immediately after having been installed. In case this works, ask mls whether libsolv-self-destruct-pkg() is mature enough to be use in production code. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com