Re: lvm bug - possible solution
On Tue, 21 Aug 2001, Robert van der Meulen wrote:
> 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.
Well, modifying it to call a shell script for lvm (if it exists) at critical
points, and the same for RAID or other packages that need such hooks MIGHT
help.
> > I sort of wish we had proper hooks in mountall.sh to handle that sort of
> > thing...
> ..but we don't.
So we either make do without, or add them, or work around them (which is
what I suggested: add lvm hooks in mountall.sh, although I did not use the
word "hook").
> 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.
Can the kernel automount lvm volumes like it does for RAID (at least for
new-style RAID) ?
> 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 ?
Well, you can regenerate the /etc/lvm* stuff right at the beginning of the
shutdown sequence, just in case. That should make reasonably sure that they
will be current at the next bootup.
I think that's a better solution than changing mountall.sh, actually.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: