[linux-lvm] Failed to update old PV extension headers in VG

[linux-lvm] Failed to update old PV extension headers in VG

[Henk Kraal]

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

Re: [linux-lvm] Failed to update old PV extension headers in VG

[David Teigland]

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

Re: [linux-lvm] Failed to update old PV extension headers in VG

[Henk Kraal]

[-- 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 --]