Bug 1029915

+++ This bug was initially created as a clone of Bug #1022810 +++

Description of problem:
Installing on a system with thin-pool on raid. Crash occured when I selected storage spoke.

Anaconda tries to activate private LVM volume pool_tdata.

Version-Release number of selected component:
anaconda-20.25.1-1

The following was filed automatically by anaconda:
anaconda 20.25.1-1 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.7/site-packages/blivet/devicelibs/lvm.py", line 439, in lvactivate
    raise LVMError("lvactivate failed for %s: %s" % (lv_name, msg))
  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 2684, in _setup
    lvm.lvactivate(self.vg.name, self._name)
  File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 718, in setup
    self._setup(orig=orig)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1314, in addLV
    lv_device.setup()
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1337, in handleVgLvs
    addLV(*lv_data[i])
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1424, in handleUdevLVMPVFormat
    self.handleVgLvs(vg_device)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1711, in handleUdevDeviceFormat
    self.handleUdevLVMPVFormat(info, device)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1075, in addUdevDevice
    self.handleUdevDeviceFormat(info, device)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1936, in _populate
    self.addUdevDevice(dev)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1880, in populate
    self._populate()
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 417, in reset
    self.devicetree.populate(cleanupOnly=cleanupOnly)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 144, in storageInitialize
    storage.reset()
  File "/usr/lib64/python2.7/threading.py", line 764, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
LVMError: lvactivate failed for [pool_tdata]: running lvm lvchange -a y vg_stacked/[pool_tdata] failed

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   method=http://10.34.48.241/fedora/linux/development/20/x86_64/os/  ks=http://192.168.144.1/stackerr.f20i.ks
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.11.6-300.fc20.x86_64
product:        Fedora
release:        Cannot get release name.
type:           anaconda
version:        20

--- Additional comment from Marian Csontos on 2013-10-24 02:17:55 EDT ---

Suggesting as blocker not meeting following requirement:

>  Guided partitioning
>
> When using the guided partitioning flow, the installer must be able to:
> 
> - Complete an installation using any combination of disk configuration
>   options it allows the user to select 

At least it does not eat data :-)

--- Additional comment from Mike Ruckman on 2013-10-24 13:31:43 EDT ---

Discussed in 2013-10-24 Go/NoGo meeting [1]. Accepted as a blocker for violating Custom Partitioning beta criterion: "When using the custom partitioning flow, the installer must be able to: [...] Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions"

[1] http://meetbot.fedoraproject.org/meetbot/fedora-meeting-2/2013-10-24/
[2] http://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Custom_partitioning

--- Additional comment from David Lehman on 2013-10-24 15:04:07 EDT ---

You created a thin pool with segment type raid1 outside the installer?

--- Additional comment from Marian Csontos on 2013-10-25 01:30:08 EDT ---

Yes, I have tried to install Fedora on a machine which already had got a pool on RAID1:

    lvcreate -n pool -L 6G -m 2 --type raid1 vg_stacked
    lvcreate -n poolmeta -L 256M -m 2 --type raid1 vg_stacked
    lvconvert --thinpool vg_stacked/pool --poolmetadata vg_stacked/poolmeta
    lvcreate -T -n lv_master --virtualsize 4G vg_stacked/pool

-- Martian

--- Additional comment from Adam Williamson on 2013-10-29 12:12:28 EDT ---

For blocker review purposes: as per the last couple of comments, this is not anaconda falling over its own LVM thinp creation logic or barfing on a layout it created itself on an earlier run. This is anaconda crashing when encountering a very unusual LVM layout that was created by the user outside of anaconda, that anaconda itself is not capable of creating.

Looking at the blocker review meeting where this bug was considered - http://meetbot.fedoraproject.org/meetbot/fedora-meeting-2/2013-10-24/f20_beta_gono-go_meeting.2013-10-24-17.01.log.html - I don't think this was fully understood when the bug was accepted as a blocker. So I'm proposing it to be re-discussed.

dlehman thinks the criterion cited may be more broad than it was intended to be: it implies that anaconda must be able to read absolutely any valid LVM layout, which is apparently a very wide scope. I believe our intent was more that it should be able to interpret commonly-encountered LVM layouts, or just LVM layouts that it is itself capable of creating. We're going to look at ways of improving that criterion.

--- Additional comment from Adam Williamson on 2013-10-29 12:13:52 EDT ---

<dlehman> adamw: if we must support anything lvm can do, holy hell
<dlehman> lvm is the emacs of storage
<dlehman> I'd be happy to make an explicit list of supported lvm configurations if you'll put it in the criteria
<adamw> sure, we can do that
<adamw> but anyway, yeah, i think the discussion on that bug was a little off-base, i think they were thinking this was anaconda tripping over itself or at least over a layout it had itself created, not one that had been stuffed in from outside
<dlehman> yeah, this is lvs created with non-standard segment types, which anaconda does not do at all

--- Additional comment from Mike Ruckman on 2013-10-30 12:36:36 EDT ---

Discussed in 2013-10-30 Blocker Review Meeting [1]. Voted a RejectedBlocker. The crash occurs in a very special use case when a special kind of LVM is used. It is not possible to create this LVM layout in anaconda itself, it must be pre-created in advance using other tools. We believe this is not serious enough violation to block Beta.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-30/

--- Additional comment from Marian Csontos on 2013-11-04 12:24:58 EST ---

Sorry to bother again but I would like to ask you to reconsider if not for Beta blocker than for Final blocker.

Rationale:

1. Anaconda UI may not be able to create such a configurations which is already a major drawback but accepted as long as one can create storage layout manually and reread it which is as I understand a supported feature.

But it MUST be much more robust and MUST not blow on meaningful storage configurations or we risk more advanced users will be disqualified from using it which should not be an acceptable limitation and any such limitation must be addressed.

2. This is a configuration seen by lvm-team as one of preferred device stacks.

Using whole VG on a single md-raid device is not only much less flexible but is just wrong as for example for thin-metadata any other RAID level than RAID1 does not make much sense (metadata should be on fastest available storage and redundancy is strongly recommended and RAID{4,5,6} are not good for speed.)

My Conclusion:

As there is no other installation tool anaconda MUST try much harder to cater for everyone not only for low-end.

--- Additional comment from Marian Csontos on 2013-11-13 09:04:17 EST ---

The patch works for me (except it uncovers another systemd/udevd/lvm related issues during system boot.)

--- Additional comment from Marian Csontos on 2013-11-13 09:10:30 EST ---

I would like to ask you to reevaluate this bug as it is an issue which can not be worked around except by changing disk layout on system.

David, could you review the one-line fix, please?