Bug 433395 - lvm.static removed from rawhide
Summary: lvm.static removed from rawhide
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 433350
TreeView+ depends on / blocked
 
Reported: 2008-02-19 00:14 UTC by Neil Horman
Modified: 2008-02-20 12:33 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-20 12:33:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Neil Horman 2008-02-19 00:14:26 UTC
It appears that lvm.static has been removed from the lvm2 package.  Please
restore this binary to the package, or split it into a separate lvm2-static
package.  Kdump relies on the static version of this utility (not we don't want
to bloat its initramfs with including the entire c library).  Without the static
version of this utility, Kdump cannot produce working initramfs images.  Thanks!

Comment 1 Alasdair Kergon 2008-02-19 00:54:46 UTC
Left hand / Right hand?

I understood that it *was* now policy in Fedora for the C library to be included
just once as a shared object, instead of being included separately inside every
static binary.

I have no wish to reinstate the lvm/dm static binaries, sorry.

Comment 2 Neil Horman 2008-02-19 03:11:57 UTC
If its policy, then the policy is broken as it was formed.  I need to be able to
assemble lvm volumes from within an initramfs that is fashioned out of busybox,
and for kdump we don't have the space to include all of libc.  So if lvm.static
can't be reinstated, then kdump can't be included in fedora in such a way as to
support lvm volumes, unless you have another solution in mind.

Comment 3 Alasdair Kergon 2008-02-19 21:10:40 UTC
Well, firstly, why should kdump and mkinitrd be different?

Secondly, the lvm+dm binaries aren't small and you get two copies of libraries
built in, and there must be other static binaries too, so is there genuinely a
significant space saving from using static binaries?

If static binaries do have to go back *just for kdump* then we create an lvm2
sub-package that installs them both in some helper directory for kdump to take
them from - not directly in /sbin.


Comment 4 Neil Horman 2008-02-20 12:10:28 UTC
"Well, firstly, why should kdump and mkinitrd be different?"
Quite simply, because they do different things.  We don't nominally boot back
into the rootfs, because after a crash, we can't be guaranteed that the rootfs
isnt corrupt, so instead we do all our capture work from the initrd.  As such we
need to assemble a much more involved initramfs than that which mkinitrd
provides.  As such we need to save space whereever we can, to avoid getting huge
bloat in a limited amount of ram.

No lvm+dm binaries aren't small, but they for most cases, were all we needed. 
Busybox, which is relatively small, provided all our other functionality. 
busybox+lvm.static+dm.static resulted in a smaller initramfs than what nash
could provide through mkinitrd.

And yes, that is what I was asking for, the lvm and dm binaries to be moved to a
sub-package.  Fortunately however, notting asked me to recheck my previous
tests, and library usage and size appear to have been reduced sufficiently, such
that add libc isn't as obtrusive as it once was (600K growth, vs. about 2-3MB
previously).  So this can be closed.


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