lvm2 and initrd
Jan Rękorajski
baggins at pld-linux.org
Mon Jul 2 12:07:18 CEST 2012
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.
> and initrd getting bigger and bigger when added more tools into it, so
> older kernels (for newer compiled in default is increased, so it *could*
> fit) need ramdisk_size commandline override, thus can't be automated
> (need manually verified to see that initrd still does fit)
It is not the case with initramfs. I have 40MB uncompressed initramfs
made by dracut and it boots with our kernel.
> so, it's more in to the "liking part" than "udev being bad"
I, personally, would abandon our geninitrd in favor of dracut, yes it's
large, but it just works, one initrams to boot any system.
--
Jan Rękorajski | PLD/Linux
SysAdm | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org
More information about the pld-devel-en
mailing list