This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 533658 - anaconda removes windows xp bootable flag and no repositories
anaconda removes windows xp bootable flag and no repositories
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
: 504570 527020 530894 531745 537155 538164 538271 539886 543810 552561 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-08 02:08 EST by Gianluca Cecchi
Modified: 2013-01-10 00:34 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-17 08:29:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda.log (56.47 KB, application/octet-stream)
2009-11-08 02:09 EST, Gianluca Cecchi
no flags Details
program.log (20.35 KB, application/octet-stream)
2009-11-08 02:09 EST, Gianluca Cecchi
no flags Details
storage.log (38.67 KB, application/octet-stream)
2009-11-08 02:10 EST, Gianluca Cecchi
no flags Details
X.log (31.97 KB, application/octet-stream)
2009-11-08 02:10 EST, Gianluca Cecchi
no flags Details
yum.log (1.50 KB, application/octet-stream)
2009-11-08 02:11 EST, Gianluca Cecchi
no flags Details

  None (edit)
Description Gianluca Cecchi 2009-11-08 02:08:21 EST
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
Comment 1 Gianluca Cecchi 2009-11-08 02:09:19 EST
Created attachment 368011 [details]
anaconda.log
Comment 2 Gianluca Cecchi 2009-11-08 02:09:50 EST
Created attachment 368012 [details]
program.log
Comment 3 Gianluca Cecchi 2009-11-08 02:10:16 EST
Created attachment 368013 [details]
storage.log
Comment 4 Gianluca Cecchi 2009-11-08 02:10:41 EST
Created attachment 368014 [details]
X.log
Comment 5 Gianluca Cecchi 2009-11-08 02:11:08 EST
Created attachment 368015 [details]
yum.log
Comment 6 Adam Williamson 2009-11-08 02:28:02 EST
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
Comment 7 Jesse Keating 2009-11-08 15:01:19 EST
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".
Comment 8 Jesse Keating 2009-11-08 17:22:10 EST
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.
Comment 9 Jesse Keating 2009-11-08 19:31:38 EST
er whoops.  The last comment went to the wrong place.  This bug is still open.
Comment 10 Gianluca Cecchi 2009-11-09 17:26:20 EST
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
Comment 11 Adam Williamson 2009-11-10 02:05:19 EST
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
Comment 12 Gianluca Cecchi 2009-11-10 02:45:49 EST
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
Comment 13 Bug Zapper 2009-11-16 10:18:36 EST
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
Comment 14 Hans de Goede 2009-11-17 08:29:07 EST
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).
Comment 15 Alexei Podtelezhnikov 2009-11-24 20:35:48 EST
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!"
Comment 16 Hans de Goede 2009-11-25 03:26:40 EST
(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.
Comment 17 Hans de Goede 2009-11-26 06:26:23 EST
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
Comment 18 Hans de Goede 2009-11-26 06:31:48 EST
*** Bug 530894 has been marked as a duplicate of this bug. ***
Comment 19 Alexei Podtelezhnikov 2009-11-26 17:26:44 EST
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.
Comment 20 Hans de Goede 2009-11-28 14:55:47 EST
*** Bug 539886 has been marked as a duplicate of this bug. ***
Comment 21 Andre Robatino 2009-11-29 16:55:37 EST
*** Bug 538164 has been marked as a duplicate of this bug. ***
Comment 22 Gianluca Cecchi 2009-11-29 17:57:24 EST
Thanks for the attention and modifications
Comment 23 Hans de Goede 2009-11-30 03:51:00 EST
(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
Comment 24 Hans de Goede 2009-11-30 05:12:58 EST
*** Bug 538271 has been marked as a duplicate of this bug. ***
Comment 25 Hans de Goede 2009-11-30 05:15:26 EST
*** Bug 537155 has been marked as a duplicate of this bug. ***
Comment 26 Hans de Goede 2009-11-30 05:19:17 EST
*** Bug 504570 has been marked as a duplicate of this bug. ***
Comment 27 Hans de Goede 2009-11-30 05:58:10 EST
*** Bug 527020 has been marked as a duplicate of this bug. ***
Comment 28 Hans de Goede 2009-12-03 03:04:06 EST
*** Bug 543810 has been marked as a duplicate of this bug. ***
Comment 29 Krishnadas K R 2009-12-03 04:30:22 EST
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.
Comment 30 Alexei Podtelezhnikov 2009-12-03 14:15:11 EST
(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.
Comment 31 Krishnadas K R 2009-12-04 00:09:40 EST
I haven't tried DVD .. its still downloading.Idea for switching to Live CD was based on just download size.
Comment 32 Hans de Goede 2009-12-10 13:24:34 EST
*** Bug 546368 has been marked as a duplicate of this bug. ***
Comment 33 Radek Vykydal 2009-12-15 10:16:43 EST
*** Bug 531745 has been marked as a duplicate of this bug. ***
Comment 34 Hans de Goede 2010-01-05 09:38:58 EST
*** Bug 552561 has been marked as a duplicate of this bug. ***
Comment 35 Alexei Podtelezhnikov 2010-01-19 15:59:43 EST
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?
Comment 36 Hans de Goede 2010-01-19 16:33:19 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.