Bug 799501

Created attachment 521000 [details]
YaST error message when trying to remove VGroup

Exit code 5 means:
"can't remove volume group containing logical volumes"

It looks like YaST does not remove logical volumes contained inside the vgroup first. Hence, either remove them prior to removing a volume group or use the "--force" parameter with the call of 'vgremove'.

Please provide YaST logs, see http://en.opensuse.org/openSUSE:Bugreport_YaST.

Created attachment 521102 [details]
YaST2 logs

The YaST logs show that YaST does remove the 6 logical volumes present
before removing the volume group. There is even a vgdisplay call right
before the vgremove call showing that no logical volumes are left.

Looks like a LVM problem.

Yes, you are right. I apologize for pointing the finger at YaST too quickly! I actually assumed YaST was not removing LVs simply due to the explanation of exit code 5, without looking at the logs.

I see that lvm2.02.98 is the latest version out there. Hence I sent an email to the linux-lvm list.

Should this report be reassigned?

Testing this in VirtualBox shows that openSUSE 12.3 Beta 1 using
  LVM version:     2.02.98(2) (2012-10-15)
  Library version: 1.02.77 (2012-10-15)
  Driver version:  4.23.0
fails to remove an empty volume group using 'vgremove VG' (exit code 5)

But openSUSE 12.2 (DVD)
  LVM version:     2.02.84(2) (2011-02-09)
  Library version: 1.02.63 (2011-02-09)
  Driver version:  4.22.0
succeeds to remove an empty volume group using 'vgremove VG' (exit code 0)

I sent a message to Linux-LVM mailing list:
https://www.redhat.com/archives/linux-lvm/2013-January/msg00015.html

After some IRC discussions, the problem seems to be that in openSUSE 12.3 installation, /etc/lvm to /mounts/mp_0000/etc/lvm/, which is mounted read-only.
In openSUSE 12.2 installation, /etc/lvm was writable!

See IRC log below:
----------------
[12:04] <kabi_> jbrauchle: hi - do you have writeble  /etc/lvm ?
[12:07] <jbrauchle> No, /etc/lvm symlinks to /mounts/mp_0000/etc/lvm/, which is mounted read-only
[12:07] <kabi_> yep - that's the problem
[12:08] <kabi_> there is missing error message
[12:08] <kabi_> disable -A n  
[12:08] <kabi_> with your vgremove
[12:08] <mcsontos> jbrauchle, you need to edit lvm.conf so backup_dir and archive_dir points to R/W location
[12:08] <mcsontos> jbrauchle, that should do the trick
[12:09] <mcsontos> More than that, I am surprised lvremoves succeeded
[12:09] <kabi_> mcsontos: he uses -A n for lvremove
[12:09] <mcsontos> OIC
[12:10] <jbrauchle> ok... so then, if I understand correctly: If openSUSE 12.2 installation works OK with exactly the same setup (root FS also read-only), there must be something wrong lvm.conf?
[12:11] <mcsontos> jbrauchle, or in installer
[12:11] <mcsontos> jbrauchle, e.g. FS mounted RO while it used to be R/W
[12:12] <kabi_> jbrauchle: there could be   backup{archive=0}  in lvm.conf
[12:12] <mcsontos> or so
[12:12] <jbrauchle> ok thanks! I will double check the difference from 12.2 to 12.3
[12:12] <kabi_> jbrauchle: any  backup{backup=0} as well
[12:12] <kabi_> (and)
[12:14] <jbrauchle> ok, you're right. On 12.2 /etc/lvm is writeable!
----------------

The problem still exists in 12.3 RC1.

If this cannot be fixed until 12.3 final, it may prevent users with existing LVM partitions from upgrading successfully.

bnc#781402 is very similar to this.
adding 'udevadm settle' before vgremove could prevent race conditions

Well, as I can't view bnc#781402 I can't judge if its similar...

From my limited knowledge of whats happening, I understand that LVM
a) needs a writable path to store archives and backups of metadata. Usually this defaults to /etc/lvm/{archive,backup}, but this is mounted read-only in the inst-sys of 12.3 (was read-write in 12.2)

OR

b) must be told to not create archives or backups of metadata in /etc/lvm.conf like so:
------------
backup {

    # Should we maintain a backup of the current metadata configuration ?
    # Use 1 for Yes; 0 for No.
    # Think very hard before turning this off!
    backup = 0

    # Should we maintain an archive of old metadata configurations.
    # Use 1 for Yes; 0 for No.
    # On by default.  Think very hard before turning this off.
    archive = 0
}
------------

So I guess option a) would be more sane...

(In reply to comment #11)
> Well, as I can't view bnc#781402 I can't judge if its similar...
> 
> From my limited knowledge of whats happening, I understand that LVM
> a) needs a writable path to store archives and backups of metadata. Usually
> this defaults to /etc/lvm/{archive,backup}, but this is mounted read-only in
> the inst-sys of 12.3 (was read-write in 12.2)
> 
> OR

If so, backup_dir and archive_dir could be changed to other directory in lvm.conf.

Because lvremove or vgchange will store metadata backup in /etc/lvm/backup and 
archive previous medadata to /etc/lvm/archives.

I believe changing default location of (backup, archive) could resolve this.
Can you test it again after changing /etc/lvm/lvm.conf?

As /etc/lvm/lvm.conf is also read only, I was unable to change it...

*** Bug 802120 has been marked as a duplicate of this bug. ***

In RC2 is looks like vgremove is called with the '-f' parameter, thus working around this problem. 

I'm not really convinced this is a real fix, as LVM cannot archive/backup any metadata in the current configuration...

(In reply to comment #18)
> In RC2 is looks like vgremove is called with the '-f' parameter, thus working
> around this problem. 
> 
> I'm not really convinced this is a real fix, as LVM cannot archive/backup any
> metadata in the current configuration...

how about my solution in comment#16?
change the backup and archive to /var/log?

(In reply to comment #18)
> In RC2 is looks like vgremove is called with the '-f' parameter, thus working
> around this problem. 
> 
> I'm not really convinced this is a real fix, as LVM cannot archive/backup any
> metadata in the current configuration...

The option -f was added for another issue, see bug #781402.

(In reply to comment #19)

> how about my solution in comment#16?
> change the backup and archive to /var/log?

/var could be on another device and thus be present only later during
booting. This could cause problems. Did you try that?

If the only problem is that /etc/lvm is read-only during installation
ask Steffen Winterfeldt to make it read-write.

I think all the other lvm commands (like lvremove) used by yast use "-A n -f"... hence, there is no archiving of metadata anyway, right?

If so, the newly added "-f" option for vgremove solves this problem.
If not, possibly make "/etc/lvm" writable again as it was in 12.2 and before...?

I don't know whether the -f option changes the archiving of the commands.
At least that is not mentioned in the man-pages.

We added the -f option to remove volume groups that had some inactive
logical volumes due to missing physical volumes.

No, the "-f" option for vgremove itself does not change archiving options, *but* as archiving is currently not possible due to read-only /etc/lvm/ directory, the "-f" option forces the operation to still proceed. Hence, it indirectly contributes to not archiving metadata in the current setup.

Ok, that sounds reasonable.

So /etc/lvm should still be made read-writable.

the priority field is for the developer not for the reporter

Cleaning my bug reports... I think this is resolved (somehow).