Created attachment 363546 [details] Output of fdisk -l /dev/sda after "rawhide" install Description of problem: After a fresh install from the current "rawhide" tree, the system boots directly from /dev/sda2 which had been set up to be mounted as /boot during install, and which had also been chosen as target of the boot loader. However, I am used to booting into Fedora via NTLDLR, and until recently, the boot flag of the Windows XP partition /dev/sda1 which was the boot partition before the "rawhide" install had never been touched by anaconda. Given that this modification is performed without notification nor confirmation requested from the user, I do consider this change a bug. Version-Release number of selected component (if applicable): anaconda-12.30-1.fc12.x86_64 How reproducible: Always. Steps to Reproduce: 1. Perform fresh install from the "rawhide" tree and choose /dev/sda2 as destination of the boot loader. Actual results: New system boots from /dev/sda2 even though it used to boot from /dev/sda1. Expected results: New system boots from /dev/sda1 as before. Additional info: FDISK allows to toogle the boot flag of /dev/sda1 and /dev/sda2 in order to revert the change of the boot partition. The system then allows again to boot into Fedora via NTLDR flawlessly after updating the boot sector image C:\GRUB.INI.
Created attachment 363548 [details] Install log file anaconda.log
Created attachment 363549 [details] Install log file storage.log
Created attachment 363550 [details] Install log file syslog
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
Further evaluation of our new boot flag setting behavior has lead to the conclusion that the removal of the active flag from an existing partition indeed is unwanted behavior. So I've just changed this, and for F-13 we will no longer do that, see: http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=0c0559f6f187815521364cb6d5118ad9faf24cc9 *** This bug has been marked as a duplicate of bug 533658 ***