Bug 433395 - lvm.static removed from rawhide
lvm.static removed from rawhide
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Alasdair Kergon
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 433350
  Show dependency treegraph
 
Reported: 2008-02-18 19:14 EST by Neil Horman
Modified: 2008-02-20 07:33 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-20 07:33:39 EST
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 Neil Horman 2008-02-18 19:14:26 EST
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-18 19:54:46 EST
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-18 22:11:57 EST
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 16:10:40 EST
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 07:10:28 EST
"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.