Bug 1158533

Created attachment 951817 [details]
File: anaconda-tb

Created attachment 951818 [details]
File: anaconda.log

Created attachment 951819 [details]
File: environ

Created attachment 951820 [details]
File: journalctl

Created attachment 951821 [details]
File: lsblk_output

Created attachment 951822 [details]
File: nmcli_dev_list

Created attachment 951823 [details]
File: os_info

Created attachment 951824 [details]
File: program.log

Created attachment 951825 [details]
File: storage.log

Created attachment 951826 [details]
File: ifcfg.log

this is second time I have seen this.
Looks like 2 USB HD's plugged in causes failure.

Proposed as a Freeze Exception for 21-final by Fedora user satellit using the blocker tracking app because:

 The installer must be able to complete an installation using all supported interfaces 
anaconda 21.48.13-1

(In reply to Fedora Blocker Bugs Application from comment #12)
> Proposed as a Freeze Exception for 21-final by Fedora user satellit using
> the blocker tracking app because:
> 
>  The installer must be able to complete an installation using all supported
> interfaces 
> anaconda 21.48.13-1

Unplug 2nd USB HD and installs fine

Another user experienced a similar problem:

I run installation. Only thing I did is: I chose both my disk for installation (with delete all) and then I changed my mind and went to installation destination again but this time I chose just one disk (with delete all). Then I started installation. This bug apeared during formating (I think).

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   initrd=initrd0.img root=live:UUID=5982-5591 rootfstype=vfat ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 nomodeset BOOT_IMAGE=vmlinuz0 
hashmarkername: anaconda
kernel:         3.17.1-302.fc21.x86_64
other involved packages: python-blivet-0.61.8-1.fc21.noarch, python-libs-2.7.8-4.1.fc21.x86_64
package:        anaconda-core-21.48.13-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         LVMError: lvactivate failed for swap: running lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] filter=["r|/fedora_dhcp-29-208$|","r|/sdb1$|","r|/sdb$|"] }  fedora_dhcp-28-114/swap failed
release:        Fedora release 21 (Twenty One)
version:        Fedora

So, here is what's going on on my computer.

I have two disks: On the first one there is the default installation of Fedora 21. sda1 is /boot and sda2 is LVM with root and swap.
On the second disk there is one LVM which is there from old installation of Fedora (original installation was on two disks with one big LVM. Then the new installation took place on the first disk and second disk was untouched by that).

When I go to installation destination for the first time I choose both disks and in reclaim space I click on delete all and confirm. There seems to be everything alright in reclaim space dialog (see first attached picture). Then when I change my mind I go to installation destination again. This time I choose only first disk and second one I leave unchecked. The reclaim space dialog is opened again, but this time there is one error. sda1 and sda2 are swapped. Anaconda shows that there is lvm on sda1 and /boot on sda2 (see second attached screenshot). After I click on delete all, confirm and I start the installation it fails.

Created attachment 952037 [details]
reclaim space dialog when opened for the first time

Created attachment 952039 [details]
reclaim space dialog when opened for the second time with just first disk

I propose this as beta blocker as it violates the criterion: "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 
* Remove existing storage volumes to free up space, at the user's direction"

I tested this with another computer with two disks. And I wasn't able to reproduce this bug. The difference seems to be that on the pc where this bug happens is gpt table on /dev/sda but there is mbr on the second pc's /dev/sda.

I reproduced this using virtual machine with two disks (both with mbr). Both have to be full so reclaim space dialog is used.

See https://pschindl.fedorapeople.org/bug1158533.ogv - mention the layout of the first disk during first and second reclaim space.

Created attachment 952142 [details]
anaconda.log

Created attachment 952143 [details]
traceback

Created attachment 952146 [details]
program.log

Created attachment 952147 [details]
storage.log

Another user experienced a similar problem:

