Bugzilla – Bug 1192014
provide admin option to NOT automatically REbuild initrds for previously installed kernels
Last modified: 2024-05-31 20:30:03 UTC
Initial Summary: provide admin option to NOT automatically REbuild initrds for previously installed kernels From bug 1189772, where this request has already had some discussion about how it might be implemented: [quote] > (In reply to Martin Wilck from comment #7) >> (In reply to Felix Miata from comment #6) >> IMO, openSUSE should also have an admin option not to rebuild, regardless of >> use case. What I do on openSUSE is set immutable flag on initrds. It doesn't >> stop the rebuild waste of CPU cycles and SSD writes, but I get the result I >> want. > Fair enough. Please open a feature request. [/quote]: On Debians there's been this to implement admin preference since forever: # cat /etc/initramfs-tools/update-initramfs.conf # # Configuration file for update-initramfs(8) # # # update_initramfs [ yes | all | no ] # # Default is yes # If set to all update-initramfs will update all initramfs # If set to no disables any update to initramfs beside kernel upgrade update_initramfs=no # # backup_initramfs [ yes | no ] # # Default is no # If set to no leaves no .bak backup files. backup_initramfs=no
Trying to move this forward from the dracut side: https://github.com/dracutdevs/dracut/pull/1950
Upstream wontfixed 1950, says it's not the job of dracut to determine when or whether to regenerate.
(In reply to Felix Miata from comment #2) > Upstream wontfixed 1950, says it's not the job of dracut to determine when > or whether to regenerate. Yes, unfortunately this won't be fixed by dracut, so I'll close this report accordingly. Anyway, if you are still interested in solving this, you can discuss this topic on the Factory mailing list. Thanks.
So dracut team won't fix via dracut. That's reason to reassign enhancement request elsewhere, not close. Packaging scripts or whatever Debian has been doing for eons ought to be able to do something. Martin, any suggestions? Initrds are getting built much too often. With Leap 15.3+ and NVidia GPUs both kernel-default and kernel-default-extra are needed for FOSS graphics drivers. Installing a new pair: # zypper -v in kernel-default kernel-default-extra (or rpm -iv rather than zypper in) 1-installs kernel-default 2-builds (incomplete) initrd 3-installs kernel-default-extra 4-builds (complete) initrd #
(In reply to Felix Miata from comment #4) > So dracut team won't fix via dracut. That's reason to reassign enhancement > request elsewhere, not close. Packaging scripts or whatever Debian has been > doing for eons ought to be able to do something. Martin, any suggestions? > > Initrds are getting built much too often. With Leap 15.3+ and NVidia GPUs > both kernel-default and kernel-default-extra are needed for FOSS graphics > drivers. Installing a new pair: I agree this is a pain. The idea to rebuild initrds in posttrans has existed for more than a year, but I haven't had time for it. But it won't change in 15.3. If you use 15.4, it will be much faster already because of zstd compression support.
This is reported against Tumbleweed so anything goes. If somebody has an idea how to do this in a sound way I suppose it could be done. There is a tradeoff between being conservative and using whatever worked before and including fixed tools in the ramdisks. I suppose if it's configurable people can do one or the other and won't complain too much.
In Tumbleweed, it is now possible to set INIRD_IN_POSTRANS=1 in the environment (either from the calling shell, in /etc/environment, or whatever). If this is set together with ZYPP_SINGLE_RPMTRANS=1, the initrd is only rebuilt once in the %posttrans stage. The same code will be in SLE15-SP6 and (with the forthcoming MU, probably in October) in SLE15-SP5 / Leap 15.5. I realize that this is most urgently needed under Leap, where we have the -extra and -optional packages. Note that ZYPP_SINGLE_RPMTRANS=1 is still not an officially supported feature.
Felix, does the workaround mentioned in comment 7 suit your needs?
As noted in https://bugzilla.opensuse.org/show_bug.cgi?id=1195291#c23 I have to say yes, though I have collected a backlog of Leap kernel upgrades pending knowledge of final 15.4 kernel version.
Closing per comment 9. Recommended workaround: # cat >>/etc/environment <<EOF ZYPP_SINGLE_RPMTRANS=1 INITRD_IN_POSTTRANS=1 EOF
Actually, I have yet to apply that workaround to TW. It has only occasionally been a TW problem, since I keep initrds immutable. The problem is special to Leap installations with NVidia graphics due to the nouveau module living in kernel-default-extra. I probably wrote this as a TW bug because enhancements normally get exposed first via TW.
On further thought, the workaround applies to a different problem. It does not prevent destruction of existing initrds or correlate to Debian's update_initramfs=no. The workaround only does what it purports to do: prevents multiple initrd builds for the same kernel as a consequence of a single rpm or zypper command.
Right, this is much less important on TW, because TW doesn't have the split kernel packages -extra and -optional. It only matters if kernel updates are carried out in the same transaction with other packages that would trigger an initrd rebuild.
Closing again. Please reopen (only) if you have concrete evidence that this bug isn't solved with the workaround from comment 10.
Created attachment 871638 [details] session transcript - running pre-zypper dup script that is routine here Looks like absent immutable flags on existing initrds, this transaction series would have described exactly what comment #0 asked to have avoided - reconstructing initrds for previously installed kernels. Is this the proof requested to support reopening, or does this have to be repeated on a more recently upgraded TW installation?
Sorry, I confused the bugs. This one is of course not solved with INITRD_IN_POSTTRANS. You basically want to avoid rebuilding the initrd completely. Antonio's upstream attempt has been rejected, so we have to implement this in regenerate-initrd-posttrans. I've created a test build that does skips calling dracut if the environment variable SKIP_REGENERATE_INITRD_ALL is set to "1". https://download.opensuse.org/repositories/home:/mwilck:/suse-module-tools/openSUSE_Factory https://download.opensuse.org/repositories/home:/mwilck:/suse-module-tools/15.5 Please provide feedback.
Any updates?
Leap hasn't had new kernels since 5 weeks ago.
This change isn't for new kernels but for other packages that update the initrd.
In doing updates to TW and 15.5 since the 55.39 kernel showed up several days ago, I haven't noticed anything unexpected. However, my policy of immutable initrds seems likely to be limiting opportunities for possible problems to appear. I only just remembered to enable your suse-module-tools. Luckily I have more do more to do than I have already done. It's not clear to me at this time whether it's OK to have both INITRD_IN_POSTTRANS=1 and SKIP_REGENERATE_INITRD_ALL=1 in /etc/environment for properly testing this, or better having only SKIP_REGENERATE_INITRD_ALL=1?
(In reply to Felix Miata from comment #20) > In doing updates to TW and 15.5 since the 55.39 kernel showed up several > days ago, I haven't noticed anything unexpected. However, my policy of > immutable initrds seems likely to be limiting opportunities for possible > problems to appear. Rather not. This setup is rather unusual (although I admit that it makes sense to me). It won't be tested by OpenQA or any other standard QA procedure. Therefore you are likely to hit issues that noone else sees. With SKIP_REGENERATE_INITRD_ALL=1, you shouldn't need to set your initrds immutable any more, because the system shouldn't even try to rebuild them. Inform me if you see errors from dracut trying to modify an immutable initrd and failing. > It's not clear to me at this time whether it's OK to have both > INITRD_IN_POSTTRANS=1 and SKIP_REGENERATE_INITRD_ALL=1 in /etc/environment > for properly testing this, or better having only > SKIP_REGENERATE_INITRD_ALL=1? Yes, it's ok. SKIP_REGENERATE_INITRD_ALL affects only packages that rebuild *all* initrds, i.e. user space packages like mdadm. For those, INITRD_IN_POSTTRANS has obviously no effect any more if SKIP_REGENERATE_INITRD_ALL is set, because if no initrd is build, the time at which it does (not) happen is irrelevant. INITRD_IN_POSTTRANS thus affects only updates of kernel packages. (kernel-default, _not_ kernel-default-extra etc, for which INITRD_IN_POSTTRANS is set anyway). The effect is, as you know, that building the initrd for a given kernel more than once in a single zypper transaction is avoided. The only risk I am aware of is that some grave error (most likely, disk full) might occur between the %post of the kernel installation and the %posttrans of the transaction and cause a failure in the %posttrans script. If this happens, the missing or incomplete new initrd is probably only one of multiple problems. So, INITRD_IN_POSTTRANS is mostly orthogonal to SKIP_REGENERATE_INITRD_ALL.
This is an autogenerated message for OBS integration: This bug (1192014) was mentioned in https://build.opensuse.org/request/show/1143010 Factory / suse-module-tools
suse-module-tools-16.0.43 fixed this in TW. The initial test package provided by assignee for 15.5 worked on several installations tested, but it was replaced by one that will not install, so can't be tested or used on other installations. Update to 15.5.4 for 15.5 was recently released, but doesn't include the fix.
SUSE-RU-2024:1887-1: An update that has five fixes can now be installed. Category: recommended (moderate) Bug References: 1192014, 1216717, 1217979, 1223278, 1224320 Maintenance Incident: [SUSE:Maintenance:34011](https://smelt.suse.de/incident/34011/) Sources used: openSUSE Leap 15.6 (src): suse-module-tools-15.6.9-150600.3.3.3 Basesystem Module 15-SP6 (src): suse-module-tools-15.6.9-150600.3.3.3 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.