Description of problem: These don't exist as static versions any more. Version-Release number of selected component (if applicable): 1.102pre-4.fc9
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 statically. (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 fail.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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
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.