Bug 433350 - looks for {dmsetup,lvm}.static
looks for {dmsetup,lvm}.static
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kexec-tools (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
:
Depends On: 433392 433395
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-18 15:07 EST by Bill Nottingham
Modified: 2014-03-16 23:12 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-15 04:17:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2008-02-18 15:07:53 EST
Description of problem:

These don't exist as static versions any more.

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

1.102pre-4.fc9
Comment 1 Neil Horman 2008-02-18 18:47:11 EST
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 11:46:12 EST
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 13:09:32 EST
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 13:42:29 EST
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
statically.

(3) worries me, as I don't know that it's going to be 100% compatible.
Comment 5 Jeremy Katz 2008-02-19 13:45:41 EST
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
fail.
Comment 6 Neil Horman 2008-02-19 14:15:31 EST
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 14:45:50 EST
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 01:15:58 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Bug Zapper 2009-06-09 19:35:03 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bug Zapper 2009-07-15 04:17:59 EDT
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.