Cloned from bug 1026466 comment 9: Description of problem: 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 See anaconda-tb file as attachment 821098 [details].
This is probably a Final blocker: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation. " https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Storage_volume_resize I actually don't know whether the resize operation failed itself, or anaconda provided wrong arguments to it. However, crashing while attempting to resize LV is quite bad. (A thought: Because I wanted to reformat it anyway, could it be safer to just remove it and create anew with a different size?)
Discussed at 2013-11-13 blocker review meeting - http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-13/f20-final-blocker-review-1.2013-11-13-17.01.log.txt . Accepted as a blocker per criterion cited in c#1. According to program.log , anaconda for some reason tried to resize the volume to 8GB - the same as its existing size - and this causes lvresize to exit with a non-0 code. anaconda is clearly not correctly attempting 'the requested operation', as it didn't try to resize to 6GB.
While anaconda should not crash, I think it's a separate bug that lvresize doesn't exit with status 0 as it has "nothing to do". It's a null operation, so there can be no failure here.
Status reviewed at 2013-11-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.log.txt . This bug seems to be clearly defined and reproducible and is now just waiting in the queue to be fixed by anaconda devs.
Please retest with 20-TC2 and report the results.
I verified that this is fixed in F20 TC2.
anaconda 20.25.9-1.fc20 is now stable, closing.