Tried to install Fedora on system with two disks, each with two partitions. Selected both disks to install, selected "delete all" in reclaim dialog, changed my mind, unselected second disk, "delete all" in reclaim dialog and run installation.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-21_B-x86_64 quiet
hashmarkername: anaconda
kernel:         3.17.1-302.fc21.x86_64
package:        anaconda-21.48.13-1
product:        Fedora"
reason:         LVMError: lvactivate failed for root: running lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] filter=["r|/vda1$|","r|/vda2$|","r|/vda$|"] }  fedora-server/root failed
release:        Cannot get release name.
version:        Fedora

It would be very useful to know if anyone can reproduce this without the 'change my mind and do it differently' bit, My inclination is to vote -1 blocker on a bug which involves running through the spoke multiple times and changing your mind, at this point.

AFAIK, it always involved running through the spoke multiple times. None of us reproduced in just a single pass.

satellit said his case did not involve multiple runs, for the record. kparal, do you have the logs from your reproducers?

Discussed at 2014-10-30 Go/No-Go meeting: http://meetbot.fedoraproject.org/fedora-meeting-2/2014-10-30/f21_beta_gono-go_meeting.2014-10-30-17.00.log.txt . Rejected as a blocker on the basis that the clear reproducer we have for this involves multiple runs through the spoke - we generally don't consider that kind of thing to block Beta, especially when it's a last-minute discovery (tending to indicate it's not very commonly encountered).

satellit says his case doesn't involve multiple trips, but disconnecting one disk makes it work, and it seems like it may be a known case where multiple connected disks have identically-named LVs, which is hard for anaconda to handle.

(In reply to Adam Williamson (Red Hat) from comment #28)
> satellit said his case did not involve multiple runs, for the record.
> kparal, do you have the logs from your reproducers?

Petr Schindler already appended those in comments 21 - 24. Do you need anything else?

Re-proposing as Final blocker.

Discussed at 2014-11-05 blocker review meeting [1]. Accepted as a blocker. This bug violates the beta criterion "Complete an installation using any combination of disk configuration options it allows the user to select" in the case you change your mind.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-05/

This is kind-of-duplicate of Bug 1022811.

Anaconda allows you to select one disk from VG spanning over multiple PVs which will cause all kind of troubles - e.g. duplicate VG names and other.

10:55:21,338 INFO program:   LVM2_PV_NAME=/dev/sdb2 LVM2_PV_UUID=OjAQnD-rPDX-6uJ9-wRIc-MoZ1-AdAW-vaQ3Tu LVM2_PE_START=1024.00 LVM2_VG_NAME=fedora LVM2_VG_UUID=hK0yhR-x185-w6cJ-8REZ-0fL7-9j9j-z5IodX LVM2_VG_SIZE=116703232.00 LVM2_VG_FREE=65536.00 LVM2_VG_EXTENT_SIZE=4096.00 LVM2_VG_EXTENT_COUNT=28492 LVM2_VG_FREE_COUNT=16 LVM2_PV_COUNT=1
10:55:21,338 INFO program:   LVM2_PV_NAME=/dev/sdc2 LVM2_PV_UUID=xVgWhI-d9Pu-2yps-nSTC-2mha-zc4U-jul7o9 LVM2_PE_START=1024.00 LVM2_VG_NAME=fedora LVM2_VG_UUID=GPlG97-ZoTO-pGKK-0kb3-J1Cf-y0f7-Ab0KcF LVM2_VG_SIZE=487870464.00 LVM2_VG_FREE=65536.00 LVM2_VG_EXTENT_SIZE=4096.00 LVM2_VG_EXTENT_COUNT=119109 LVM2_VG_FREE_COUNT=16 LVM2_PV_COUNT=1

Hello anaconda devs, is there any progress on this? Thanks for info.

Another user experienced a similar problem:

Tried to reproduce bug 1158533 with one disk. Had one disk with two partitions - /boot (vda1) and / (vda2). Went to partitioning spoke, selected that disk for installation, clicked done, clicked "delete all" on reclaim space dialog. Then went to partitioning spoke again, unselected that disk and clicked "done". Finally, went to partitioning spoke again, selected that disk again and clicked "done". In reclaim space dialog, both partitions had swapped names (/boot was vda2 and / was vda1). When I started installation, this showed up.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-21_T2-x86_64 quiet
hashmarkername: anaconda
kernel:         3.17.2-300.fc21.x86_64
package:        anaconda-21.48.14-1
product:        Fedora"
reason:         LVMError: lvactivate failed for root: running lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] }  fedora-server/root failed
release:        Cannot get release name.
version:        Fedora

