Description of problem: downloaded boot.iso (170Mb) from http://ftp.tudelft.nl/download.fedora.redhat.com/linux/development/x86_64/os/images/boot.iso with timestamp 07-Nov-2009 14:13 171M My test system has a partition layout that comprehends: sda1 ntfs with windows XP and set as bootable by windows xp itself. inside the winxp fs I also have the copy of the first 512 bytes of sda4, to boot my F11 partition (with grub installed previously in its root partition) from boot.ini of windows. Now I have also sda2 that is scratchable. I want to install F12 rc on it I run the cd where I burnt the boot.iso and select sda2 as target partition and to install grub on root partition (so sda2) Version-Release number of selected component (if applicable): anaconda 12.46 as provided by boot.iso above How reproducible: donna. Only tried once Steps to Reproduce: 1. boot cd with boot.iso burnt on it 2. select sda2 as target root partition and to format it 3. no other partition selected and grub install on boot secotr of sda2 partition Actual results: failure about repositories due to install tree and removal of bootable flag from win xp partition win xp unable to boot any more Expected results: failure but no influence on previous win xp installation Additional info: This grub setup phase completes, but then I get an error about repositories not aligned with my install treee and I can only retry (with same failure) or reboot. I reboot and I'm not able to start win xp anymore. I start the same f12 cd in rescue and notice with fdisk that now my sda has this sda1 no bootable flag sda2 bootable flag so that I remove bootbale flag from sda2 and set bootable flag for sda1 and my windows XP starts again and also is able again to start my F11 from sda4 Is this a bug or does it depends on installation not finished? Anyway I think we have to consider a possible error and the bootable flasg should not be removed from sda1..... I copied these files and I'm going to attach them my fdisk layout [root@tekkaman ~]# fdisk -l Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x0003ef5c Device Boot Start End Blocks Id System /dev/sda1 * 1 9138 73400953+ 7 HPFS/NTFS /dev/sda2 9139 11750 20980890 83 Linux /dev/sda3 11751 18603 55046722+ 83 Linux /dev/sda4 18604 60801 338955435 5 Extended /dev/sda5 18604 20428 14659281 83 Linux /dev/sda6 20429 60801 324296091 83 Linux
Created attachment 368011 [details] anaconda.log
Created attachment 368012 [details] program.log
Created attachment 368013 [details] storage.log
Created attachment 368014 [details] X.log
Created attachment 368015 [details] yum.log
I talked to Jesse today, and apparently this is known. The problem is that the installer is no longer tagged as a beta installer, so it refuses to use Rawhide repos, but the 'F12' repos are currently Rawhide repos, so there's nothing to install from. If I understand correctly, at any rate. This will get magically fixed once the real F12 repos exist. CCing Jesse for confirmation. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Ah, looking at the log file it's something slightly different. When rawhide is composed, the version passed to anaconda is "rawhide", this is what shows up for $releasever in yum confs, instead of something like "12". Since we removed betanag, anaconda will throw out any repo that looks like rawhide or updates-testing or source or debuginfo, which we generally want. What has to happen for this to be "fixed" during this transition week or so is we'd have to pass an actual version number to the rawhide compose so that the version looks like "12" rather than "rawhide". This should have no impact upon the release candidate composes as they get passed a real version of "12".
I've found the fault and sent a patch upstream. I'll be doing a build with the patch as soon as I verify it. Promoting to blocker.
er whoops. The last comment went to the wrong place. This bug is still open.
Hello, tried also with F12 RC3 x86_64 DVD iso. Select the same, to install boot loader on sda2, and the installation procedes with its 1142 packages. In the mean time I can see from tty2 that the bootable flag has been changed from Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x0003ef5c Device Boot Start End Blocks Id System /dev/sda1 * 1 9138 73400953+ 7 HPFS/NTFS /dev/sda2 9139 11750 20980890 83 Linux /dev/sda3 11751 18603 55046722+ 83 Linux /dev/sda4 18604 60801 338955435 5 Extended /dev/sda5 18604 20428 14659281 83 Linux /dev/sda6 20429 60801 324296091 83 Linux to Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x0003ef5c Device Boot Start End Blocks Id System /dev/sda1 1 9138 73400953+ 7 HPFS/NTFS /dev/sda2 * 9139 11750 20980890 83 Linux /dev/sda3 11751 18603 55046722+ 83 Linux /dev/sda4 18604 60801 338955435 5 Extended /dev/sda5 18604 20428 14659281 83 Linux /dev/sda6 20429 60801 324296091 83 Linux Then I ome back to the graphical installation window. The installation after about 20 minutes arrives showing the little window saying executing post install... and suddenly I see the system come back to tty2 with the typical circle when X Windows SYstem starts in the middle of the black screen. But the systems seems blocked and after a few seconds it reboots..... unable to boot because of the bootable flag problem. After rescue and going to see what is inside the f12 parttion I have mounted it under /f12 mount point: ls /f12/boot/ config-2.6.31.5-122.fc12.x86_64 initramfs-2.6.31.5-122.fc12.x86_64.img efi System.map-2.6.31.5-122.fc12.x86_64 grub vmlinuz-2.6.31.5-122.fc12.x86_64 [root@tekkaman ~]# ls /f12/boot/grub/ splash.xpm.gz Unfortunately, as the system reboots, I was not able to catch the log files... But I think they are the same I already attached with the boot.iso step.... Let me know if I can be of further help investigating.... I have F11 x86_64 too on this system, so I can run some commands to give info about hw
that seems very different from your last report. changing the boot flag is correct, as you're installing to that partition and you told it to put the bootloader there. what do you mean 'unable to boot because of the bootable flag problem'? It's set /dev/sda2 as bootable, and that should be the partition where f12 got installed with its bootloader, so...what's the problem? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Actually my report consisted of two problems and at that time I didn't know if one was the cause of the other or not. 1) removal of bootable flag and system unbootable 2) error about repositories and abort of installation As the installation didn't complete, I presumed some post-install actions skipped, perhaps.... Coming back to my latest update, I don't know if this is a limitation of Windows XP or not; anyway if you install windows xp in the mbr of the disk, you also have to set the partition wit the bootable flag. In general one user could wish to be able to mantain this boot priority, so we should let him/her this chance (suppose a windows user that has a free partition and decides to try Fedora, but keeping overall pc setup closest with the original one, in case of mind changing later). So I decide to install f12 in boot sector of designated root partition (so first 512 bytes of sda2), but eventually I'll customize later its boot setup, so that I can start it from within Windows XP environment (as I'm doing right now with f11 btw). In my opinion the boot flag is not necessary, or at least it can be set, but also preserved for the sda1 partition. In my scenario, the system WILL NOT BE ABLE to boot at all, f12 because I install grub on sda2 and not on MBR, and windows xp because f12 install phase is removing the bootable flag from sda1.... On another system where I have Windows Vista installed in sda3 and I boot f11 from within boot loader of Vista, my setup is at the moment: [root@tekkafedora ~]# fdisk -l /dev/sda Disk /dev/sda: 200.0 GB, 200049647616 bytes 255 heads, 63 sectors/track, 24321 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x30000000 Device Boot Start End Blocks Id System /dev/sda1 1 15 120456 de Dell Utility /dev/sda2 16 1321 10485760 7 HPFS/NTFS /dev/sda3 * 1321 12829 92434428 7 HPFS/NTFS /dev/sda4 12830 24321 92309490 5 Extended /dev/sda5 12830 12892 506016 82 Linux swap / Solaris /dev/sda6 12893 17756 39070048+ 83 Linux /dev/sda7 17757 24321 52733331 83 Linux And I presume that if I install f12 with the same strategy, I will end up with the same unbootable system.... Hope I've made it clearer. Eventually I can split this bugzilla in two, to separate things... let me know Gianluca
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
Hi, As for the removal of the boot flag. I'm afraid there is nothing we can do to fix this, esp. not when installing to the boot sector of a partition instead of to the mbr. And when installing to the bootsector of a partition and assuming default mbr boot code (*), which will boot the first active partition, is present in the mbr, then we must set the active / bootable flag, otherwise one might very well end up with a not bootable system. The fact that the XP bootloader installs an mbr which does check the active flag, but then can only chainload itself and won't chainload grub, is a bug in the mbr written by the XP bootloader, not in Fedora. Either the Xp bootloader should install an mbr which does not care about the active flag (like grub does), or it should properly chainload the bootsector of the active partition. *) as written by dos for eons and as written by parted when creating a fresh mbr. As for the repository problem, I believe that was because of the way the RC's where composed which was somewhat special, and this should not be happening with F-12, if it still does please open a new, separate bug for this (as you should have done to begin with, please always file one bug report per issues).
Kinda disagree with comment #14. Before F12 installation - MBR is a Dell loader * sda2 is active NTLDR After F12 installation - MBR is Dell loader - sda2 is deactivated NTLDR - sda5 is GRUB So nothing boots ... nothing active ... F12 should have issued a warning like: "You chose to configure bootloaders yourselves. Good luck, but don't report any bugs!"
(In reply to comment #15) > Kinda disagree with comment #14. > > Before F12 installation > - MBR is a Dell loader > * sda2 is active NTLDR > > After F12 installation > - MBR is Dell loader > - sda2 is deactivated NTLDR > - sda5 is GRUB > > So nothing boots ... nothing active ... > > F12 should have issued a warning like: > "You chose to configure bootloaders yourselves. > Good luck, but don't report any bugs!" Hmm, ok, so you did a custom partitioning setup with /boot on a logical partition and then selected for the boot loader to be installed in the partition, right ? Yes that wont work. I agree with you that warning about this specific problem would be nice, the problem is that as soon as you choose custom partitioning, or advanced bootloader options, then there are so many scenario's to warn about that doing so is practically impossible so we've chosen not to. As for a generic warning as soon as one does manual bootloader configuration, I sort of see your point, but we don't want to turn anaconda in to some piece of software which pops ups "Are you sure" "Are you really really sure" all the time, the "advanced" word in the advanced bootloader setup sort if implicitly contains this warning. You might have actually found a bug here btw, I think we should not set the active flag for /boot if /boot is on a logical partition, that is not going to help anyone.
Good news, further evaluation of this issue 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
*** Bug 530894 has been marked as a duplicate of this bug. ***
Thanks. Forget warnings, how about publishing a release caveat? This thing scared the hell out of me and I did a lot of stupid things debugging this issue including unnecessarily wiped-out partitions.
*** Bug 539886 has been marked as a duplicate of this bug. ***
*** Bug 538164 has been marked as a duplicate of this bug. ***
Thanks for the attention and modifications
(In reply to comment #19) > Thanks. Forget warnings, how about publishing a release caveat? This thing > scared the hell out of me and I did a lot of stupid things debugging this issue > including unnecessarily wiped-out partitions. I've asked a college to put this on the F-12 CommonBugs page. Regards, Hans
*** Bug 538271 has been marked as a duplicate of this bug. ***
*** Bug 537155 has been marked as a duplicate of this bug. ***
*** Bug 504570 has been marked as a duplicate of this bug. ***
*** Bug 527020 has been marked as a duplicate of this bug. ***
*** Bug 543810 has been marked as a duplicate of this bug. ***
I am facing this bug for first time because i used the live media. from now on will use only the install DVD which i used for all previous version.
(In reply to comment #29) > I am facing this bug for first time because i used the live media. from now on > will use only the install DVD which i used for all previous version. Why did you decide that DVD is better????? F12 DVD has the same bug, and both LiveCD and DVD will be fixed for F13. Your own perception of switching from DVD to LiveCD has nothing to do with the bug and the fix.
I haven't tried DVD .. its still downloading.Idea for switching to Live CD was based on just download size.
*** Bug 546368 has been marked as a duplicate of this bug. ***
*** Bug 531745 has been marked as a duplicate of this bug. ***
*** Bug 552561 has been marked as a duplicate of this bug. ***
I reread the patch and (In reply to comment #17) > Good news, further evaluation of this issue 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 Just to be completely clear: /boot should be activated IFF no other active partition exists. Right? The applied patch seem to be more complex. Why?
(In reply to comment #35) > The applied patch seem to be more complex. Why? First of all it limits this behavior to msdos disklabels (what regular fdisk creates, there are also mac, bsd, gpt, etc. disklabels), Second it limits the search for existing active flags to primary partitions, logical partitions can have active flags too, but have no meaning there. IOW if for some reason a logical partition has an active flag, that is not a good reason not to set the active flag on the /boot partition.