setup-storage & preserve_lazy on LVM

Tue Mar 29 11:17:18 CEST 2011

Le lundi 28 mars 2011 à 20:17 +0100, Michael Tautschnig a écrit : 
> Hi Mât,
Hi Michael,

First of all, thanks for taking time to reply :)

[...]

> > * I've saw in the debug output that my LVM parts will be preserved and
> > my PV part will also be preserved (good here) but setup-storage try to
> > create the PV partition (but it shouldn't !). Hopefully it give me an
> > error about /dev/sda9 is in use and stop here.
> > 
> 
> I'm not 100% sure I understand what you mean by "create the PV partition (but it
> shouldn't)" - you asked to preserve partition 9 (well, implicitly, you want to
> preserve the LVM volumes and therefore setup-storage infers that this partition
> must be preserved. To setup-storage, this means that it will rebuild the
> partition in the very same place and won't do any formatting. 

I'll try to reformulate so we'll speak about the same things.

What I need is to tell setup-storage that my 2 LVs must be preserved.
Implicitly, I expect the PV (sda9) to be also preserved.
To preserve sda9, the extended partition (sda4) should be preserved as well (?)
(But sda5-sda8 should not be preserved and should be formated)

> > * In the logs I saw "/dev/sda4 will be resized", why should this part be
> > resized, as it is the same partition plan !?

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.

> Therefore I don't quite see a problem with these steps,

Right now, with fresh minds, I agree that until to this point, there is no problem,
setup-storage "will" do what I expect :)

> apart from the fact that
> at some point ...
[...]
> ... in these logs we have:
> 
> (CMD) parted -s /dev/sda mklabel msdos 1> /tmp/KATiFXM2l8 2> /tmp/P8rxJ2K0zg
> Executing: parted -s /dev/sda mklabel msdos
> (STDOUT) Warning: WARNING: partition(s) 5 on /dev/sda could not be modified, probably because it/they is/are in use.  As a result, the old partition(s) will remain in use until after reboot. You should reboot now before making further changes.
> 
> (And several more of these until finally it all fails for /dev/sda9.)

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.

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 !?

33:parted -s /dev/sda mklabel msdos
	pre: exist_/dev/sda,self_cleared_VG_HEBEX
	post: cleared1_/dev/sda
34:parted -s /dev/sda mkpart extended "" 2237276160B 32210196479B
	pre: cleared1_/dev/sda
	post: exist_/dev/sda1,rebuilt_/dev/sda1
35:parted -s /dev/sda mkpart logical "" 6514421760B 32210196479B
	pre: cleared1_/dev/sda
	post: exist_/dev/sda5
36:parted -s /dev/sda resize 1 2237276160B 32210196479B
	pre: rebuilt_/dev/sda1
	post: resized_/dev/sda1
37:parted -s /dev/sda mklabel msdos
	pre: cleared1_/dev/sda,exist_/dev/sda5,resized_/dev/sda1
	post: cleared2_/dev/sda

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 :)

parted -s /dev/sda mklabel msdos
parted -s /dev/sda mkpart primary "ext3" 32256B 98703359B
parted -s /dev/sda mkpart primary "linux-swap" 98703360B 1167989759B
parted -s /dev/sda mkpart primary "ext3" 1167989760B 2237276159B
parted -s /dev/sda mkpart extended "" 2237276160B 32210196479B
parted -s /dev/sda mkpart logical "ext3" 2237277184B 3808304639B
parted -s /dev/sda mkpart logical "ext3" 3816529920B 4885816319B
parted -s /dev/sda mkpart logical "ext3" 4894041600B 5428684799B
parted -s /dev/sda mkpart logical "ext3" 5436910080B 6506196479B
parted -s /dev/sda mkpart logical "" 6514421760B 32210196479B

Do you see ?

> > I hope we can't solve this :)
>             ^^^^^^ 
> 
> Are you sure? Then we're fine off I guess :-))))

Ooops :) Of course, there is no doubts that I wanted to say "CAN" !

[...]

> > PS: I've also seen this message:
> > "Can't exec "mdadm-startall": No such file or directory
> > at /usr/sbin/setup-storage line 146, <$config_file> line 1."
> > 
> > What should I do ? Should I install mdadm-startall in my nfsroot, or
> > setup-storage should check if the command is available before calling
> > it ?
> 
> Ok, so first of all:
> 
> - I tried your configs in an attempt to reproduce your problem. But for me it
>   works!? Therefore I wonder whether this is related to a particular version of
>   some tool!? Could you run parted --version in your NFSROOT?

The first install was made with a lenny NFSROOT:
parted (GNU parted) 1.8.8

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 think the missing mdadm-startall isn't quite fatal, but obviously it isn't
>   nice either. As squeeze is Debian/stable, presumably all recent Debian or
>   Ubuntu distributions provide that command, however.

I'll go with installing mdadm stuff...

> - Just to rule out sources of randomness: could you simply give it another try?

I've done it twice yesterday, but I'll do it again...

> Best regards,
> Michael

Bests
Mât

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5063 bytes
Desc: not available
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20110329/543b797f/attachment-0001.bin>