similar to: [PATCH] Create an addition MD variant of the dummy Fedora image

This change involves rewriting make-fedora-img.sh in perl. This allows the flexibility to write mdadm.conf containing whichever uuids where randomly generated when the md devices were created. --- .gitignore | 2 + images/Makefile.am | 18 +++- images/guest-aux/make-fedora-img.pl | 194 +++++++++++++++++++++++++++++++++++

I noticed some uses of ${srcdir} in shell scripts. That is almost always better written as $srcdir. The patch below converts most such variable references. Here are the few remaining candidates: $ git grep -i -E '\$\{[a-zA-Z_0-9]+\}'|grep -v Makefile.in.in configure.ac: JAR_INSTALL_DIR=\${prefix}/share/java configure.ac: JNI_INSTALL_DIR=\${libdir} debian/rules: for TEST in

This API is used to stop a md device. When we want to move a device to another md array, we should stop the md device which contained this device first. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/md.c | 16 ++++++++++++++++ generator/generator_actions.ml | 9 +++++++++ regressions/test-mdadm.sh | 14 ++++++++++++++ src/MAX_PROC_NR

md_create: mdadm: boot: mdadm: boot is not a block device. at /home/rjones/d/libguestfs/images/guest-aux/make-fedora-img.pl line 95. Looking into this, it appears the old version of mdadm shipped in Ubuntu (mdadm 2.6.7) doesn't support the notion of giving arbitrary names to devices. Thus you have to do: mdadm --create /dev/md0 [devices] We do: mdadm --create boot [devices] which it

We've recently discovered that libguestfs can't handle guests which use md. There are (at least) 2 reasons for this: Firstly, the appliance doesn't include mdadm. Without this, md devices aren't detected during the boot process. Simply adding mdadm to the appliance package list fixes this. Secondly, md devices referenced in fstab as, e.g. /dev/md0, aren't handled

This API is used to stop a md device. When we want to move a device to another md array, we should stop the md device which contained this device first. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/md.c | 16 ++++++++++++++++ generator/generator_actions.ml | 9 +++++++++ regressions/test-mdadm.sh | 14 ++++++++++++++ src/MAX_PROC_NR

No functional changes to the tests. --- tests/guests/Makefile.am | 12 ++++++------ tests/guests/guest-aux/make-debian-img.sh | 6 +++--- tests/guests/guest-aux/make-fedora-img.pl | 10 +++++----- tests/guests/guest-aux/make-ubuntu-img.sh | 4 ++-- tests/guests/guest-aux/make-windows-img.sh | 6 +++--- 5 files changed, 19 insertions(+), 19 deletions(-) diff --git

This adds the mdadm-create API for creating RAID devices, and includes various fixes for the other two patches. Rich.

The issue: - raid1 will be in degraded state if one of its components is logical volume (LV) - raid0 will be inoperable at all (inacessible from within appliance) if one of its component is LV - raidN: you can expect the same issue for any raid level depends on how many components are inaccessible at the time mdadm is running and raid redundency. It happens because mdadm is launched prior to lvm

Hello folks, I successfully stopped the software RAID. How can I delete the ones found on scan? I also see them in dmesg. [root at extragreen ~]# mdadm --stop --scan ; echo $? 0 [root at extragreen ~]# mdadm --examine --scan ARRAY /dev/md0 level=raid5 num-devices=4 UUID=89af91cb:802eef21:b2220242:b05806b5 ARRAY /dev/md0 level=raid6 num-devices=4 UUID=3ecf5270:339a89cf:aeb092ab:4c95c5c3 [root

This patch fixes inspection when fstab contains devices md devices specified as /dev/mdN. The appliance creates these devices without reference to the guest's mdadm.conf so, for e.g. /dev/md0 in the guest will often be created as /dev/md127 in the appliance. With this patch, we match the uuids of detected md devices against uuids specified in mdadm.conf, and map them appropriately when we

'--no-degraded' flag in the first mdadm call inhibits the startup of array unless all expected drives are present. This will prevent starting arrays in degraded state. Second mdadm call (after LVM is scanned) will scan unused yet devices and make an attempt to run all found arrays even they are in degraded state. Two new tests are added. This fixes rhbz1527852. Here is boot-benchmark

We would like to have a more flexible way to run tests, including running them on an installed copy of libguestfs, running them in parallel, and being able to express dependencies and ordering between tests and data files properly. Therefore introduce a test harness (test-harness) program which can run tests either from the locally built copy, or from an installed copy of the tests (in

This series fixes inspection in the case that fstab contains references to md devices. I've made a few changes since the previous posting, which I've summarised below. [PATCH 1/8] build: Create an MD variant of the dummy Fedora image I've double checked that no timestamp is required in the Makefile. The script will not run a second time to build fedora-md2.img. [PATCH 2/8] build:

> I got the email that a drive in my 4-drive RAID10 setup failed. What are > my > options? > > Drives are WD1000FYPS (Western Digital 1 TB 3.5" SATA). > > mdadm.conf: > > # mdadm.conf written out by anaconda > MAILADDR root > AUTO +imsm +1.x -all > ARRAY /dev/md/root level=raid10 num-devices=4 > UUID=942f512e:2db8dc6c:71667abc:daf408c3 > >

Howdy folks, I''m trying to boot Xen 3.0 on a Centos 4(.2) system with root on a software raid1 volume. When booting the Xen kernel, ''raidautorun'' in the /init nash script fails to assemble either the root md or the raid5 md containing my LVM volumes. If I move root to /dev/hda1, the system boots fine. raidautorun still fails to assemble the md devices, but mdadm

We would like to have a more flexible way to run tests, including running them on an installed copy of libguestfs, running them in parallel, and being able to express dependencies and ordering between tests and data files properly. Therefore introduce a test harness (test-harness) program which can run tests either from the locally built copy, or from an installed copy of the tests (in

I got the email that a drive in my 4-drive RAID10 setup failed. What are my options? Drives are WD1000FYPS (Western Digital 1 TB 3.5" SATA). mdadm.conf: # mdadm.conf written out by anaconda MAILADDR root AUTO +imsm +1.x -all ARRAY /dev/md/root level=raid10 num-devices=4 UUID=942f512e:2db8dc6c:71667abc:daf408c3 /proc/mdstat: Personalities : [raid10] md127 : active raid10 sdf1[2](F)

These patches are rebased on top of current master. In addition, I've made the following changes: * Fixed whitespace error. * Functions return -1 on error. * Added a debug message when guest contains md devices, but nothing was parsed from mdadm.conf.

We would like to have a more flexible way to run tests, including running them on an installed copy of libguestfs, running them in parallel, and being able to express dependencies and ordering between tests and data files properly. Therefore introduce a test harness (test-harness) program which can run tests either from the locally built copy, or from an installed copy of the tests (in