Am Samstag 20 Juni 2009 07:33:38 schrieb Mike Kazantsev: > On Fri, 19 Jun 2009 22:15:12 -0600 > > Maxim Wexler <[email protected]> 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
signature.asc
Description: This is a digitally signed message part.
