Re: [opensuse-buildservice] Re: [opensuse-factory] Questions about osc
On 9/11/20 3:24 AM, Michal Kubecek wrote:
That's part of the kmp packaging macro magic, not much the kmp packager can do about it.
There is the possibility of doing crazy ugly hacks like
%define regenerate_initrd_posttrans /bin/true\ %{nil}
but a bug / feature request against kernel-macros package to give kmp packagers an easy and documented way to say "this module will not end up on initrd" would be better:-) But can you ever be sure that it definitely cannot end up in initrd? How do you e.g. prevent user from putting it into INITRD_MODULES explicitly? I'm afraid the only safe way would be a dracut feature that would let you check if it would put a module into initrd based on current configuration and dependencies.
In the VB case, the kmp install section had the following statements: export INITRD_IN_POSTTRANS=1 export KMP_NEEDS_MKINITRD=0 My tests show that inclusion in initrd stopped when these were removed. We will see what results Pete gets when the new version reaches TW. Larry -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Freitag, 11. September 2020, 16:51:19 CEST schrieb Larry Finger:
On 9/11/20 3:24 AM, Michal Kubecek wrote:
That's part of the kmp packaging macro magic, not much the kmp packager can do about it.
There is the possibility of doing crazy ugly hacks like
%define regenerate_initrd_posttrans /bin/true\ %{nil}
but a bug / feature request against kernel-macros package to give kmp packagers an easy and documented way to say "this module will not end up on initrd" would be better:-)
+1000
But can you ever be sure that it definitely cannot end up in initrd? How do you e.g. prevent user from putting it into INITRD_MODULES explicitly? I'm afraid the only safe way would be a dracut feature that would let you check if it would put a module into initrd based on current configuration and dependencies.
dracut would need to record checksums/timestamps of every item, and stop recreating a certain initrd, if items didn't changed, unless the operation is forced. Oh well.
In the VB case, the kmp install section had the following statements: export INITRD_IN_POSTTRANS=1 export KMP_NEEDS_MKINITRD=0 My tests show that inclusion in initrd stopped when these were removed. We will see what results Pete gets when the new version reaches TW.
Unfortunately, initrds are still rebuilt, Larry. Sorry. In addition, virtualbox fails to build for any Leaps now after Franck Bui's latest change: [ 3270s] ... testing for pre/postinstall scripts that are not idempotent [ 3271s] Failed to connect to bus: No such file or directory [ 3271s] Failed to connect to bus: No such file or directory [ 3271s] /.build_patchrpmcheck_scr: line 53: fg: no job control [ 3271s] postuninstall script of virtualbox-6.1.14-lp152.614.1.x86_64.rpm failed This is evoked from this changeset: -export DISABLE_RESTART_ON_UPDATE=yes -%service_del_postun vboxautostart.service -%service_del_postun vboxdrv.service +%service_del_postun_without_restart vboxautostart.service +%service_del_postun_without_restart vboxdrv.service Franck, while this is a pretty important fix, these macros aren't available on Leap. Would you add them for Leap builds, please? Cheers, Pete -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Fri, 2020-09-18 at 12:48 +0200, Hans-Peter Jansen wrote:
Am Freitag, 11. September 2020, 16:51:19 CEST schrieb Larry Finger:
On 9/11/20 3:24 AM, Michal Kubecek wrote:
That's part of the kmp packaging macro magic, not much the kmp packager can do about it.
There is the possibility of doing crazy ugly hacks like
%define regenerate_initrd_posttrans /bin/true\ %{nil}
but a bug / feature request against kernel-macros package to give kmp packagers an easy and documented way to say "this module will not end up on initrd" would be better:-)
+1000
There is an easy way, and it's actually documented, albeit not very prominently. You can use the "-t template" option of the %kernel_module_package macro. See section 6 of the kernel module packages manual. (https://drivers.suse.com/doc/kmpm/Kmpm-code11.pdf) Typically, you'd copy the default template /usr/lib/rpm/kernel-module- subpackage into your project as an additional source file, modify it to suit your needs, and feed it's path to the -t option. Regards, Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am Freitag, 18. September 2020, 14:49:45 CEST schrieb Martin Wilck:
On Fri, 2020-09-18 at 12:48 +0200, Hans-Peter Jansen wrote:
Am Freitag, 11. September 2020, 16:51:19 CEST schrieb Larry Finger:
On 9/11/20 3:24 AM, Michal Kubecek wrote:
That's part of the kmp packaging macro magic, not much the kmp packager can do about it.
There is the possibility of doing crazy ugly hacks like
%define regenerate_initrd_posttrans /bin/true\ %{nil}
but a bug / feature request against kernel-macros package to give kmp packagers an easy and documented way to say "this module will not end up on initrd" would be better:-)
+1000
There is an easy way, and it's actually documented, albeit not very prominently.
You can use the "-t template" option of the %kernel_module_package macro. See section 6 of the kernel module packages manual. (https://drivers.suse.com/doc/kmpm/Kmpm-code11.pdf)
Typically, you'd copy the default template /usr/lib/rpm/kernel-module- subpackage into your project as an additional source file, modify it to suit your needs, and feed it's path to the -t option.
Well, that's done for virtualbox already. Larry, during investigation, I noticed, that the spec yanks "^Provides: multiversion(kernel)" from /usr/lib/rpm/kernel-module-subpackage, do you remember the reasoning? I still remember a case, where I tried to switch back to an older kernel, which resulted in a dysfunctional VB, since the kmp is *replaced* with the newest build for the latest kernel. The idea of this tag is to support multiple kmp builds for several kernels, and VB shouldn't be excluded from this. Martin, if I read /usr/lib/rpm/kernel-module-subpackage (as of TW) correctly, it would suffice to supply "-b KMP_NEEDS_MKINITRD=0" to %kernel_module_package for suppressing the initrd regeneration. Am I right? Cheers, Pete -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Fri, 2020-09-18 at 16:23 +0200, Hans-Peter Jansen wrote:
Am Freitag, 18. September 2020, 14:49:45 CEST schrieb Martin Wilck:
There is an easy way, and it's actually documented, albeit not very prominently.
You can use the "-t template" option of the %kernel_module_package macro. See section 6 of the kernel module packages manual. (https://drivers.suse.com/doc/kmpm/Kmpm-code11.pdf)
Typically, you'd copy the default template /usr/lib/rpm/kernel- module- subpackage into your project as an additional source file, modify it to suit your needs, and feed it's path to the -t option.
Well, that's done for virtualbox already. Larry, during investigation, I noticed, that the spec yanks "^Provides: multiversion(kernel)" from /usr/lib/rpm/kernel-module-subpackage, do you remember the reasoning?
multiversion(kernel) for KMPs used to cause all sorts of headaches and subtle problems. IIRC these problems are solved with the kernel commit "KMPs: provide and conflict a kernel version specific KMP name", which avoids two different KMPs installed for the same kernel version, which causes the KMPs to have these dependencies: Provides: %{-n*}-kmp-%1-%_this_kmp_kernel_version Conflicts: %{-n*}-kmp-%1-%_this_kmp_kernel_version
I still remember a case, where I tried to switch back to an older kernel, which resulted in a dysfunctional VB, since the kmp is *replaced* with the newest build for the latest kernel. The idea of this tag is to support multiple kmp builds for several kernels, and VB shouldn't be excluded from this.
Martin, if I read /usr/lib/rpm/kernel-module-subpackage (as of TW) correctly, it would suffice to supply "-b KMP_NEEDS_MKINITRD=0" to %kernel_module_package for suppressing the initrd regeneration. Am I right?
No, -b *forces* creation of the initrd, and KMP_NEEDS_MKINITRD=0 means nothing (it's equivalent to KMP_NEEDS_MKINITRD not existing). If you don't use this, and don't set KMP_NEEDS_MKINITRD=1, then weak-modules2 would look whether any modules from your KMP are contained in the current initrd, and schedule a mkinitrd run only if that was the case. Perhaps that's your problem? If not, it might make sense to debug what weak-modules2 is doing, like this: /usr/lib/module-init-tools/weak-modules2 --verbose --add-kmp %{name}-%{version}-%{release} Regards Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (3)
-
Hans-Peter Jansen -
Larry Finger -
Martin Wilck