Bug 533658
Summary: | anaconda removes windows xp bootable flag and no repositories | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gianluca Cecchi <gianluca.cecchi> | ||||||||||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||
Priority: | low | ||||||||||||||
Version: | 12 | CC: | anaconda-maint-list, apodtele, art-rh, awilliam, bugger-pihhan, dcantrell, eddie, hdegoede, jfrieben, krishnadaskr, marcin.wolyniak, markku.kolkka, p.sherman, robatino, vanmeeuwen+fedora | ||||||||||||
Target Milestone: | --- | ||||||||||||||
Target Release: | --- | ||||||||||||||
Hardware: | x86_64 | ||||||||||||||
OS: | Linux | ||||||||||||||
Whiteboard: | |||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | Environment: | ||||||||||||||
Last Closed: | 2009-11-17 13:29:07 UTC | Type: | --- | ||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||
Documentation: | --- | CRM: | |||||||||||||
Verified Versions: | Category: | --- | |||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
Embargoed: | |||||||||||||||
Attachments: |
|
Description
Gianluca Cecchi
2009-11-08 07:08:21 UTC
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. |