Re: lvm bug - possible solution
Hi,
Quoting Henrique de Moraes Holschuh (hmh@debian.org):
> 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 disagree. There is a functional difference between the two. The best they
can do is take eachother into account in some generic way, but them does not
sound like a good idea to me..
> > > 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").
I won't comment on the 'hook' thing anymore - i've made it clear that i
disagree, the rest is up to the maintainer of the package in question ;)
> > 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) ?
I'm not sure what you mean here.
It can't auto-initialise lvm volumes. It _can_ automount filesystems in
those volumes, after they're initialised.
> 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.
Good point.
> I think that's a better solution than changing mountall.sh, actually.
Me too :)
Greets,
Robert
--
Linux Generation
encrypted mail preferred. finger rvdm@debian.org for my GnuPG/PGP key.
<Fluor> zarq: i'll be gentle :]
Reply to: