On Sat, 20 Jun 2009 11:01:33 +0200
Dirk Heinrichs <dirk.heinri...@online.de> wrote:

> Am Samstag 20 Juni 2009 09:37:24 schrieb Mike Kazantsev:
> 
> > Dirk Heinrichs <dirk.heinri...@online.de> wrote:
> > > > 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:
> >
> > So LVM would start before dmcrypt? Great.
> 
> Yes.

No, because encrypted partitions hold LVM volumes as well.


> > > > 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.
> >
> > I do, but mainly for other purposes.
> 
> Which?

Keeping my mini-distro there, which I use as instant-boot router w/o
mounting anything.
Why not keep it on /boot, separate partition or separate initrd?
I do, each with a bit different setup and purpose.


> > Mounting encrypted partitions from there is a bonus and while root is
> > not encrypted (although it doesn't even holds most configuration
> > from /etc) it is an LVM volume.
> 
> > Can linux boot from lvm root w/o initrd these days?
> 
> Yes, it always could. As long as /boot is a separate partition one can put 
> the 
> same stuff into it. Much simpler to setup.

Simplier to setup prehaps, but I find it simplier to keep my initrds
contents in git branches w/ one-click build and deploy script, which I
find simplier to maintain than ten different paths under /boot.

But this goes completely offtopic. It's not like I seek suggestions for
my setup, it works perfectly already.


-- 
Mike Kazantsev // fraggod.net

Attachment: signature.asc
Description: PGP signature

Reply via email to