Description of problem: I had old LVM partition scheme on my disk. I have resized old root partition to some big number (130 GB on my 20 GB disk), accepted changes (ran without problem), and then tried to resize it back to old value and this showed up. Version-Release number of selected component: anaconda-20.25.6-1 The following was filed automatically by anaconda: anaconda 20.25.6-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 581, in __init__ raise ValueError("new size same as old size") File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 1250, in resizeDevice self.devicetree.registerAction(action_class(device, new_size)) File "/usr/lib/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1454, in _save_right_side self.__storage.resizeDevice(device, size) File "/usr/lib/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 2802, in on_apply_clicked self._save_right_side(self._current_selector) ValueError: new size same as old size Additional info: cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2020-Beta\x20i386 rd.live.check quiet BOOT_IMAGE=vmlinuz executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.11.6-301.fc20.i686 product: Fedora release: Cannot get release name. type: anaconda version: 20-Beta Potential duplicate: bug 868698
Created attachment 821104 [details] File: anaconda-tb
Created attachment 821105 [details] File: anaconda.log
Created attachment 821106 [details] File: environ
Created attachment 821107 [details] File: lsblk_output
Created attachment 821108 [details] File: nmcli_dev_list
Created attachment 821109 [details] File: os_info
Created attachment 821110 [details] File: program.log
Created attachment 821111 [details] File: storage.log
Created attachment 821112 [details] File: syslog
Created attachment 821113 [details] File: ifcfg.log
Created attachment 821114 [details] File: packaging.log
I am using Fedora F20 Beta RC5.
This fails: " Reject or disallow invalid disk and volume configurations without crashing. " https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Custom_partitioning Anaconda should not allow to create a partition larger than disk and then crash.
Steps to reproduce: 1. Install Fedora using default LVM partition scheme. 2. Boot F20 anaconda installer. 3. Choose custom partitioning. 4. Resize existing root partition to bigger size than your disk have (130 GB) and click "update settings". It shows that root will have 130 GB. 5. Resize your root partition back to old size.
Discussed in the 2013-11-07 Go/No-Go meeting [1]. Voted as a RejectedBlocker. While unfortunate, this is a resize issue at heart and that is not covered by the F20 beta release criteria and thus, is rejected as a release blocking issue for fedora 20 beta. Please re-propose as a F20 final blocker and mark for inclusion in CommonBugs [1] http://meetbot.fedoraproject.org/meetbot/meetbot/fedora-meeting-2/2013-11-07/
Proposed as a Blocker for 20-final by Fedora user jsedlak using the blocker tracking app because: Any installer mechanism for resizing storage volumes must correctly attempt the requested operation.
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 "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." - it may instead be "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation." or "Custom partitioning: Reject or disallow invalid disk and volume configurations without crashing." depending on the exact cause of the crash, but we're solidly agreed that it ought to be a blocker.
anaconda-20.25.8-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.25.8-1.fc20
Package anaconda-20.25.8-1.fc20, pykickstart-1.99.46-1.fc20, python-blivet-0.23.5-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-20.25.8-1.fc20 pykickstart-1.99.46-1.fc20 python-blivet-0.23.5-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-21553/pykickstart-1.99.46-1.fc20,python-blivet-0.23.5-1.fc20,anaconda-20.25.8-1.fc20 then log in and leave karma (feedback).
It still doesn't work. If you try to resize existing partition to lower value and back (for example 13 GB -> 1 GB (update settings) -> 13 GB (update settings)), it shows the same traceback.
jan: how did you test? the new anaconda is not in any build yet (it will be in TC2 when that lands).
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 . We'd like to double-check with Jan that he actually tested 20.25.8 (e.g. by updating it on a live image), and didn't assume that it was present in TC1 or anything.
This is not fixed, but the fix is fairly simple.
Best ask bcl to edit the update and mark it as not fixing this bug any more, then, or else Bodhi will continue to update the status and eventually close it.
(In reply to Adam Williamson from comment #21) > jan: how did you test? the new anaconda is not in any build yet (it will be > in TC2 when that lands). Booted F20 TC1 Live and updated anaconda to 20.25.8-1 via yum.
Updates image available for testing (against 20-TC2): http://dlehman.fedorapeople.org/updates/updates-1121.0.img It should handle setting the size back to its original value by cancelling all scheduled resize actions on the device.
pykickstart-1.99.46-1.fc20, python-blivet-0.23.5-1.fc20, anaconda-20.25.9-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to David Lehman from comment #26) > Updates image available for testing (against 20-TC2): > > http://dlehman.fedorapeople.org/updates/updates-1121.0.img > > It should handle setting the size back to its original value by cancelling > all scheduled resize actions on the device. David, this is still not correct. Anaconda no longer crashes, but it is impossible to set the partition back to its original value. Reproducer: 1. Go to custom part, click on existing root partition (6 GB). 2. Change size to 7 GB, click Update, see it updated correctly. 3. Change size to 6 GB, click Update, see the number reverted to 7 GB. 4. Change size to 5 GB, click Update, see it updated correctly. 5. Change size to 6 GB, click Update, see the number reverted to 5 GB.
Created attachment 828645 [details] anaconda.log (updates-1121.0.img)
Created attachment 828646 [details] program.log (updates-1121.0.img)
Created attachment 828647 [details] storage.log (updates-1121.0.img)
Still present in F20 TC3.
Confirmed fixed in TC4.
(In reply to Dan Mossor from comment #33) > Confirmed fixed in TC4. No, comment 28 still applies and crashes anaconda.
anaconda-20.25.14-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/anaconda-20.25.14-1.fc20
Package anaconda-20.25.14-1.fc20, python-blivet-0.23.8-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-20.25.14-1.fc20 python-blivet-0.23.8-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22800/python-blivet-0.23.8-1.fc20,anaconda-20.25.14-1.fc20 then log in and leave karma (feedback).
I have tested it with TC5 and it seems to work now. Verified.
No, this is still broken as per comment 28 - standard partitions, the same steps apply. Furthermore, I received a crash (bug 1039503) when I tried to reproduce this.
Please see attachment 834296 [details] to see a video of the problem.
Created attachment 834297 [details] bug demonstration video for LVM This is the video of the same performed with LVM. To summarize: Standard partitions: 1. Can resize up and down, but can't go back to original size. 2. Once mounted, can resize up but can't downsize (neither revert). LVMs: 1. Can resize down (and revert, even to original size), but can't resize up. 2. Once mounted, can't resize at all. I can create separate bug reports for selected problems, if you wish.
Created attachment 834484 [details] logs for standard partitions problem - comment 38 and 39 Attaching logs for failed use cases (comment 38 - 40). I wanted to split the report into separate cases, but bugzilla is broken today and I can't create new bugs. I also don't want to spam it here with a dozen new attachments. So I decided the attach the logs compressed, hope you don't mind.
Created attachment 834488 [details] logs for lvm problem - comment 40
anaconda-20.25.14-1.fc20, python-blivet-0.23.8-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
So this is getting confused due to the bugzilla problems, and I still can't file a new bug right now. But to focus on the initial report, dlehman has just told me he thought the initial problem was fixed, but I and kparal assert that it is not. I have reproduced it as in kparal's video. To reproduce: 1. Boot F20 Final TC5 on a system with an existing storage volume (at least ext4 and LVM VG are affected). 2. Go to custom partitioning (with the disk with that volume on selected, obviously). 3. Find the existing storage volume and change 'Desired Capacity' to something else. Hit 'Update Settings'. 4. Change 'Desired Capacity' back to its original value. Hit 'Update Settings' again. This will cause the value to show as the changed value you set in step 3, not the original value you set back in step 4. I have just reproduced this with F20 Final TC5, using a disk containing an existing F20 install with a 500MB ext4 /boot partition. Changing the value to 450 MB, hitting 'Update Settings", then changing it back to 500 MB and hitting 'Update Settings' again leaves the field reading '450 MB'. There is no reproducible crasher that I can see. The other issues kparal found with it not being possible to grow/shrink volumes after assigning a mount point should be considered separate issues we will report separately when we can.
Step 1 in c#44 was incorrect in an important way: turns out LVM is not affected, that's the original case that was reported and fixed. I believe dlehman and I now agree that we're tracking four separate current issues here. weird numbering to match the numbers we started using in IRC, so we don't confuse ourselves. 0) regular filesystems are still broken as per the 'original' bug here: changing the size of an ext4 partition, then changing it back to the original size, does not work correctly. 1) multiple resize actions followed by resetting to original size resets size to the second-to-last size instead of the initial size. 2) scheduling reformat of lv scheduled for resize causes a crash. 3) resize attempts ignored for lvs already scheduled for reformat. ideally we'd have separate reports for each of these, but BZ is not playing ball. Until it is, let's try and track things with those numbers. dlehman and I agree that 0) and 2) are the most important to work on and consider as blockers. We think 1) and 3) are probably FE/F21 stuff rather than F20 blockers. If anyone strongly thinks 1) and/or 3) ought to be considered a blocker, please do reply with justification, but let's try to keep things as clear as we possibly can until we're able to separate the reports, so please be very clear which issue you're talking about at any given time.
Bugzilla works again, so I created the following bug reports to separate the issues found here. Here we go: https://bugzilla.redhat.com/show_bug.cgi?id=1040352 https://bugzilla.redhat.com/show_bug.cgi?id=1040413 https://bugzilla.redhat.com/show_bug.cgi?id=1040422 https://bugzilla.redhat.com/show_bug.cgi?id=1040438 https://bugzilla.redhat.com/show_bug.cgi?id=1040445 I proposed all of them for FinalBlocker discussion, so that we can collectively decide which ones are important. Developers feedback will certain be important. I'm closing this one, because the original crash has been fixed. (In reply to Adam Williamson from comment #45) > 2) scheduling reformat of lv scheduled for resize causes a crash. I couldn't reproduce this one. If you know how, please report a separate bug and link it here, thanks.