Re: Has anybody had good luck using FAI where it repartitions on a system that previously contained an lvm setup?
Hi Ken, * Am Wed, Jul 10 at 15:05:10 -0500 , schrieb Ken Hahn: > 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. I had the same problem and added a script-hook. It just wipes all disks before trying to partition them. This script was posted on this list before I think. cheers, Christoph commit f00f42e0d8cefa4ab759534b647b9fb275245dc6 Author: Christoph Date: Wed Jun 19 11:41:57 2013 + work around debian bug # #693701 diff --git a/hooks/partition.WIPEDISKS b/hooks/partition.WIPEDISKS new file mode 100644 index 000..7d2b46a --- /dev/null +++ b/hooks/partition.WIPEDISKS @@ -0,0 +1,49 @@ +#!/bin/bash +# +# hooks/partition.WIPEDISKS +# +# author : W. Walkowiak, 2013-01-03 +# changed: +# +# Stop LVM an MD RAIDs if existing and wipe all disks with wipefs and dd +# +# $Id: $ +#=== + +error=0; trap 'error=$(($?>$error?$?:$error))' ERR # save maximum error code + +#--- functions + +# + +# stop volume groups +echo "Stopping VGs:" +vgs +vgchange -an $vg + +# stop MD RAID arrays +echo "Stopping and removing MD RAID arrays:" +mdadm --detail --scan +for array in $(mdadm --detail --scan | cut -d ' ' -f 2 | xargs readlink -f ) +do + parts=$(mdadm --detail $array | grep '/dev/' | grep -oE "[^ :]+$") + mdadm --stop $array + [ -x $array ] && mdadm --remove $array + for part in $parts; do +echo "zeroing $part" +mdadm --zero-superblock $part + done +done +rm -f /etc/mdadm/mdadm.conf + +# wipe all disks with wipefs and dd +if [ -n "$disklist" ]; then + echo "Wiping boot sector of disks: $disklist" + for disk in $disklist; do +wipefs -a /dev/$disk +dd if=/dev/zero of=/dev/$disk bs=512 count=1 + done +fi + +exit $error + > > -Ken Hahn -- Christoph Kluenter E-Mail: supp...@iphh.net Technik Tel: +49 (0)40 374919-10 IPHH Internet Port Hamburg GmbH Fax: +49 (0)40 374919-29 Wendenstrasse 408AG Hamburg, HRB 76071 D-20537 Hamburg Geschaeftsfuehrung: Axel G. Kroeger
Re: Has anybody had good luck using FAI where it repartitions on a system that previously contained an lvm setup?
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
Re: Installing fai-server Without isc-dhcp-server
> On Wed, 10 Jul 2013 21:51:16 -0400, n43w79 said:
> Trying to install fai-server 4.0.6 and apt-get or aptitude shall install
the following (quote):
> The following NEW packages will be installed:
>debconf-utils{a} debootstrap{a} fai-client{a} fai-server file{a}
>isc-dhcp-server{a} libapt-pkg-perl{a} libevent-2.0-5{a}
> Q. Is there a way NOT to install isc-dhcp-server as I already have
dnsmasq on our network.
aptitude -R install fai-server
-R is the same as --without-recommends
--
regards Thomas
Re: Installing fai-server Without isc-dhcp-server
You can also leave the package installed, but disable starting it after
reboot:
insserv -r isc-dhcp-server
I have chosen this route myself. In order not to forget, you can have a
configuration tool (eg cfengine) check the status of the package and
re-run the above command in cases where package upgrades re-enable the
service. This has been necessary here, as experience shows.
Toomas
On Wed, 2013-07-10 at 21:51 -0400, n43w79 wrote:
> Trying to install fai-server 4.0.6 and apt-get or aptitude shall install the
> following (quote):
> The following NEW packages will be installed:
>debconf-utils{a} debootstrap{a} fai-client{a} fai-server file{a}
>isc-dhcp-server{a} libapt-pkg-perl{a} libevent-2.0-5{a}
>libfile-copy-recursive-perl{a} libgraph-perl{a} libgssglue1{a}
>libheap-perl{a} libmagic1{a} libnfsidmap2{a} libproc-daemon-perl{a}
>libproc-processtable-perl{a} libtirpc1{a} mime-support{a} nfs-common{a}
>nfs-kernel-server{a} openbsd-inetd{a} python{a} python-minimal{a}
>python2.7{a} python2.7-minimal{a} rpcbind{a} tftpd-hpa{a} update-inetd{a}
> 0 packages upgraded, 28 newly installed, 0 to remove and 0 not upgraded.
> Need to get 7,464 kB of archives. After unpacking 24.8 MB will be used.
> Q. Is there a way NOT to install isc-dhcp-server as I already have dnsmasq on
> our network.
> Cheers!
> Kwon
>
Re: Has anybody had good luck using FAI where it repartitions on a system that previously contained an lvm setup?
I can confirm that disks with LVM can not be cleanly re-installed with FAI 4.0.6. A wipefs command fails, causing the whole setup-storage to fail. We have only a couple of such systems, all with LVM on top of RAID1, and for these, I have a hook to task partition with the following content: vgremove -f lv1 mdadm --stop /dev/md0 mdadm --stop /dev/md1 dd if=/dev/zero of=/dev/sda bs=10240 count=10 dd if=/dev/zero of=/dev/sdb bs=10240 count=10 Perhaps not all of this is necessary (such as zeroing a whole gigabyte of disk), but this combination reliably wipes both the kernel data and actual disk sufficiently to enable a clean reinstall. Regards, Toomas On Wed, 2013-07-10 at 15:05 -0500, 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: [...]
Re: Installing fai-server Without isc-dhcp-server
On Wed, Jul 10, 2013 at 09:51:16PM -0400, n43w79 wrote: > Q. Is there a way NOT to install isc-dhcp-server as I already have dnsmasq on > our network. Install it, but leave it unconfigured if there's a dnsmasq running somewhere else? S
Re: Installing fai-server Without isc-dhcp-server
Install it, but leave it unconfigured if there's a dnsmasq running somewhere else? Thank you all for replying! I am trying to reduce the size of the install on disk. A base install so far had taken up 700MB!
Re: Has anybody had good luck using FAI where it repartitions on a system that previously contained an lvm setup?
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 >
Not all fixed. Re: Has anybody had good luck using FAI where it repartitions on a system that previously contained an lvm setup?
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 >> >
Re: Not all fixed. Re: Has anybody had good luck using FAI where it repartitions on a system that previously contained an lvm setup?
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 >>> >> >