Created attachment 959379 [details]
anaconda traceback

Created attachment 959380 [details]
storage.log

Another thing is that it seems that to reproduce this bug, LVM should be valid. I have booted same machine again, I have same partitioning on it, but parted doesn't display first partition as "/boot" and second partition as LVM. If I try select-unselect-select combo, partitions are again swapped in reclaim space dialog, but installation proceeds without problem.

(In reply to Marian Csontos from comment #32)
> Anaconda allows you to select one disk from VG spanning over multiple PVs
> which will cause all kind of troubles - e.g. duplicate VG names and other.

I don't know if there are more bugs that has caused this, but I had only one PV but this still happened to me.

Forgot to mention: vda1 was normal partition (with ext4 I think) and vda2 was LVM partition (showed actually as "fedora-server", not "/" in reclaim space dialog).

I am not sure anaconda manipulates lvm.conf in any way, but I see lot of lines like this in lvm2 commands' output:

    13:59:54,504 INFO program:   WARNING: Ignoring duplicate config node: global (seeking global/metadata_read_only)

Could you submit /etc/lvm/lvm.conf please?

Looking further this looks intersting:

08:00:32,915 INFO program: Running... lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] }  fedora-server/root
08:00:32,999 INFO program:   Volume group "fedora-server" not found
08:00:33,000 INFO program:   Skipping volume group fedora-server

I wonder what exactly is wipefs erasing LVM's PV doing here?

08:00:32,616 INFO program: Running... wipefs -f -a /dev/vda2
08:00:32,732 INFO program: /dev/vda2: 8 bytes were erased at offset 0x00000218 (LVM2_member): 4c 56 4d 32 20 30 30 31
08:00:32,733 DEBUG program: Return code: 0

Oh! It is trying to destroy /boot which is actually on /dev/vda1! BINGO Jan, you nailed it, except it is different bug than the original reported, but the same Petr Schindler reported.

Here is the lvchange's output:

07:56:51,721 INFO program: Running... lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] filter=["r|/sda1$|","r|/sda2$|","r|/sda3$|","r|/sda$|","r|/sdc1$|","r|/sdc2$|","r|/sdc$|"] }  fedora/home
07:56:51,760 INFO program:   No device found for PV xVgWhI-d9Pu-2yps-nSTC-2mha-zc4U-jul7o9.
07:56:51,761 INFO program:   Refusing activation of partial LV fedora/home.  Use '--activationmode partial' to override.
07:56:51,761 DEBUG program: Return code: 5

How to handle? I think there are three options:

When reusing an existing VG:
- always use all disks from the VG

When user wants to get rid of VG:
- need to use all disks too

When user wants to use a disk(s) from existing VG keeping the VG:
- Optionally: remove LVs
- Mandatory: use pvmove and vgreduce
- Question is why not reusing the existing VG? Perhaps user wants separate /boot partition on the disk or different configuration of RAID for this installation...

Also VG names in single system should not be duplicated (fedora names the VG fedora - possible unbootable system): it would be safer to either:

- filter used during installation should be propagated to installed system's lvm.conf
- scan disks for VG names

Marian split this into two bugs - this one now only concerns the comment 0 use case, and bug 1166598 concerns Petr's and Jan's use case. Because only the latter use case was already accepted as a Final blocker, I leave bug 1166598 as accepted and I remove the decision from this bug, moving it back to the proposed state.

