Red Hat Bugzilla – Bug 1028110
LVMError: lvresize failed for root: running lvm lvresize --force -L 8712m fedora/root failed
Last modified: 2013-11-26 05:15:06 EST
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.
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
reason: LVMError: lvresize failed for root: running lvm lvresize --force -L 8712m fedora/root failed
release: Cannot get release name.
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. "
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.