Hey,
Still looking at this issue (been gone to a conference), but I'm noting
that FAI/debian changed from using liblinux-lvm-perl .14-2 to .16-1.
This ends up changing what the "current device tree" looks like.
Specifically it appears the lv's are represented by /dev/ paths in the
old version and by volume name only in the new version. This is really
significant because the post and pre depend on everything being a dev name.
Old method:
'VG_vg' => [
'/dev/vg/fscache',
'/dev/vg/local.hd',
'/dev/vg/root',
'/dev/vg/swap',
'/dev/vg/var'
]
New method:
'VG_vg' => [
'fscache',
'local.hd',
'root',
'swap',
'var'
]
(I discovered this while trying to use the old setup-storage in a new fai.)
Also, note this info in the Linux::LVM changelog:
0.14 Wed Jul 2 02:54:14 CDT 2008
- Fixed some logic errors to get it working a little better
- Full rewrite underway
I guess one of my questions is: is this a bug in setup-storage, or a bug
in Linux::LVM or perhaps even one of the lvm command line tools?
Also, how long have people be trying to give patches for setup-storage
because of a difference that really arose in Linux::LVM?
If anybody has any info on this before I keep digging on Monday, it
would be appreciated!
-Ken Hahn
On 07/11/2013 05:11 PM, Ken Hahn wrote:
> Hello,
>
> I've been looking through the code, and perhaps I need to ask this on
> the dev list, but I can never see a reason that we need to call vgchange
> -a n. It appears to just cause problems.
>
> Am I correct about this? Can I get a scenario where it would be
> required? perhaps resize... I'm not sure.
>
> Thanks,
>
> -Ken
>
>
> On 07/11/2013 02:46 PM, Ken Hahn wrote:
>> Hello,
>>
>> It looks like this fix doesn't resolve the problem when a preserved
>> partition is desired. Still looking into it.
>>
>> -Ken
>>
>> On 07/11/2013 11:40 AM, Ken Hahn wrote:
>>> Hello,
>>>
>>> Thanks, indeed that patch fixed the problem and made sense to me. I am
>>> still, however, curious if there is indeed any documentation on the
>>> various pre and post states, just so I can understand what they are
>>> supposed to mean? The new vg_enabled_for_destroy_* makes sense to me,
>>> but I'm curious what the original, vgchange_a_n_VG_* is supposed to mean
>>> exactly.
>>>
>>> I think confusion in diagnosing this kind of problem is related to the
>>> lack of this information and also a lack of a way to see the full graph
>>> generated. (we see a topologically sorted dump in the debug, which does
>>> get most of the way).
>>>
>>> Anyway, thank you, again, for the pointer at the patch.
>>>
>>> -Ken
>>>
>>> On 07/11/2013 03:26 AM, Bjarne Bertilsson wrote:
>>>> Hi,
>>>>
>>>> I think the patch posted in this bug report will fix the problem with lvm,
>>>> haven't tested it yet. Notice there are two bugs in that report but the
>>>> one you want is the one posted on github.
>>>>
>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676882
>>>>
>>>> https://github.com/kumy/fai/commit/fbdde8f6707f35bed3a377d901389a2d67e7de37
>>>>
>>>> Not sure why this hasn't been addressed yet on upstream.
>>>>
>>>> BR
>>>> / Bjarne
>>>>
>>>>
>>>> On Wed, Jul 10, 2013 at 10:05:10PM +0200, Ken Hahn wrote:
>>>>> Hello,
>>>>>
>>>>> I'm trying to get FAI working for an install of several labs using
>>>>> Debian Wheezy. I'm using the latest wheezy install of FAI (which is
>>>>> version 4.0.6).
>>>>>
>>>>> My install process has worked fine when I empty out the disk (dd
>>>>> if=/dev/zero of=/dev/sda bs=1024 count=512 is my friend) of the client
>>>>> machine. However, when I try to reinstall on top of a previous system
>>>>> which used LVM, I continually have failures. This led me to a few
>>>>> questions specifically about setup-storage:
>>>>>
>>>>> 1. Is there any documentation on all the names for the pre and post
>>>>> dependencies for a command? I'm having a very hard time deciding if
>>>>> there's a bug, or if my config has problems because it's hard for me to
>>>>> decode these strings. Specifically, what is self_cleared_* and why does
>>>>> it sometimes have a dev node suffix, and other times have a logical
>>>>> volume name?
>>>>>
>>>>> 2. Has anybody had luck with installing where an lvm setup previously
>>>>> existed? I see that the wipefs command always depends on a vgchange -a
>>>>> n command, and I don't understand how that could work, as the vgchange
>>>>> removes the device node. With no device node, there's no device to wipe.
>>>>> (Also, I see that for lvm, wipefs refers to a path like vg/fscache
>>>>> instead of /dev/vg/fscache. I'm not sure how that would ever work,
>>>>> either.)
>>>>>
>>>>> One of the few things that I can think of is that the kernel causes
>>>>> different behavior as to the dev nodes appearance/disappearance. I am
>>>>> using a stock debian kernel instead of the grml one because the grml one
>>>>> was crashing randomly on my test machine (which is similar to my lab
>>>>> machines).
>>>>>
>>>>> I appreciate any relevant feedback.
>>>>>
>>>>> -Ken Hahn
>>>>
>>>
>>
>
