Created attachment 412605 [details] Anaconda crash log Description of problem: Anaconda offers an option to resize the NTFS partition on the main hard drive if one is present. A dialog is presented prompting the user which partition to resize, and by how much. In my case, Windows 7 is preinstalled to the drive, which means there are two partitions: a 100MB boot partition and another one occupying the rest of the drive. The problem is that both partition sizes show up as 0 MB; attempting to resize using the 'custom layout' tool results in an error of 1, but will write the partition table to the drive anyway, resulting in an unbootable system. Version-Release number of selected component (if applicable): Fedora 13 RC2 How reproducible: Purchase any computer, use Anaconda's 'resize system' option to attempt to install Fedora 13 RC2 without wiping the existing operating system Steps to reproduce: 1. Find a computer with Windows 7 preinstalled, or install it / buy one 2. Boot Fedora 13 RC2's installation CD1 3. Hit enter when GRUB menu appears, proceed through media test, etc. 4. Select default language / keymapping, enter hostname, time zone, root password, etc. 5. Select 'Shrink Current System' 6. Note the options given in the dialog box: sda1 / sda2, both of size 0 MB 7. Attempt to proceed past this dialog box, see 'sdaX: new size same as old size' 8. Select 'Custom Layout', resize the second partition to occupy half of the drive, fill out the rest of the drive with the usual root / swap partitions 9. Press next, note the error message that appears Actual results: Anaconda exits with an error, Windows 7 becomes unbootable Expected results: NTFS partition is resized, installation proceeds normally Additional info: This has been going on for years, from release versions of Fedora 10 onward, and has happened on many different types of systems. These computers were brand-new, and no unusual Win7 installation options (RAID-1, etc.) were used. To make matters worse, attempting to connect via scp to a remote server to upload the crash log will cause anaconda to hang, although the emergency shells at alt-F1 through alt-F4 will work fine.
All details are here, marking as Triaged. I can reproduce this too with 13 GA. This is a major issue.
Same for me on BIOS SW RAID 10 Intel Matrix Storage. Anaconda found it correctly. Installer (burned x86_64 boot.iso) accepted new size and went to error message about inconsistent volume. It asked to reboot PC start OS and repair it. I was absolutely not prepared for finding unbootable MS Windows and "resized" partitions. It looked like Anaconda asked its subcomponent to do the check of the original file system for errors BEFORE real resize. Instead it made the change in the partition table and later it found inconsistencies. $MFT was not touched by resizing tool. I must say: "Very funny!"
Yeah.. same problem in a Athlon, with windows XP.. anaconda gives a resize error (1). I could fix the wrong partition with this tutorial: http://gparted-forum.surf4.info/viewtopic.php?id=13937
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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
I'm pretty sure this happens with Fedora 15 as well (we had an install fest recently [1], and we encountered issue on one laptop). [1] http://www.ri.linux.hr/?p=431
This should be watched more seriously. This is a MAJOR bug. Please change it to Fedora 15 and try to fix it.
Still present as of today. If anyone has any suggestions where a developer might start to look into things, let me know.
Confirmed this today on a system with Windows 7 Home Premium and Fedora 16 Beta RC4. Same set of errors and the system becomes unbootable.
Same here. Fedora 16 beta. Windows 7 destroyed. I thought it was a safe choice to shrink NTFS from the Fedora installer...
(In reply to comment #9) > Same here. Fedora 16 beta. Windows 7 destroyed. I thought it was a safe choice > to shrink NTFS from the Fedora installer... Eventually, I've "deleted" my shrinked sda3 in GParted and then Win7 is able to recover it. It only manipulated the partition table. So, OK, Win7 is not destroyed. But it's scary !!!
This is still present on the f16 install DVD. Luckily anaconda barfed with an error before it attempted to resize my partition (I tried to resize the "0MB" sda2 to 102400MB). Argh... I have the full traceback if you need it. anaconda 16.25 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/fs.py", line 202, in _setTargetSize raise ValueError("invalid target size request") File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 555, in cancel self.device.format.targetSize = self.origSize File "/usr/lib64/python2.7/site-packages/pyanaconda/iw/autopart_type.py", line 172, in getNext action.cancel() File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1197, in nextClicked rc = self.currentWindow.getNext () ValueError: invalid target size request Local variables in innermost frame: newsize: 0 self: existing ntfs filesystem
I'm wondering if this commit is to blame: http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=514cec57b099fdfb5a7fa82cd451355a6fe8ab1c which was a fix for this bug: https://bugzilla.redhat.com/show_bug.cgi?id=540598 It seems to me if supported is false that the size will remain 0? Mind you this is only based off of looking at the anaconda code for 15 minutes. I tried editing the anaconda code live, but I don't think it re-read the .py. Maybe I'll try building another install DVD tomorrow.
I can confirm that reverting that commit and building a F16 install DVD shows proper sizes for NTFS partitions. Unfortunately, my HDD came with 4 partitions on a ms-dos partition layout... let's see if I can do something about that. Then I'll test actual resize functionality.
With that patch reverted (and after deleting a partition) I was able to shrink my NTFS partition. After installing F16 I checked that Win7 was still able to boot- after a chkdsk that automatically ran next boot, it worked fine.
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
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.