Hi all, I’ve run into an issue when trying to activate an LV which resides on a read-only loop device. When I run lvchange -a y <LV Path> I get the following error: Error writing device /dev/loop0p5 at 4096 length 512. bcache_invalidate: block (4, 0) still dirty Failed to write mda header to /dev/loop0p5 fd -1 Failed to update old PV extension headers in VG recursor02-01-vg. Volume group "recursor02-01-vg" not found Cannot process volume group recursor02-01-vg I’ve observed this issue when using LVM version 2.03.02 (Debian 10) to activate the LV. The volume I’m trying to mount comes from a host which has LVM version 2.02.168 which explains why headers are attempted to be updated. The lvchange commando is part of a file restore procedure. The backup solution we are using (Xen Orchestra) creates chained .vhd files but is unable to access LVM volumes which reside across multiple PV’s. As restoring a full VM is often not required a solution was found in using vhdimount and losetup to access the data and get the required files from the backups. # vhdimount 20200714T234001Z.vhd /mnt/20200714T234001Z # losetup -P -r -f /mnt/20200714T234001Z/vhdi1 # lsblk /dev/loop0 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 42G 1 loop |-loop0p1 259:0 0 243M 1 part |-loop0p2 259:1 0 1K 1 part `-loop0p5 259:2 0 41.8G 1 part Given the error I would guess the source of this issue might be caused by the following commit: https://sourceware.org/git/?p=lvm2.git;a=commit;h=070c0d31ab3847240081e7593f959b03e716923d Is there a way I can prevent the update of the extension headers when activating the LV? With kind regards, Henk
On Fri, Jul 17, 2020 at 09:04:32AM +0200, Henk Kraal wrote: > Hi all, > > I’ve run into an issue when trying to activate an LV which resides on a > read-only loop device. When I run lvchange -a y <LV Path> I get the > following error: > > Error writing device /dev/loop0p5 at 4096 length 512. > bcache_invalidate: block (4, 0) still dirty > Failed to write mda header to /dev/loop0p5 fd -1 > Failed to update old PV extension headers in VG recursor02-01-vg. > Volume group "recursor02-01-vg" not found > Cannot process volume group recursor02-01-vg > > I’ve observed this issue when using LVM version 2.03.02 > Is there a way I can prevent the update of the extension headers when > activating the LV? I don't think there's a way to tell that version to skip the header update. A more recent verson of lvm should work, and let you use the PV without updating the header. It will not attempt updates from commands which are not otherwise updating lvm metadata. Dave
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --] > On 17 Jul 2020, at 18:20, David Teigland <teigland@redhat.com> wrote: > > On Fri, Jul 17, 2020 at 09:04:32AM +0200, Henk Kraal wrote: >> Hi all, >> > >> I’ve run into an issue when trying to activate an LV which resides on a >> read-only loop device. When I run lvchange -a y <LV Path> I get the >> following error: >> >> Error writing device /dev/loop0p5 at 4096 length 512. >> bcache_invalidate: block (4, 0) still dirty >> Failed to write mda header to /dev/loop0p5 fd -1 >> Failed to update old PV extension headers in VG recursor02-01-vg. >> Volume group "recursor02-01-vg" not found >> Cannot process volume group recursor02-01-vg >> >> I’ve observed this issue when using LVM version 2.03.02 > >> Is there a way I can prevent the update of the extension headers when >> activating the LV? > > I don't think there's a way to tell that version to skip the header > update. A more recent verson of lvm should work, and let you use the PV > without updating the header. It will not attempt updates from commands > which are not otherwise updating lvm metadata. > Dave Hi Dave, Thank you for confirming that skipping the header update probably isn’t possible as I expected. I just wanted to make sure I wasn’t going down a rabbit hole needlessly. The older LVM headers which I’m dealing with are part of the OS of hundreds of virtual servers which I don’t control. My task is to make the data on the read-only PV accesable for retrieval. A parameter to skip the update would’t have been the best option but I guess I need figure out if I can place a (temporary) writeable layer on top of the device to work around this. Off course I’m open to idea’s if they come to the table ;) With kind regards, Henk [-- Attachment #2: Type: text/html, Size: 9054 bytes --]