Discussed at 2014-11-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-24/f21-blocker-review.2014-11-24-17.01.log.txt .  Agreed to delay decision on this one as it's not entirely clear what the trigger for satellit's case is - the case that was split out into #1166598 is now well-understood, but no-one was entirely sure how to trigger satellit's case.

We will try to reproduce it ahead of the next blocker meeting on Wednesday so we can make a determination. First thing to try is a guided installation F20 or F21 with multiple disks, then try to install F21 again with the same disks connected but only one chosen as an install target.

I tried to reproduce comment 0, this is what I did:

1. Installed F21 on two disks using guided part and LVM
2. Reinstalled F21 when selecting just the first disk, using guided part and deleting all contents from the reclaim dialog
and
1. Installed F21 on two disks using guided part and LVM
2. Reinstalled F21 when selecting just the second disk, using guided part and deleting all contents from the reclaim dialog

In both cases, everything worked correctly and the reinstalled system booted.

I tried once again the same approach, this time using manual partitioning. Again everything worked. Please note that in the manual partitioning dialog, the existing (partial) LVM is grayed out and cannot be reused, only deleted. Which seems correct.

satellit, can you please provide very detailed steps of how you triggered this issue? Thanks.

I'd just like to add information that while testing fix for bug #1166598 I've performed installations on one disk from a multi-disk VG without any issues.

I tried also the use case of physically removing a disk:

1. Installed F21 on two disks using guided part and LVM
2. Physically removed one of the disks
3. Reinstalled F21 (deleted all previous contents)

I tried this for both the disks, and for guided and manual part (all combinations). Everything worked. Again, there was no option to reuse the LVM, just to delete it.

Discussed in 2014-11-26 Blocker Review Meeting [1]. Voted as an RejectedBlocker. This bug doesn't seem to be reproducible and no new reports have come in confirming this bug.
 
[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2014-11-26/

It must be the LV spanning multiple disks so it becomes "partial".

(In reply to Marian Csontos from comment #49)
> It must be the LV spanning multiple disks so it becomes "partial".

Not sure what this comment is related to. That's the layout I had when trying to reproduce this issue.

Note *LV* not *VG*: Marian's suggesting the bug only happens if you have a single LV within the VG that *itself* spans multiple disks. Just to be super-sure, is that the config you tested with?

Yes. My root partition was larger than any of the disks attached, so it must have spanned both of them.

Another user experienced a similar problem:

1. booted from live cd
2. from live cd selected install to disk
3.  Deleted all disk partitions from previous Linux Mint install on hard disk.
4.  Received the message during the install.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Workstation-x86_64-2 ro rd.live.image quiet rhgb
hashmarkername: anaconda
kernel:         3.17.1-302.fc21.x86_64
other involved packages: python-blivet-0.61.8-1.fc21.noarch, python-libs-2.7.8-4.1.fc21.x86_64
package:        anaconda-core-21.48.13-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         LVMError: lvactivate failed for root: running lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] }  mint-vg/root failed
release:        Fedora release 21 (Twenty One)
version:        Fedora

Follow up re-running and it worked second time. Odd, assume something got cleaned up the first time.

Another user experienced a similar problem:

tying to install fedora 21 on my laptop
i formated my harddrive , I think that might be the problem, but not sure.
Useing a live dvd for installation

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-WS-x86_64-21-5 ro rd.live.image quiet rhgb rd.live.check
hashmarkername: anaconda
kernel:         3.17.4-301.fc21.x86_64
other involved packages: python-blivet-0.61.13-1.fc21.noarch, python-libs-2.7.8-7.fc21.x86_64
package:        anaconda-core-21.48.21-1.fc21.x86_64
packaging.log:  
product:        Fedora"
reason:         LVMError: lvactivate failed for root: running lvm lvchange -a y --config  devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] }  fedora_localhost/root failed
release:        Fedora release 21 (Twenty One)
version:        Fedora

*** This bug has been marked as a duplicate of bug 1209223 ***

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days