Bug 496896
Created attachment 340546 [details]
Attached traceback automatically from anaconda.
Created attachment 340548 [details]
Attached traceback automatically from anaconda.
Created attachment 340556 [details]
interactive kickstart script
In case it helps, I got these errors when installing over an existing Fedora 10 system. The system netbooted into the installer with a kickstart script set to interactive mode. I'm attaching the kickstart script.
I finally chose to do a manual layout. At first, it showed that my disk was empty. As soon as I added a partition, it suddenly added back the preexisting partitions. Once the preexisting partitions appeared, I was able to delete them, and the partitioning then proceeded as expected.
Created attachment 340584 [details]
Attached traceback automatically from anaconda.
Created attachment 343479 [details]
Attached traceback automatically from anaconda.
(In reply to comment #5) > Created an attachment (id=343479) [details] > Attached traceback automatically from anaconda. This error appears when I am trying to install Fedora 11 on an 1 Gb Harddrive. If you change this line in your kickstart file: part / --size=10000 --grow --fstype ext3 --ondisk=sda to: part / --size=1 --grow --fstype ext3 --ondisk=sda Does the installation complete? I'm out of the country, so it will be about two weeks before I will be able to test this. I'll try it as soon as I can. This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Created attachment 347053 [details]
Attached traceback automatically from anaconda.
(In reply to comment #10) > Created an attachment (id=347053) [details] > Attached traceback automatically from anaconda. I was installing using netinst image, in qemu with hda set to 1 GB USB stick attached to /dev/sdb - similar as comment #6 at the beginning, the installer complained about disk not being ready, so I've chosen to let it "initialize" it (sigh) Created attachment 347370 [details]
Attached traceback automatically from anaconda.
Created attachment 348706 [details]
Attached traceback automatically from anaconda.
David, I tried changing the size for / from 10000 to 1 and that seemed to work around the problem. Sorry for taking so long to test this. Created attachment 349186 [details]
Attached traceback automatically from anaconda.
Created attachment 350729 [details]
Attached traceback automatically from anaconda.
Comment on attachment 350729 [details]
Attached traceback automatically from anaconda.
The first time I ran the netinst image I was able to make out a custom partitioning scheme and this output is from anaconda crashing right at the end of that. On subsequent reboots anaconda now crashes at the screen in which the user selects the option to review and customize partitioning even before doing it.
Created attachment 354762 [details]
Attached traceback automatically from anaconda.
Created attachment 354766 [details]
Attached traceback automatically from anaconda.
Created attachment 360688 [details]
Attached traceback automatically from anaconda.
Created attachment 362534 [details]
Attached traceback automatically from anaconda.
Created attachment 366213 [details]
Attached traceback automatically from anaconda.
Dave - I believe this is likely to be fixed by your new request growing code. Your thoughts? I don't think so. The idea here is that people specify their pv as size=1 grow=True and then another partition as size=$bignumber grow=True, right? This means that in the old code and the new code we will allocate $bignumber times as many sectors to the non-pv request when growing the partitions. Even if we made all requests grow at an equal rate this approach to kickstart partitioning makes no sense -- it would require an algorithm that tries to even out the sizes of the requests in spite of the base size specs. If you know your ks.cfg specifies an lv w/ size=1024, how can you possibly expect things to go well when you specify the sole pv w/ size=1, regardless of grow. It just makes no sense. We're guilty of it as well in autopart -- we should determine the minimum size required by the autopart lv reqs and make sure the sum of the pvs at least matches that. Created attachment 369242 [details]
Attached traceback automatically from anaconda.
For all of you who put "--size=1 --grow" physical volume requests in your kickstart scripts, please stop and think: if you are requesting logical volumes that total > 1000MB, how could it possibly be wise to only request a minimum of 1MB for the only physical volume? Dave, I originally had "--size=10000". In Comment #7, David Cantrell suggested switching to "--size=1" as a workaround. I agree that specifying a size of 1 MB doesn't make much sense, but at least it stopped the installer from crashing. :) A change was included in anaconda-13.8-1 to cause a more graceful (also recoverable) failure when specified volume group space is not adequate to satisfy logical volume requests. Created attachment 397257 [details]
Attached traceback automatically from anaconda.
Created attachment 454099 [details]
Attached traceback automatically from anaconda.
Created attachment 454101 [details]
Attached traceback automatically from anaconda.
Created attachment 597785 [details]
Attached traceback automatically from anaconda.
Created attachment 597786 [details]
Attached traceback automatically from anaconda.
Created attachment 597789 [details]
Attached traceback automatically from anaconda.
|
The following was filed automatically by anaconda: anaconda 11.5.0.46 exception report Traceback (most recent call first): File "/usr/lib/anaconda/storage/devices.py", line 1946, in _setSize raise ValueError("not enough free space in volume group") File "/usr/lib/anaconda/storage/partitioning.py", line 1132, in growLVM lv.size += grow_amounts[lv.name] File "/usr/lib/anaconda/storage/partitioning.py", line 193, in doAutoPartition growLVM(anaconda.id.storage) File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext self.moveStep() File "/usr/lib/anaconda/gui.py", line 1323, in nextClicked self.anaconda.dispatch.gotoNext() ValueError: not enough free space in volume group