I setup a system with two drives as thus: /dev/sda1 - /boot - 500meg - ext4 /dev/sda2 - mdraid - rest of disk /dev/sdb1 - mdraid - rest of disk /dev/md0 - raid0 - 64G - /dev/sda2 /dev/sdb1 things partition and progress, mount shows them mounted correctly however after software select I'm told that my package set requires 625MB of free space, but you don't have this much free. Go back, or exit. Something is wrong here. I used the branched images from 20100427
Hi, I just tried to reproduce this, using a local mirror of fedora/development/13/i386/os And I cannot reproduce this. Please try again and when it fails again, attach all files with names ending in log under /tmp. Regards, Hans p.s. Please always attach log files when filing an anaconda bug, this saves both us and you (no need to reproduce just to get the log files) time, thanks!
Re-assigning as directed on IRC.
This is fixed in anaconda-13.40-1 .
seems like Bugzilla missed a chunk of this story; what turned out to be the trigger? Jesse, you are the one who has the power to get a build with 13.40 to test this =) Could be done from a live image, I suppose. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This was triggered by having existing md raids that were deleted and re-created. That confused anaconda. I'll re-try and confirm it fixed, when there is a build.
To reproduce do the following: 1) Do a custom partitioning install with 1 small (500 MB) mdraid set (so it will become md0) 2) Do a new install on the same system, removing the small mdraid set and make a new large mdraid set, again use only 1 mdraid set, use this set for / 3) Boom The problem is that libparted has a device cache and remembers the size of the old small md0 (which has been destroyed, and then a new bigger md0 created). So we think we don't have enough free disk space. This is fixed by this commit: http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=4c3a114f07962ff34732b4b303865788babe48ca And I've verified the fix using the above reproduction method.
This is an F13 blocker per our 'should be able to handle any possible partition setup' criterion; can you push the fix to the f13 branch? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #7) > This is an F13 blocker per our 'should be able to handle any possible partition > setup' criterion; can you push the fix to the f13 branch? Thanks. > As the fixed in version field, and the modified status hint at, the fix is already in f13-branch, I guess I should have added a comment to that extend as well, so here you go :)
oh, sorry, I checked the 13 branch but somehow didn't see the commit, I think I didn't look far enough back. MODIFIED isn't enough, there have unfortunately been several cases this cycle where anaconda team has set bugs filed against 13 to MODIFIED after committing the fix only to Rawhide; I've been chasing those yesterday...
anaconda-13.40-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13
anaconda-13.40-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update anaconda'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13
We should now be able to confirm that this bug is fixed using the images here: http://alt.fedoraproject.org/pub/alt/stage/13.0505/Fedora/i386/os/images/ if we have not yet confirmed the fix, can anyone able to reproduce this bug please test with one of those images and check that the bug is fixed? Thanks.
Verified that this works.
let's close it, then. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
anaconda-13.40-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.