Re: setup-storage for raid5 + lvm
Hi, Nicolas Courtel wrote on 2009-04-30 11:11:46 +0200 [Re: setup-storage for raid5 + lvm]: # mdadm --zero-superblock /dev/sda2 # /lib/udev/vol_id -u /dev/sda2 6428a2d1-c30d-4916-ab6b-625117989651 [...] Ok, good to know, thanks for testing this. I wonder whether we should do something about this in setup-storage, but I believe that doing mdadm --zero-superblock on each and every non-RAID device is pure overkill. I agree. You may want to add a few words in the error message, something like Failed to obtain UUID [...], check that $device_name is not or has not been a RAID partition. sorry, I'm not familiar with the code in question, so I don't know if it's actually possible, but ideally, detecting this failure would trigger possible remedies to the problem (eg. zeroing the RAID superblock - unless this is potentially harmful for reasons not obvious to me right now) and then re-try. I can imagine that this might not be as simple to implement as it sounds. As an alternative, there could be a pedantic mode (triggered by some flag) which actually does zero each potential superblock (again, unless there is some reason this might be undesirable). Then, if you hit trouble with a particular installation, you could simply turn on this flag and see if it solves your problem without needing to go into any extensive debugging. Having something that just works even in awkward circumstances without manual intervention does not seem like a bad idea, does it? Thinking about the complexity of a modern Linux system, though, I tend to agree that something like that should be turned off by default ;-). Regards, Holger
Re: setup-storage for raid5 + lvm
# mdadm --zero-superblock /dev/sda2 # /lib/udev/vol_id -u /dev/sda2 6428a2d1-c30d-4916-ab6b-625117989651 # I wonder how this mdadm data was still there, though... Thanks for your help, Ok, good to know, thanks for testing this. I wonder whether we should do something about this in setup-storage, but I believe that doing mdadm --zero-superblock on each and every non-RAID device is pure overkill. I agree. You may want to add a few words in the error message, something like Failed to obtain UUID [...], check that $device_name is not or has not been a RAID partition. -- Nicolas
RE: Etch amd64 mirror broken? - Packages.gz was corrupt
-Message d'origine- De : linux-fai-boun...@uni-koeln.de [mailto:linux-fai-boun...@uni-koeln.de] De la part de Michael Tautschnig Envoyé : 29 avril 2009 16:12 À : linux-fai@uni-koeln.de Objet : Re: Etch amd64 mirror broken? - Packages.gz was corrupt [...] I've tried changing my FAI_DEBOOTSTRAP=etch http://ftp.debian.org/debian; but I get the exact same error with debian.org: Calling debootstrap etch /data/fai/nfsroot/QC/amd64/live/filesystem.dir http://ftp.debian.org/debian [^] I: Retrieving Packages I: Validating Packages W: http://ftp.debian.org/debian/dists/etch/main/binary-amd64/Packages.gz [^] was corrupt I: Retrieving Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... W: Failure trying to run: chroot /data/fai/nfsroot/QC/amd64/live/filesystem.dir mount -t proc proc /proc Everything used to be working really really smoothly until recently (we actually noticed that on april 17th). Lastly, our 32bit fai runs without a flaw and I can update my nfsroot without any problems using either debian.org or my local debmirror. Just a really blind guess: Are you working behind some proxy? Has it cached that file (in a broken way)? Its just debootstrap that is running here ... Nope... and that is why I'm really really wondering what might be causing this??? It does the same error either directly on debian.org or on my internal debmirror ONLY on amd64 etch ??? And that is totally new since perhaps 2-3 week? I'm probably mistaking but it makes me wonder if there could be a real corruption of the Pacakges files for amd64 etch on the official debian repository??? Or curiously enough, a new bug in the debootstrap that suddently appeared 2-3 weeks ago? What's wierd is that it never stopped working on i386 but suddently got marked as corrupted by debootstrap only for amd64 ? Wierd guess: official etch amd64 repository broken? - vin
RE: Etch amd64 mirror broken? - Packages.gz was corrupt
-Message d'origine- De : linux-fai-boun...@uni-koeln.de [mailto:linux-fai-boun...@uni-koeln.de] De la part de Fortier,Vincent [Montreal] Envoyé : 30 avril 2009 07:52 À : Michael Tautschnig; linux-fai@uni-koeln.de Objet : RE: Etch amd64 mirror broken? - Packages.gz was corrupt -Message d'origine- De : linux-fai-boun...@uni-koeln.de [mailto:linux-fai-boun...@uni-koeln.de] De la part de Michael Tautschnig Envoyé : 29 avril 2009 16:12 À : linux-fai@uni-koeln.de Objet : Re: Etch amd64 mirror broken? - Packages.gz was corrupt [...] I've tried changing my FAI_DEBOOTSTRAP=etch http://ftp.debian.org/debian; but I get the exact same error with debian.org: Calling debootstrap etch /data/fai/nfsroot/QC/amd64/live/filesystem.dir http://ftp.debian.org/debian [^] I: Retrieving Packages I: Validating Packages W: http://ftp.debian.org/debian/dists/etch/main/binary-amd64/Packages.gz [^] was corrupt I: Retrieving Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... W: Failure trying to run: chroot /data/fai/nfsroot/QC/amd64/live/filesystem.dir mount -t proc proc /proc Everything used to be working really really smoothly until recently (we actually noticed that on april 17th). Lastly, our 32bit fai runs without a flaw and I can update my nfsroot without any problems using either debian.org or my local debmirror. Just a really blind guess: Are you working behind some proxy? Has it cached that file (in a broken way)? Its just debootstrap that is running here ... Nope... and that is why I'm really really wondering what might be causing this??? It does the same error either directly on debian.org or on my internal debmirror ONLY on amd64 etch ??? And that is totally new since perhaps 2-3 week? I'm probably mistaking but it makes me wonder if there could be a real corruption of the Pacakges files for amd64 etch on the official debian repository??? Or curiously enough, a new bug in the debootstrap that suddently appeared 2-3 weeks ago? What's wierd is that it never stopped working on i386 but suddently got marked as corrupted by debootstrap only for amd64 ? Wierd guess: official etch amd64 repository broken? OK, tried something else and got some pretty interesting results... Although it does not solve my problem: I've installed debootstrap from lenny and reinvoked fai-setup -vvv and this time I did'nt got any signs of errors against Pacakges.gz. Although due to incompatibilities between lenny vs etch it failed to finish (I actually did'nt tought it would go that far...): install_packages: executing chroot /data/fai/nfsroot/QC/amd64/live/filesystem.dir apt-get clean Can't call method exists on an undefined value at /usr/sbin/install_packages line 416, FILE line 38. install_packages exit code: 2 Curiously enough I reinstalled debootstrap from etch and reinvoked fai-setup -vvv and this time magic occured since it was capable of validating the Package.gz and it seemed like working well until this: I: Base system installed successfully. ERROR: debootstrap did not complete successfully. This is mostly caused by a broken mirror. Please check your mirror or use an official mirror. No diversion `any diversion of /sbin/discover-modprobe', none removed Log file written to /var/log/fai/make-fai-nfsroot.log Could not find the type of your nfs server. Maybe no nfs server is installed. I can't restart it. FAI setup finished. Log file written to /var/log/fai/fai-setup.log I'm getting that error wether I use my local debian mirror repository or the official debian.org... So still I'm getting at the same guess: Could the official debian repository for etch amd64 be incompatible with etch debmirror since a few weeks? Again help appreciated! - vin
RE: setup-storage 1.0.4 - ERROR (line 11): Invalid file:Wasexpecting /\Z/ but found
-Message d'origine- De : linux-fai-boun...@uni-koeln.de [mailto:linux-fai-boun...@uni-koeln.de] De la part de Michael Tautschnig Envoyé : 29 avril 2009 16:23 À : linux-fai Objet : Re: setup-storage 1.0.4 - ERROR (line 11): Invalid file:Wasexpecting /\Z/ but found You where soo right... Thnx... I was trying to assign 72304 x 1024 = 74039296 disk_config disk1 bootable:1 primary /boot 256 ext3defaults primary - 2048swaprw primary - 7- - - while I the disk as: [r...@urpbe1 /root]# fdisk -l Disk /dev/sda: 72.7 GB, 72746008576 bytes 255 heads, 63 sectors/track, 8844 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Thnx a lot! - vin i agree that the error message could be a little different like: disk is not big enough for the settings or I don't want to talk to you no more, you empty headed animal food trough wiper. I fart in your general direction. Your mother was a hamster and your father smelt of elderberries, something that really told us we got somethign wrong in our configs ;) I've changed the error message to Sorry, can't create a partition of $start B on a disk of $size_b - check your config! (with $start and $size_b being the size of the partition and that of the disk, respectively). Will make it into the next experimental upload. Thnx... Will certainly be helpfull :) Regards, - vin
