Description of problem: Existing LVM configurations detected by blivet show existing VGs as having their full capacity available in spite of any existing LVs. This is due to a regression introduced when fixing bug 1013800. Version-Release number of selected component (if applicable): python-blivet-0.23.3-1 How reproducible: Always Steps to Reproduce: 1. create an anaconda automatic partitioning layout (write it to disk) 2. reboot into the installer using the same disk(s) 3. in the custom storage spoke, create a new LV Actual results: A new LV will be added with up to the full size of the VG even though the VG is already full. Expected results: Creation of a new LV should fail due to the disk(s) and VG being full. Additional info:
I have a patch for this and have verified that it fixes this problem.
When someone tries to continue with installation, anaconda crashes with "DeviceCreateError: ('lvcreate failed for fedora/root00: running lvm lvcreate -L 15496m -n root00 fedora failed', 'fedora-root00')". It shows as bug 1021507 in ABRT. I will not mark bug 1021507 as duplicate, because it seems that it is different bug.
*** Bug 1025911 has been marked as a duplicate of this bug. ***
Discussed in 2013-11-06 Blocker Review Meeting [1]. Voted an AcceptedBlocker. This bug lets user to set a layout which cannot be created. Also it violates 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 partitions." [2] [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-06/ [2] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Custom_partitioning
python-blivet-0.23.4-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/python-blivet-0.23.4-1.fc20
If I understand the description correctly, verified the fix in pre-RC5 smoke testing of 0.23.4.
When I tried to verify this bug I've hit bug 1027682.
With a much simpler test case this works correctly, therefore verified.
I tried to reproduce bug 1027682 or bug 1008732. I might have found yet another bug. Reproducer: 1. Install a default Fedora LVM install - /boot as standard partition, swap and / as LVM. 2. Reboot into installer again. 3. Go into custom part and reuse /boot and swap. 4. Click on /, click Reformat and also resize it (I used 6 GB instead of original 8 GB). Click Apply. 5. See that the size was _not_ updated (that's probably related to bug 1027714). 6. Continue with install. See crash during installation start. Please note that when I performed the same steps as above, but without the attempt to resize /, everything worked well. cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2020-Beta\x20x86_64 quiet BOOT_IMAGE=vmlinuz hashmarkername: anaconda kernel: 3.11.6-301.fc20.x86_64 package: anaconda-20.25.6-1 product: Fedora reason: LVMError: lvresize failed for root: running lvm lvresize --force -L 8712m fedora/root failed release: Cannot get release name. version: 20-Beta
Created attachment 821098 [details] anaconda-tb 20.25.6 related to comment 9
In comment 9 ABRT found that crash to be a duplicate of bug 1025911 which is a duplicate of this bug. So, unless it was matched by a mistake, this is not fixed. Reopening.
I have reproduced comment 9 by following the exactly same steps. Seems to happen reliably.
The issue reported in comment 9 is not the same as the problem reported initially in this bug. Please open a separate report with the logs and update the status of this bug as appropriate. Thanks.
(In reply to David Lehman from comment #13) > The issue reported in comment 9 is not the same as the problem reported > initially in this bug. Please open a separate report with the logs and > update the status of this bug as appropriate. Thanks. OK. Reported as a separate bug 1028110.
python-blivet-0.23.4-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.