Re: [gentoo-user] lvm problem -- is timing?

[Dirk Heinrichs]

Am Samstag 20 Juni 2009 07:33:38 schrieb Mike Kazantsev:
> On Fri, 19 Jun 2009 22:15:12 -0600
>
> Maxim Wexler <maxim.wexler@×××××.com> wrote:
> > Seems if I add the commands:
> >
> > vgscan --mknodes
> > vgchange -a y
> > mount -a
> >
> > to /etc/conf.d/bootmisc and add it to the boot runlevel, the eee boots
> > to a coherent system BUT not before going through LVM failure, errors,
> > inability to find volumes etc through many console lines until just
> > after the line:
> >
> > *Configuring kernel parameters...
> >
> > comes
> >
> > Reading all physical volumes. This may take a while...
> > Found volume group "vg" using metadata type lvm2
> > 5 logical volume(s) in volume group "vg" now active
> > ...
> >
> > And everything is fine after that. So it looks like a question of
> > timing, of executing bootmisc or something like it earlier, say just
> > after loading dm-mod and dm-crypt and just before the line in the
> > console:
> >
> > *Setting up the Logical Volume Manager...
> >
> > When it all starts to fall apart.
> >
> > FWIW I'm using baselayout-2.
>
> I've had such problem in the past, even filed the bug:
>
>   http://bugs.gentoo.org/show_bug.cgi?id=255237
>
> For me, the problem was that "device-mapper" initscript started after
> "lvm".
>
> I believe there's "after device-mapper" line already in lvm-2.02.45, so
> it should run fine, but as an additional precaution I have dm-crypt
> script at sysinit runlevel, which starts device-mapper and dm-crypt
> before lvm or even it's runlevel (boot).

That's not needed, it should be sufficient to have them all in the boot 
runlevel:

# ll /etc/runlevels/boot
insgesamt 0
lrwxrwxrwx 1 root root 20 28. Dez 14:02 bootmisc -> /etc/init.d/bootmisc*
lrwxrwxrwx 1 root root 25 12. Apr 08:58 device-mapper -> /etc/init.d/device-
mapper*
lrwxrwxrwx 1 root root 19 12. Apr 08:59 dmcrypt -> /etc/init.d/dmcrypt*
lrwxrwxrwx 1 root root 16 28. Dez 13:53 fsck -> /etc/init.d/fsck*
lrwxrwxrwx 1 root root 20 28. Dez 14:02 hostname -> /etc/init.d/hostname*
lrwxrwxrwx 1 root root 19 28. Dez 14:02 hwclock -> /etc/init.d/hwclock*
lrwxrwxrwx 1 root root 19 28. Dez 17:20 keymaps -> /etc/init.d/keymaps*
lrwxrwxrwx 1 root root 22 28. Dez 14:02 localmount -> /etc/init.d/localmount*
lrwxrwxrwx 1 root root 15 12. Apr 08:58 lvm -> /etc/init.d/lvm*
lrwxrwxrwx 1 root root 19 28. Dez 14:02 modules -> /etc/init.d/modules*
lrwxrwxrwx 1 root root 16 28. Dez 13:53 mtab -> /etc/init.d/mtab*
lrwxrwxrwx 1 root root 18 28. Dez 14:02 net.lo -> /etc/init.d/net.lo*
lrwxrwxrwx 1 root root 18 28. Dez 13:53 procfs -> /etc/init.d/procfs*
lrwxrwxrwx 1 root root 16 28. Dez 13:53 root -> /etc/init.d/root*
lrwxrwxrwx 1 root root 16 28. Dez 13:53 swap -> /etc/init.d/swap*
lrwxrwxrwx 1 root root 18 28. Dez 14:02 sysctl -> /etc/init.d/sysctl*
lrwxrwxrwx 1 root root 24 28. Dez 14:02 termencoding -> 
/etc/init.d/termencoding*
lrwxrwxrwx 1 root root 19 28. Dez 14:02 urandom -> /etc/init.d/urandom*

> It makes sense for me, since some lvm pv's (not root) are actually on
> encrypted partitions, although I mount these even earlier, but should
> initrd become incompatible w/ latest kernel, dm-crypt should do the job
> instead.

No, it does not make sense. You don't even need an initrd.

> Guess you can do the same, at least if you don't have dm-crypt
> mappings, or you can try adding device-mapper to sysinit level directly.

As said above, it's not not needed. Maybe it's better to investigate wether 
there are any leftovers from baselayout 1 in the runlevels. This was at least 
the reason I got an unbootable system after switching to bl 2.

HTH...

	Dirk