similar to: [PATCH 0/2] daemon: Reimplement handling of lvm.conf and filters.

This patch reworks how we start up LVM and lvmetad. It fixes the problem we had converting a guest which had a peculiar LVM configuration: https://bugzilla.redhat.com/show_bug.cgi?id=1581810#c14 However please note I have NOT yet tested it fully. Rich.

Hi, this series improves the way LVM is used in the appliance: in particular, now lvmetad can eventually run at all, and with the correct configuration. Also improve the listing strategies. Thanks, Pino Toscano (5): daemon: lvm-filter: set also global_filter daemon: lvm-filter: start lvmetad better daemon: lvm: improve filter for LVs with activationskip flag set daemon: lvm: list

Hi, newer lvm2 releases don't have have uncommented "filter" lines, so the current way to edit lvm.conf doesn't work anymore. Instead, switch to augeas (with a "custom" len) for a cleaner and working way to set the lvm filter. Pino Toscano (3): daemon: add add_sprintf daemon: move AUGEAS_ERROR to the common header daemon: lvm-filter: use augeas for setting the

Hi, this series improves the way LVM is used in the appliance: in particular, now lvmetad can eventually run at all, and with the correct configuration. Also improve the listing strategies. Changes in v2: - dropped patch #5, will be sent separately - move lvmetad statup in own function (patch #2) Thanks, Pino Toscano (4): daemon: lvm-filter: set also global_filter daemon: lvm-filter:

Don't carry around Augeas lenses. It is fragile, since if the lens is added to upstream Augeas but the version number has not changed, then Augeas won't parse the target file at all. This specifically causes password adjustments to fail in RHEL 7.1. In future, if we need an Augeas lens, it must be added to Augeas, either upstream or as a downstream patch carried around by distros. ---

v2 of previous patch, which fixes some missing bits. For now I'm going to go with Pino's RHEL 7.1 patch, since it is at least smaller than this. So I'm sending this to the list just to have it archived for later. Rich.

v3: - Don't remove the LVM transform.

I have lvm based (thin pool) storage on local disks. I need to move vps from one vg on one disk to another. Does it possible to migrate to localhost with blockcopy migration to another vg? I'm understand that i can move lv from one vg to another, but i don't need that. -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru

Hi, I would know how to plot two variograms on a same graph. I can plot one by one but I would draw both on the same one. Is it possible? Do i need any special package? Thanks! Cordialement Damien Landais

'--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

Augeas 1.7.0 was released a couple of days ago. By encouraging everyone to upgrade to this we can drop several calls to aug_transform and also our custom copies of two lenses, and a lot of related code. Rich.

When the daemon starts up it creates a fresh (empty) LVM configuration and starts up lvmetad (which depends on the LVM configuration). However this appears to cause problems: Some types of PV seem to require lvmetad and don't work without it (https://bugzilla.redhat.com/show_bug.cgi?id=1581810). If we don't start lvmetad earlier, the device nodes are not created. Therefore move the

Hi, currently /etc/shadow is edited manually when needed (i.e. when setting the password for an user), and it is not changed when removing users. Import the upstream shadow.aug (currently in their development serie, but not part of any released version yet), and use it only when the augeas version is less than a potential 1.2.1 (covering also the case when the new version is just 1.3.0). Pino

Hi All, For quite some time I've used raid 1 as a means of providing a rollback mechanism for an upgrade (which I learned from others long ago). So essentially, before an upgrade you split the mirrors and upgrade one side or the other. If your upgrade goes well you sync one way, if your upgrade does not you sync the other (much hand waving and chanting going on, as its more complicated than

"R Installation and Administration", section 2.5 "Sub-architectures" describes calling specific builds of R using the call "R --arch=name". I am trying to build and install three versions of R-2.9.1, each configured with a different valgrind-instrumentation level ("Writing R Extensions", section 4.3.2 "Using valgrind"). My goal is to be able to

Is there a simple way to directly install a vm on an lvm (or proably seperate LVM's for root and swap)? For example something like: lvcreate -L 10G -n testvm_root vg_myvg lvcreate -L 1G -n testvm_swap Then somehow setup the VM to be able to directly install and boot the vm from these LV's. How do I do this? Could you then pause the virtual machine and safely take an LVM snapshot,

cp will fail if /etc/lvm is an empty directory. Copy the entire directory and adjust environment variable. Signed-off-by: Olaf Hering <olaf at aepfle.de> --- daemon/lvm-filter.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/daemon/lvm-filter.c b/daemon/lvm-filter.c index 52d6b3d..204e238 100644 --- a/daemon/lvm-filter.c +++ b/daemon/lvm-filter.c @@ -47,7

I am trying to do a classic R -d valgrind --vanilla < mypkg-Ex.R as described in http://cs.swan.ac.uk/~csoliver/ok-sat-library/internet_html/doc/doc/R/2.9.1/doc/manual/R-exts.html#Using-valgrind The problem is valgrind crashes imediately. I am using Ubuntu 10.04 LST (actually Biolinux) on a 64bit Dell Precision laptop with 4 core-i5 Intel processors. I have R-2-15-0 installed from source

I've started updating systems to CentOS 7.6, and so far I have one failure. This system has two peculiarities which might have triggered the problem. The first is that one of the software RAID arrays on this system is degraded. While troubleshooting the problem, I saw similar error messages mentioned in bug reports indicating that sGNU/Linux ystems would not boot with degraded software

No functional change. --- tests/lvm/test-lvm-filtering.sh | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/tests/lvm/test-lvm-filtering.sh b/tests/lvm/test-lvm-filtering.sh index 0c8b8803a..abb88ae6c 100755 --- a/tests/lvm/test-lvm-filtering.sh +++ b/tests/lvm/test-lvm-filtering.sh @@ -40,22 +40,22 @@ pvcreate /dev/sdb1 vgcreate VG1 /dev/sda1 vgcreate VG2