lvm2 and initrd

[Paweł Sikora]

On Monday 02 of July 2012 12:07:18 Jan Rękorajski wrote:
> On Mon, 02 Jul 2012, Elan Ruusamäe wrote:
> 
> > On 07/02/2012 09:22 AM, Jacek Konieczny wrote:
> > > On Mon, Jul 02, 2012 at 08:45:41AM +0300, Elan Ruusamäe wrote:
> > >> >  anyone interested working that out (so that udev can be again optional
> > >> >  for rootfs on lvm systems)?
> > > Is udev on initrams that bad, that you just don't want to use it? Are
> > > there scenarios where udev just won't work?
> > well, there's continuous fight getting initrd versions of tools 
> > compiled, as new releases tend to get broken with klibc/uclibc/... and 
> > even if they compile with some patching, they can crash in some 
> > configurations/architectures.
> 
> AFAIR semaphore messages are harmless.
> 
> > this could end up we will be having glibc version of initrd udev, or no 
> > initrd version of udev at all, because nobody wants to do the porting to 
> > small libc's.
> 
> Porting, and lately even just static linking, becomes bigger and bigger
> RPITA, so we may have no choice than to having dynamic linked programs
> in initrd. I just don't see a reason to justify the extent of work one
> have to put into making klibc/uclibc/.../static built tools.

we should use shared libc.so (~1.7MB @ x86-64) in initrd and build essential
init tools with -Os optimization. -Os e.g. reduces mdadm size from 448kB to 380kB
and 'upx -9' reduces binaries about the ~50% (better than gzip -9).
i vote for drop any klibc/uclibc/glibc static linking.