lvm bug - possible solution
Hi,
Quoting Henrique de Moraes Holschuh (hmh@debian.org):
> > behavior in the lvm script; that sounds evil as well.
> > Any ideas, anyone ?
> Coordinate with the maintainer that takes care of mountall.sh, make damn
> sure lvm stuff can be inserted into that file in a very sane way, that will
> not cause trouble with different versions of lvm, or lvm not being
> active/installed in the system.
We can't 'make damn sure' 'mountall.sh' is modified just for lvm. It is
called 'mountall.sh' because it has to do with mounting, not with
initialising logical volumes.
> > (remember, lvm is not a filesystem, but creates a virtual device to make a
> > filesystem on)
> I sort of wish we had proper hooks in mountall.sh to handle that sort of
> thing...
..but we don't.
It is possible to run 'vgchange' (the thing that is used in the lvm
initscript to make the volumes visible to the kernel) without creating the
lvm files in /etc/ first; as long as they're there.
As far as i know, it only needs to be certain that there is an up-to-date
/etc/lvmtab and /etc/lvmtab.d/ available, which can be created and updated
outside the boot process.
This means that any update to the logical volumes has to be followed by a
vgscan command to update /etc/lvmtab and /etc/lvmtab.d. On the next reboot,
vgchange has the data it needs, and can initialise its volumes based on the
existing /etc/lvmtab / /etc/lvmtab.d/ ; and doesn't need / rw.
This is all 'afaik', so any comments anyone ?
Greets,
Robert
--
Linux Generation
encrypted mail preferred. finger rvdm@debian.org for my GnuPG/PGP key.
<doogie> 'How to Raise Your I.Q. by Eating Gifted Children'
Reply to: