Has anybody had good luck using FAI where it repartitions on a system that previously contained an lvm setup?
khahn at engr.wisc.edu
Thu Jul 11 18:40:35 CEST 2013
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
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.
On 07/11/2013 03:26 AM, Bjarne Bertilsson wrote:
> 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.
> Not sure why this hasn't been addressed yet on upstream.
> / Bjarne
> On Wed, Jul 10, 2013 at 10:05:10PM +0200, Ken Hahn wrote:
>> 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
>> I appreciate any relevant feedback.
>> -Ken Hahn
More information about the linux-fai