The following was filed automatically by anaconda: anaconda 12.24 exception report Traceback (most recent call first): File "/usr/lib/anaconda/storage/devices.py", line 1974, in _setSize raise ValueError("not enough free space in volume group") File "/usr/lib/anaconda/storage/partitioning.py", line 1189, in growLVM lv.size += grow_amounts[lv.name] File "/usr/lib/anaconda/storage/partitioning.py", line 209, in doAutoPartition growLVM(anaconda.id.storage) File "/usr/lib/anaconda/dispatch.py", line 204, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 127, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1201, in nextClicked self.anaconda.dispatch.gotoNext() ValueError: not enough free space in volume group
Created attachment 361198 [details] Attached traceback automatically from anaconda.
*** This bug has been marked as a duplicate of bug 517491 ***
Created attachment 362406 [details] Attached traceback automatically from anaconda.
Created attachment 366765 [details] Attached traceback automatically from anaconda.
Still reproducible with anaconda 12.42-1, and which should had fixed BUG517491 and that has a different root cause than this report but that was linked as a duplicate. to reproduce : 1) create a qemu-img of 2GB for harddisk 2) start kvm with 2GB memory and install fedora on that disk 3) accept default options for partitioning which would then try to allocate a swap partition of 2GB inside a smaller lvm and result in negative values for partition sizes and a crash. what is expected : anaconda reports that there is not enough disk space for the recommended layout and allows installation to proceed by allowing user to use a different setup. what happens : anaconda dies with a traceback
Created attachment 366991 [details] proposed fix for anaconda 12.41 (or later) to easy testing an anaconda-12.41-1 update.img available from : http://sajino.sajinet.com.pe/update.img 12.42 hasn't been tested as there is not yet an snapshot that includes it so disregard previous comment about testing the bugfix for BUG517491.
(In reply to comment #6) > Created an attachment (id=366991) [details] > proposed fix for anaconda 12.41 (or later) > > to easy testing an anaconda-12.41-1 update.img available from : > > http://sajino.sajinet.com.pe/update.img > > 12.42 hasn't been tested as there is not yet an snapshot that includes it so > disregard previous comment about testing the bugfix for BUG517491. This fix is not actually fixing the root cause of the problem, just working around the issue seen. I'd like to see why some people are seeing that ValueError exception and fix that.
(In reply to comment #7) > (In reply to comment #6) > > Created an attachment (id=366991) [details] [details] > > proposed fix for anaconda 12.41 (or later) > > > > to easy testing an anaconda-12.41-1 update.img available from : > > > > http://sajino.sajinet.com.pe/update.img > > > > 12.42 hasn't been tested as there is not yet an snapshot that includes it so > > disregard previous comment about testing the bugfix for BUG517491. > > This fix is not actually fixing the root cause of the problem, just working > around the issue seen. Sorry I wasn't clear about that, but yes, that is why the patch description says it is a workaround. My objective with this patch was to make the minimum amount of changes possible so that it could be considered safe enough for F12 (if possible), specially considering that this report got probably lost on the confusion with the ext[2-4] failures that it was merged into. I don't think though, the problem to be serious enough for going against the F12 freeze, if nothing because it will only happen when the disk available is small (2GB) and there is a lot of memory (1GB to 2GB) and that is not even realistic even for netbooks or OLPC but would argue about being a closed issue. > I'd like to see why some people are seeing that ValueError exception and > fix that. Agree, but considering that 12.41 is already obsoleted as per the 20091103 snapshot didn't make much sense to do all the debugging for the root cause there IMHO. It is important to mention that some of the code to calculate the partition sizes has changed on master already and the fact that in the current code for growLVM in f12-branch, the vg.vgFree is allowed to be negative as described in the replication steps is IMHO suspicious. also noticed while debugging this problem that there might be overlapping partitions which could also explain the problems reported elsewhere but which would be better tracked through a different bug report if confirmed to be still present in 12.42.
Created attachment 367575 [details] Attached traceback automatically from anaconda.
Created attachment 367578 [details] Attached traceback automatically from anaconda.
It happened in anaconda 12.43 and the steps below is 100% reproducable in my machine: 1. Install f12 with minimal package install, clear all existing partitions and create new partitions like this: sda1 /boot ext4 200M sda2 / ext4 20G sda3 swap 512M the other settings is by default. (A ks.cfg was attached for this installation.) 2. Install another f12 on the same machine, in the partition step, choose 'shrink sda2' and click 'OK'. 3. Exception occurred saying 'ValueError: not enough free space in volume group'
Created attachment 367777 [details] ks.cfg for installing a f12 system to be shrunk. I also advice this bug to be blocker bug.
this was discussed at the blocker meeting today. we generally agreed that we don't have a sufficiently solid base of shrink code to expect all shrink operations to work, so we won't generally take shrink failures as blockers. however, if this causes any pre-existing data to be lost, corrupted or otherwise damaged, that could be a blocker. can you please test whether the failure causes any adverse effects for the existing data? or does the shrink just fail without actually touching the existing data in any way? thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I retested with f12-RC4, the shrink failure happened before formatting any partition, so the existing data was intact.
BUG533797 open for the simpler case, when the failure of autopartition was triggered by the use of a disk smaller than recommended as detailed in comment #5 and to avoid confusing that issue (which has the same anaconda traceback) with the one triggered by resizing and that is described in comment #11. since the behaviour is similar the workaround proposed on that bug might also work for this case but hadn't been tested with the same partition sizes as suggested by Rui.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 379216 [details] Attached traceback automatically from anaconda.
Created attachment 389866 [details] Attached traceback automatically from anaconda.
Comment on attachment 389866 [details] Attached traceback automatically from anaconda. I was trying to install f12 as a virtual guest using virt-install onto a 1.2GB LV
Created attachment 405488 [details] Attached traceback automatically from anaconda.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days