Description of problem: dracut functionality defaults to --nostrip in binary and binary usage output but man page says --strip is the default. Given the usage scenarios it seems that the man page is incorrect and needs to be updated. Version-Release number of selected component (if applicable): dracut-004-284.el6_3.noarch How reproducible: Easy Steps to Reproduce: 1. Run the following commands given <RHEL6 kernel>: #dracut initramfs-2.6.32-279.2.1.el6.x86_64-default.img 2.6.32-279.2.1.el6.x86_64 # dracut --strip initramfs-2.6.32-279.2.1.el6.x86_64-strip.img 2.6.32-279.2.1.el6.x86_64 # dracut --nostrip initramfs-2.6.32-279.2.1.el6.x86_64-nostrip.img 2.6.32-279.2.1.el6.x86_64 Actual results: The default run and --nostrip run produce a nostrip initramfs as functionality and binary usage state. Expected results: If the man page is correct, the default run should have produced a stripped initramfs. Additional info:
Thanks! man page is incorrect.
commit 54f8e74
(In reply to comment #1) > Thanks! man page is incorrect. Given how straight forward this is, is there anyway it can be nominated for 6.3.z? Thanks, -Dan
(In reply to comment #3) > (In reply to comment #1) > > Thanks! man page is incorrect. > > Given how straight forward this is, is there anyway it can be nominated for > 6.3.z? > Thanks, > -Dan Give this information, does it make sense to spin another BZ for /sbin/weak-modules script to call dracut with the --nostrip option? Thanks, -Dan
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > Thanks! man page is incorrect. > > > > Given how straight forward this is, is there anyway it can be nominated for > > 6.3.z? > > Thanks, > > -Dan > > Give this information, does it make sense to spin another BZ for > /sbin/weak-modules script to call dracut with the --nostrip option? > Thanks, > -Dan ? nostrip is the default anyway
I guess Dan meant it the other way round. Before the 5be225d2998f5c1ad7d52f2832e66d5d0f867fe6 commit weak-modules produced stripped initramfs and now it produces non stripped, thus sometimes significantly larger initramfs. So the question is if /sbin/weak-modules should be modified to call dracut with --strip option. IMHO yes. I'll check it with module-init-tools maintainer.
(In reply to comment #6) > I guess Dan meant it the other way round. > > Before the 5be225d2998f5c1ad7d52f2832e66d5d0f867fe6 commit weak-modules > produced stripped initramfs and now it produces non stripped, thus sometimes > significantly larger initramfs. > > So the question is if /sbin/weak-modules should be modified to call dracut > with --strip option. IMHO yes. I'll check it with module-init-tools > maintainer. Yes that is what I meant, sorry for the confusion. Thanks, -Dan
Created attachment 614413 [details] dracut.conf.5 man page fix There was also swapped default left in dracut.conf man page: Strip binaries in the initramfs (default=yes)
(In reply to comment #8) > Created attachment 614413 [details] > dracut.conf.5 man page fix > > There was also swapped default left in dracut.conf man page: > > Strip binaries in the initramfs (default=yes) thanks
qa_ack+ Before the fix: --strip strip binaries in the initramfs (default) --nostrip do not strip binaries in the initramfs
ok, after talking to the customer, the request is not to change the man page to reflect reality, but to change the reality to reflect the man page. If nobody objects, I will change the default for dracut to "--strip".
What are the implications of stripping binaries in the initramfs? Are there usecases where this would make a difference for a customer or where unstripped binaries would be necessary in the initramfs? I'm asking because changing a default that we've shipped RHEL-6.4 with seems a bit risky, especially in such a core component as dracut. Personally i've pondered about this and thought about usecases where non-stripped as a default would be preferable, but no real world case that i know of would fit there. In case of a failure you might really want a non-stripped initramfs to do proper debugging there, but then you should always be able to recreate a separate non-stripped initramfs either from a rescue system or from a previously working kernel/initramfs combo. Thanks & regards, Phil
(In reply to comment #12) > What are the implications of stripping binaries in the initramfs? > > Are there usecases where this would make a difference for a customer or > where unstripped binaries would be necessary in the initramfs? > > I'm asking because changing a default that we've shipped RHEL-6.4 with seems > a bit risky, especially in such a core component as dracut. > > Personally i've pondered about this and thought about usecases where > non-stripped as a default would be preferable, but no real world case that i > know of would fit there. > > In case of a failure you might really want a non-stripped initramfs to do > proper debugging there, but then you should always be able to recreate a > separate non-stripped initramfs either from a rescue system or from a > previously working kernel/initramfs combo. > > Thanks & regards, Phil The only critical thing could be FIPS mode. Maybe we should document that you don't want to strip then and therefore need to reconfigure /etc/dracut.conf.
ok, will add nostrip to the dracut-fips subpackage
Tested with dracut-004-302.el6 and dracut-fips-004-302.el6. Default behaviour is to strip binaries in initramfs. When --nostrip option is used, dracut skips stripping. This is in concordance with comment 11 and dracut man page: --strip strip binaries in the initramfs (default) If dracut-fips is installed, dracut will not strip binaries by default. Moving to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0436.html