Description of problem:
These don't exist as static versions any more.
Version-Release number of selected component (if applicable):
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?
Well, we're using a dynamic initramfs for 'normal' boot now; I don't see why
kdump can't use the same thing.
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?
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.
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
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.
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.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
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:
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.