Bug 433350 - looks for {dmsetup,lvm}.static
Summary: looks for {dmsetup,lvm}.static
Alias: None
Product: Fedora
Classification: Fedora
Component: kexec-tools
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Fedora Extras Quality Assurance
Depends On: 433392 433395
TreeView+ depends on / blocked
Reported: 2008-02-18 20:07 UTC by Bill Nottingham
Modified: 2014-03-17 03:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-07-15 08:17:59 UTC

Attachments (Terms of Use)

Description Bill Nottingham 2008-02-18 20:07:53 UTC
Description of problem:

These don't exist as static versions any more.

Version-Release number of selected component (if applicable):


Comment 1 Neil Horman 2008-02-18 23:47:11 UTC
Any thoughts as to what to do about this Bill?  [dmsetup|lvm].static are tightly
integrated parts of kdump.  Without them we can't bulid a reasonably sized kdump
initramfs.  They need to be restored, unless there is some other way to use them
from an initramfs without also including glibc.  I'd include uclibc, but IIRC we
don't have that packaged, do we?

Comment 2 Bill Nottingham 2008-02-19 16:46:12 UTC
Well, we're using a dynamic initramfs for 'normal' boot now; I don't see why
kdump can't use the same thing.

Comment 3 Neil Horman 2008-02-19 18:09:32 UTC
well, because kdump isn't a 'normal' boot.  We're trying to a much wider variety
of things (setting up the network, doing nfs mounts, interactive capture, etc.)
from within the initramfs using a fraction of the memory available to a normal
initramfs. People are trying to use kdump with 32MB of ram reserved (not that we
recommend that, but people want to do it).  That space has to be used to hold
the kernel, initramfs and enough heap to capture the vmcore.  If we all of a
sudden need to include glibc for even the most trivial dump case, the initramfs
size increases fromabout 2MB to 10MB.  Thats 30% of our available memory, and
its just not feasible.

The options as I see them are:
1) restore lvm.static and dmraid.static
2) just include libc.so in the initramfs and to heck with the size bloat
3) package uclibc as an extra available package and try to use it as a drop in 
   replacement when populating the kdump initramfs

(1) is the easiest solution, and given that it can be separated out into a
separate package so that people don't generally have to install it, I think its
the best solution

(2) is the easiest solution in general, as thats what kdump did in the past
(although to much complaining from end users), and after all the work we did to
reduce the kdump initramfs image size, I really don't want to go back to that

(3) might be the best compromise , given that it would give me the opportunity
to save space in some corner case s where kdump does still need to include glibc.

I suppose if I had to pick a 'best' overall solution, I'd say (3).  Thoughts?

Comment 4 Bill Nottingham 2008-02-19 18:42:29 UTC
I'm not seeing how your initramfs size would increase that much - for example, a
rawhide initramfs is ~7MB on x86_64 with dynamic libc, and 1MB of that is just
the kernel modules.

Considering libc itself is only 1.8MB, I suspect by the time you include more
than two or three static binaries in the initramfs, you're going to be bigger

(3) worries me, as I don't know that it's going to be 100% compatible.

Comment 5 Jeremy Katz 2008-02-19 18:45:41 UTC
As it turns out, adding libc.so and switching to dynamically linked binaries,
*especially* when you get to having more than a couple ends up being a wash.  We
went through this in both the normal and the anaconda case.  

And if you think that uclibc is the answer, then you're asking the wrong
question.  I've played the "use an alternate libc" approach and it's nothing but

Comment 6 Neil Horman 2008-02-19 19:15:31 UTC
I am admittedly going off memory hereregarding the 7MB number, but IIRC it
wasn't just libc that we needed to pull in, it was libsepol, libselinux, libdl,
libdevmapper, etc.  When it was all totaled up there were enough libraries that
were unique to the individual applications that I needed to pull in, that I just
grew too much.  Its an easy enough test to preform, so I'll check in the event
that something has changed, but last time I looked it was a non-starter.

Comment 7 Neil Horman 2008-02-19 19:45:50 UTC
Ok, so I appear to stand corrected.  moving to dynamic executibles seems to
increase our initramfs size by about 600k.  Its not great by any stretch, but
its not the multiple megabytes that it was in the past.  I'll modify kdump to
using the dynamic executables shortly.  Thanks.

Comment 8 Bug Zapper 2008-05-14 05:15:58 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 9 Bug Zapper 2009-06-09 23:35:03 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 10 Bug Zapper 2009-07-15 08:17:59 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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