Bug 854416 - dracut man page incorrectly lists --strip as the default functionality
dracut man page incorrectly lists --strip as the default functionality
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dracut (Show other bugs)
6.3
All All
medium Severity medium
: rc
: ---
Assigned To: dracut-maint
Release Test Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-04 19:28 EDT by Daniel Kinon
Modified: 2014-11-10 07:30 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: dracut did not strip the kernel modules as mentioned in the man page. Consequence: initramfs size grew very big, if the customer has kernel modules with a lot of debug info. Fix: dracut now strips the kernel modules, except in FIPS mode. Result: The initramfs size is smaller and can be loaded on machines with small memory.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 05:30:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dracut.conf.5 man page fix (570 bytes, patch)
2012-09-19 11:16 EDT, Filip Krska
harald: review+
harald: review+
Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0436 normal SHIPPED_LIVE dracut bug fix and enhancement update 2013-02-20 15:48:34 EST

  None (edit)
Description Daniel Kinon 2012-09-04 19:28:00 EDT
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:
Comment 1 Harald Hoyer 2012-09-06 05:56:08 EDT
Thanks! man page is incorrect.
Comment 2 Harald Hoyer 2012-09-06 05:58:29 EDT
commit 54f8e74
Comment 3 Daniel Kinon 2012-09-06 11:19:05 EDT
(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
Comment 4 Daniel Kinon 2012-09-17 19:33:53 EDT
(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
Comment 5 Harald Hoyer 2012-09-18 10:11:03 EDT
(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
Comment 6 Filip Krska 2012-09-18 10:32:47 EDT
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.
Comment 7 Daniel Kinon 2012-09-18 11:29:54 EDT
(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
Comment 8 Filip Krska 2012-09-19 11:16:39 EDT
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)
Comment 9 Harald Hoyer 2012-09-20 05:29:59 EDT
(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
Comment 10 Alexander Todorov 2012-09-20 08:28:01 EDT
qa_ack+

Before the fix:

       --strip
              strip binaries in the initramfs (default)

       --nostrip
              do not strip binaries in the initramfs
Comment 11 Harald Hoyer 2012-10-02 16:12:42 EDT
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".
Comment 12 Phil Knirsch 2012-10-18 05:59:43 EDT
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
Comment 14 Harald Hoyer 2012-10-18 06:48:59 EDT
(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.
Comment 15 Harald Hoyer 2012-10-18 08:19:17 EDT
ok, will add nostrip to the dracut-fips subpackage
Comment 16 Jan Stodola 2013-01-09 09:37:40 EST
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.
Comment 17 errata-xmlrpc 2013-02-21 05:30:04 EST
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

Note You need to log in before you can comment on or make changes to this bug.