Description of problem: I was randomly clicking through the guided partitioning, because I was trying to reproduce a completely different bug. And voila, I managed to reproduce bug 1163694. So, it's not fixed after all. This time it happened I reclaimed some space in the guided dialog, went to the main hub, then back to guided partitioning, and unselected the previously selected disk. Version-Release number of selected component: anaconda-core-21.48.15-1.fc21.x86_64 The following was filed automatically by anaconda: anaconda 21.48.15-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 1550, in _setTargetSize raise ValueError("new size will not yield an aligned partition") File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 752, in <lambda> lambda s, v: s._setTargetSize(v), File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 454, in cancel self.device.targetSize = self.origsize File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 515, in cancelAction action.cancel() File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 1964, in hide self.cancelAction(action) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 721, in on_back_clicked self.storage.devicetree.hide(disk) ValueError: new size will not yield an aligned partition Additional info: cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Workstation-x86_64-2 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.17.2-300.fc21.x86_64 other involved packages: python-blivet-0.61.10-1.fc21.noarch, anaconda-gui-21.48.15-1.fc21.x86_64 product: Fedora" release: Fedora release 21 (Twenty One) type: anaconda version: Fedora
Created attachment 958972 [details] File: anaconda-tb
Created attachment 958973 [details] File: anaconda.log
Created attachment 958974 [details] File: environ
Created attachment 958975 [details] File: journalctl
Created attachment 958976 [details] File: lsblk_output
Created attachment 958977 [details] File: nmcli_dev_list
Created attachment 958978 [details] File: os_info
Created attachment 958979 [details] File: storage.log
Created attachment 958980 [details] File: ifcfg.log
Created attachment 958981 [details] File: program.log
This can probably be marked as a duplicate of bug 1163694, I guess.
Let's keep this one open and close 1163694. The issue is that we are requiring new target size be aligned even when that target size is the partition's current/actual size. IOW we are canceling a resize action. In this case we should be bypassing the alignment check.
*** Bug 1163694 has been marked as a duplicate of this bug. ***
Transferring blocker nomination from bug 1163694.
Discussed in 2014-11-19 blocker review meeting. This violates the final criterion: Any installer mechanism for resizing storage volumes must correctly attempt the requested operation.
Can you please try the following updates.img containing a naïve patch? http://vpodzime.fedorapeople.org/1165714_updates.img
(In reply to Vratislav Podzimek from comment #16) > Can you please try the following updates.img containing a naïve patch? > http://vpodzime.fedorapeople.org/1165714_updates.img I have trouble using this, it seems to not apply at all. Wrongly created? [liveuser@localhost ~]$ liveinst --updates=http://vpodzime.fedorapeople.org/1165714_updates.img % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 319 100 319 0 0 871 0 --:--:-- --:--:-- --:--:-- 871 mount: /tmp/updates.img is not a block device (maybe try `-o loop'?) cp: cannot stat ‘/tmp/updates.disk/*’: No such file or directory umount: /tmp/updates.disk: not mounted Starting installer, one moment... For the record, here's the reproducer of this bug: 1. Create a VM with two blank disks 2. Put a msdos disklabel on them 3. Create a single unaligned partition on the first disk mkpart p ext4 1M 2000000000B 4. Select both disks in guided part, check "I want to make more space available", and shrink down the existing partition a bit 5. Confirm, arrive to the main hub 6. Go back to storage screen 7. Deselect the second disk 8. hit Done 9. anaconda crashes
(In reply to Kamil Páral from comment #17) > (In reply to Vratislav Podzimek from comment #16) > > Can you please try the following updates.img containing a naïve patch? > > http://vpodzime.fedorapeople.org/1165714_updates.img > > I have trouble using this, it seems to not apply at all. Wrongly created? Interesting, it works for me just fine (not live installation). However, I've just uploaded a re-packed version of the file so please give it a try.
(In reply to Vratislav Podzimek from comment #18) > Interesting, it works for me just fine (not live installation). However, > I've just uploaded a re-packed version of the file so please give it a try. Two problems: 1. It still does not work on Live (TC4, anaconda 21.48.16-1), same problem. Can you please investigate a bit? I'll try as well. Anaconda's capacity to apply updates.img is a blocking feature. 2. It applies correctly to a Server DVD (TC4, anaconda 21.48.16-1). However, if I do steps from comment 17, anaconda freezes after step 8. It is stuck in a loop, consumes 100% CPU forever. gstack is not available on DVD, so I can't provide you with a trace.
(In reply to Kamil Páral from comment #19) > 1. It still does not work on Live (TC4, anaconda 21.48.16-1), same problem. > Can you please investigate a bit? I'll try as well. Anaconda's capacity to > apply updates.img is a blocking feature. Mystery solved, fedorapeople automatically redirects everything to https, but liveinst does not follow http redirects by default. dracut does, that's why it works on DVD. > 2. It applies correctly to a Server DVD (TC4, anaconda 21.48.16-1). However, > if I do steps from comment 17, anaconda freezes after step 8. It is stuck in > a loop, consumes 100% CPU forever. gstack is not available on DVD, so I > can't provide you with a trace. Vratislav fixed the updates.img (same url), and it works great now.
I also tested with https://vpodzime.fedorapeople.org/ultimate_f21_updates.img and it works as well.
anaconda-21.48.18-1.fc21,python-blivet-0.61.12-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/anaconda-21.48.18-1.fc21,python-blivet-0.61.12-1.fc21
pyparted-3.10.2-1.fc21, python-blivet-0.61.12-1.fc21, anaconda-21.48.18-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/FEDORA-2014-15910/pyparted-3.10.2-1.fc21,python-blivet-0.61.12-1.fc21,anaconda-21.48.18-1.fc21
Package pyparted-3.10.2-1.fc21, python-blivet-0.61.12-1.fc21, anaconda-21.48.18-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing pyparted-3.10.2-1.fc21 python-blivet-0.61.12-1.fc21 anaconda-21.48.18-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-15910/pyparted-3.10.2-1.fc21,python-blivet-0.61.12-1.fc21,anaconda-21.48.18-1.fc21 then log in and leave karma (feedback).
This works well in RC1.
For safety we need to re-VERIFY this with RC5, though #anaconda expects it to still be fixed.
This seems to work in RC5.
anaconda-21.48.21-1.fc21, python-blivet-0.61.13-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.