setup-storage & preserve_lazy on LVM

[Michael Tautschnig]

Hi Mât,

[...]
> 
> This lets me a bit afraid yesterday. By closer looking at the debug
> output, the sda4 is created exactly the same as in the first install :)
> 
> > Well, indeed I could add a logic to detect that the partition hasn't moved at
> > all and could therefore just be rebuilt as is. (That is, the logical partition
> > will be created in the same place and the containing extended partition will be
> > resized, which is a no-op in this case.)
> 
> I agree to the fact that it's finally a no-op action there.
> Maybe suppressing the "will be resized" message would be a (little) good point as it
> confused me about what will be done, maybe others will be confused too.
>

Hmm, yes, might be good to adjust that a bit. I'll take a look at that, but that
won't happen right away.

[...]
> I think I've found something interesting !
> 
> There are some repeating steps (33,34,35) == (37,41,46) ! That are cleared just after (37).
> I've made some tests, and the command 35 just let the LV appear again ;) !
> And as the lvm logical parts are here again, all the next command will
> print a warning about parts are in use. And 46 fails.
> 

Wow, thanks for debugging it to the point that LVs re-appear. That was
tremendously helpful!

> 
> My real problem seems to be there.
> Why is there commands 33 through 35 ? Maybe they shouldn't be there.
> 36 wouldn't be sufficient ? or useless as it the same partition plan !?
> 
[...]

In your case, yes, we could get away without these steps. But in general that
seems like the easiest way to be able to resize partitions, i.e., first remove
all the useless ones and only then start moving around.

> I've tried the sequence manually.
> 
> vgchange -a n HEBEX
> parted -s /dev/sda mklabel msdos
> parted -s /dev/sda mkpart extended "" 2237276160B 32210196479B
> parted -s /dev/sda mkpart logical "" 6514421760B 32210196479B
> 
> (here the lvm are recreated and all the next commands print a warning
> about parts are in use. And 46 fails.)
> 
> parted -s /dev/sda resize 1 2237276160B 32210196479B
> 
> I've made a "vgchange -a n HEBEX" here, and all the next commands works :)
> 
[...]
> 
> The reinstall was with Lucid NFSROOT:
> parted (GNU parted) 2.2
> 
> That is maybe why there is some
> "Warning: The resulting partition is not properly aligned for best performance."
> 
> > - I've used squeeze, which version of Debian or Ubuntu is your NFSROOT based
> >   upon?
> 
> Lenny / Lucid
> 
[...]

I've found this one:

https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/133905

It seems that Ubuntu devs are pretty fond of their extra changes, making volume
groups start as volumes appear via some udev magic. It's a Ubuntu-specific
change as outlined in

https://launchpad.net/ubuntu/+source/lvm2/+changelog

I have no idea why they insist in doing that. After all, Debian people seem to
get away fine without such nasty auto-run-volume-group stuff. If you need a
quick fix, I'd suggest going for a Debian NFSROOT :-) Well, no, it's even
easier:

cd $NFSROOT ; rm lib/udev/rules.d/85-lvm2.rules

I'm seriously considering a simple diversion of that file while setup-storage is
running. I don't think brute-force repeated vgchange calls would be a viable
solution.

Sorry,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20110329/baa032e8/attachment.bin>