[partition reuse] VGs are not deleted

Bug #1837214 reported by Paride Legovini on 2019-07-19
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
subiquity
Critical
Michael Hudson-Doyle

Bug Description

In manual partitioning mode one may want to keep some partitions but throw away a VG, replacing it with a plain partition or with another VG built from scratch.

Subiquity allows for deleting VGs, but this is not actually done. Even if the "deleted" VG disappears, another VG with the same name can't be created (the error is: "vg0 is not a valid name for a volume group"). If the VG has been "deleted" from subiquity and a device which was in the VG is used in another way, the installation fails at format time with the error "device is in use".

In both cases a look in /dev reveals the VG still exists.

If a VG is deleted and not reused the installation does not fail, but the VG comes up configured in the installed system.

Paride Legovini (legovini) wrote :

VGs are not deleted even "reformatting" the device ("Reformat" from the device context menu).

On Sat, 20 Jul 2019, 02:02 Paride Legovini, <email address hidden>
wrote:

> Public bug reported:
>
> In manual partitioning mode one may want to keep some partitions but
> throw away a VG, replacing it with a plain partition or with another VG
> built from scratch.
>
> Subiquity allows for deleting VGs, but this is not actually done. Even
> if the "deleted" VG disappears, another VG with the same name can't be
> created (the error is: "vg0 is not a valid name for a volume group").
>

Ah I know what causes this: you can't create a vg with a name that
already exists in /dev. And subiquity hasn't been taught that the install
might actually remove a device node... Or at least it should.

If

> the VG has been "deleted" from subiquity and a device which was in the
> VG is used in another way, the installation fails at format time with
> the error "device is in use".
>

This is another bug and at least possibly one in curtin although it's also
possible that we're generating a bogus config. Did you save the logs?

In both cases a look in /dev reveals the VG still exists.
>
> If a VG is deleted and not reused the installation does not fail, but
> the VG comes up configured in the installed system.
>

Hmm I guess we need to do something that will cause curtin to run
clear_holders on all the members of an LVM / RAID we delete.

Cheers,
mwh

>

Paride Legovini (legovini) wrote :

Hey Michael,

Michael Hudson-Doyle wrote on 22/07/2019:
>> If the VG has been "deleted" from subiquity and a device which was in the
>> VG is used in another way, the installation fails at format time with
>> the error "device is in use".
>>
>
> This is another bug and at least possibly one in curtin although it's also
> possible that we're generating a bogus config. Did you save the logs?

I didn't, but I think I can easily reproduce this.

> In both cases a look in /dev reveals the VG still exists.

Yes it does, this is why I added this detail in this bug. I think the
root cause is the VG is not deleted, even if it appears to be gone from
the subiquity interface.

Paride

Changed in subiquity:
status: New → Triaged
importance: Undecided → Critical
assignee: nobody → Michael Hudson-Doyle (mwhudson)
tags: added: reuse
Michael Hudson-Doyle (mwhudson) wrote :

My test setup for this has a VG consisting of a single PV consisting of a partition. If I remove the VG, reformat the disk and then create some partitions on it, everything works, the VG is removed and the install completes. But if you remove the VG and then try to reuse the partition somehow, things break as you describe.

I think that Ryan's patch from https://code.launchpad.net/~mwhudson/curtin/+git/curtin/+merge/370028/comments/967403 is relevant here, I'll try that next.

Michael Hudson-Doyle (mwhudson) wrote :

Oh no that doesn't help, because get_device_paths_from_storage_config doesn't return things that have preserve set on them. I think this comes down to the confusion we've talked about before that preserve: true should mean the thing itself is preserved, but curtin interprets it (sometimes, at least) as that the data on the thing should be preserved as well.

I think this will have to be release noted for 18.04.3 as well.

Paride Legovini (legovini) wrote :

Hi Michael, a "Reformat" does seem to help when switching from LVM to partitions, however this is not an option when you want to delete a VG and replace it with another VG.

Steps to reproduce:

 1. At install time, setup a VG named vg0 consisting of a
    entire single device and mount it somewhere
 2. Reboot and start the installer again.
 3. In manual partitioning mode, delete the VG.
 4. Try to recreate a VG on the same device. The name "vg0"
    won't work, because "behind" subiquity the original vg0
    is still alive and well. This is already a bit confusing.
 5. Give up with vg0, name it vg1 and do ahead with installing
 6. The installer fails trying to setup vg1, as its PV is
    still part of vg0

Note that there is no "Reformat" option in this case. After deleting the VG the device appears as "clean" in subiquity. There is only the "Format" option, which formats it with a filesystem , which is not wanted in this case.

Ryan Harper (raharper) wrote :

Can we capture the debug data, probert probe data and the yaml curtin sends to subiquity?

Curtin certainly knows how to clear devices, including vgs; the question is whether subiquity told it to do so.

Paride Legovini (legovini) wrote :

Here are the installer logs in the "replace VG with another VG" scenario, basically the steps in comment #6.

vg1 is composed of disk-sdb, which is set to be preserved instead of being
wiped.

  - serial: QEMU_HARDDISK_QM00002
    path: /dev/sdb
    preserve: true
    name: ''
    grub_device: false
    type: disk
    id: disk-sdb

 - name: vg1
    devices:
    - disk-sdb
    preserve: false
    type: lvm_volgroup
    id: lvm_volgroup-0

I think if subiquity marks the vg as preserve: false, then it needs to
ensure the composition devices are cleared (wipe: superblock) which implies
they cannot also have preserved: true.

On Tue, Jul 23, 2019 at 11:50 AM Paride Legovini <
<email address hidden>> wrote:

> Here are the installer logs in the "replace VG with another VG"
> scenario, basically the steps in comment #6.
>
>
> ** Attachment added: "tarball of /var/log/installer"
>
> https://bugs.launchpad.net/subiquity/+bug/1837214/+attachment/5278733/+files/installer-vg-delete-fail.tar.gz
>
> --
> You received this bug notification because you are subscribed to
> subiquity.
> Matching subscriptions: subiquity-bugs
> https://bugs.launchpad.net/bugs/1837214
>
> Title:
> [partition reuse] VGs are not deleted
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/subiquity/+bug/1837214/+subscriptions
>

On Wed, 24 Jul 2019 at 05:20, Ryan Harper <email address hidden>
wrote:

> vg1 is composed of disk-sdb, which is set to be preserved instead of being
> wiped.
>
> - serial: QEMU_HARDDISK_QM00002
> path: /dev/sdb
> preserve: true
> name: ''
> grub_device: false
> type: disk
> id: disk-sdb
>
> - name: vg1
> devices:
> - disk-sdb
> preserve: false
> type: lvm_volgroup
> id: lvm_volgroup-0
>
> I think if subiquity marks the vg as preserve: false, then it needs to
> ensure the composition devices are cleared (wipe: superblock) which implies
> they cannot also have preserved: true.
>

Right, this line of thinking is what lead directly to me filing
https://bugs.launchpad.net/curtin/+bug/1837487 :)

tags: added: id-5d645a2e2be6213e05b2df9a
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers