[opensuse-factory] Questions about osc
A few weeks ago, the virtualbox project was split into two parts - one to build the main packages, and the other to build the kernel modules. I then issued a linkpac command to link them. Shortly after this change was published, it was suggested a multibuild approach would be better, and that was done. All is working mostly OK; however, I have two questions: A standard osc build command works fine, but the kernel modules are not built. OBS does what is expected; however, I would like to save some load on OBS by verifying that the modules will build correctly before uploading changes. What osc build options should I use to build that part of the project? The second question is how to remove the now-dead link to a kmp sub-project? That will save roughly 50% of the OBS build time. Thanks, Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2020-09-08 17:47, Larry Finger wrote:
A standard osc build command works fine, but the kernel modules are not built. OBS does what is expected; however, I would like to save some load on OBS by verifying that the modules will build correctly before uploading changes. What osc build options should I use to build that part of the project?
osc build -M -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/8/20 10:52 AM, Jan Engelhardt wrote:
On Tuesday 2020-09-08 17:47, Larry Finger wrote:
A standard osc build command works fine, but the kernel modules are not built. OBS does what is expected; however, I would like to save some load on OBS by verifying that the modules will build correctly before uploading changes. What osc build options should I use to build that part of the project?
osc build -M
Thanks. I read the osc build help several times and missed that option every time! Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Dienstag, 8. September 2020, 17:47:10 CEST schrieb Larry Finger:
A few weeks ago, the virtualbox project was split into two parts - one to build the main packages, and the other to build the kernel modules. I then issued a linkpac command to link them. Shortly after this change was published, it was suggested a multibuild approach would be better, and that was done. All is working mostly OK; however, I have two questions:
A standard osc build command works fine, but the kernel modules are not built. OBS does what is expected; however, I would like to save some load on OBS by verifying that the modules will build correctly before uploading changes. What osc build options should I use to build that part of the project?
The second question is how to remove the now-dead link to a kmp sub-project? That will save roughly 50% of the OBS build time.
Can't halp you with your questions, sorry, but this reminds me of something, that I wanted to ask: for what reason does the kmp package rebuild the initrd? Usually, the initrd contains only those modules, that are essential for initial boot setup, eg. everything, that is needed to mount and switch over to the real root. The virtualbox host kmp doesn't do anything in this respect, does it? Omitting the initrd rebuilds would speed up VB updates considerably.. Thanks, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 08.09.20 um 18:36 schrieb Hans-Peter Jansen:
Can't halp you with your questions, sorry, but this reminds me of something, that I wanted to ask: for what reason does the kmp package rebuild the initrd?
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 :-)
Usually, the initrd contains only those modules, that are essential for initial boot setup, eg. everything, that is needed to mount and switch over to the real root. The virtualbox host kmp doesn't do anything in this respect, does it?
Omitting the initrd rebuilds would speed up VB updates considerably..
90% of the KMP modules would benefit from such a feature ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
09.09.2020 12:33, Stefan Seyfried пишет:
Am 08.09.20 um 18:36 schrieb Hans-Peter Jansen:
Can't halp you with your questions, sorry, but this reminds me of something, that I wanted to ask: for what reason does the kmp package rebuild the initrd?
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}
IIRC installation of VB KMP regenerated initrd immediately, not in posttrans.
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 :-)
Usually, the initrd contains only those modules, that are essential for initial boot setup, eg. everything, that is needed to mount and switch over to the real root. The virtualbox host kmp doesn't do anything in this respect, does it?
Omitting the initrd rebuilds would speed up VB updates considerably..
90% of the KMP modules would benefit from such a feature ;-)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Sep 09, 2020 at 11:33:18AM +0200, Stefan Seyfried wrote:
Am 08.09.20 um 18:36 schrieb Hans-Peter Jansen:
Can't halp you with your questions, sorry, but this reminds me of something, that I wanted to ask: for what reason does the kmp package rebuild the initrd?
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. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/18/20 12:48 PM, Hans-Peter Jansen wrote:
-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?
Yes it's underway now, see https://build.suse.de/request/show/226290. The request has been accepted so it shouldn't take long but if this can't wait feel free to revert my changes, I'll resubmit them later. Sorry for the inconvenience. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Freitag, 18. September 2020, 13:19:09 CEST schrieb Franck Bui:
On 9/18/20 12:48 PM, Hans-Peter Jansen wrote:
-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?
Yes it's underway now, see https://build.suse.de/request/show/226290.
Not accessible from here. Does this fix permeated into openSUSE somewhere?
The request has been accepted so it shouldn't take long but if this can't wait feel free to revert my changes, I'll resubmit them later.
Hey, we are here at work and not on the run, aren't we?
Sorry for the inconvenience.
To the contrary, thanks for the fix, Franck. Much appreciated. Have a nice weekend guys, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/18/20 9:04 AM, Hans-Peter Jansen wrote:
Am Freitag, 18. September 2020, 13:19:09 CEST schrieb Franck Bui:
On 9/18/20 12:48 PM, Hans-Peter Jansen wrote:
-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?
Yes it's underway now, see https://build.suse.de/request/show/226290.
Not accessible from here. Does this fix permeated into openSUSE somewhere?
The request has been accepted so it shouldn't take long but if this can't wait feel free to revert my changes, I'll resubmit them later.
Hey, we are here at work and not on the run, aren't we?
Sorry for the inconvenience.
To the contrary, thanks for the fix, Franck. Much appreciated.
Pete and Frank, I just uploaded a change that uses %service_del_postun_without_restart if it is available, and reverts to the old way if not. That way, the builds will transition as the new macro becomes available on Leap and SLE15_SP1. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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
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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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
participants (8)
-
Andrei Borzenkov -
Franck Bui -
Hans-Peter Jansen -
Jan Engelhardt -
Larry Finger -
Martin Wilck -
Michal Kubecek -
Stefan Seyfried