Bug 537155 - anaconda removes previous bootable flag: system unbootable after install
Summary: anaconda removes previous bootable flag: system unbootable after install
Keywords:
Status: CLOSED DUPLICATE of bug 533658
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 12
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-12 17:05 UTC by Gianluca Cecchi
Modified: 2009-11-30 10:15 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-17 12:15:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Gianluca Cecchi 2009-11-12 17:05:53 UTC
Description of problem:
System is a Dell laptop XPS M1330.
I have Windows Vista installed in sda3 and currently I boot f11 x86_64 (sda7)
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

To boot F11 I make a dd into a file of the first 512 bytes of sda7 partition (where I installed the boot loader of F11) and make this file available to Vista boot loader
Now I want to install F12 on sda6, but preserving Vista boot loader as the master one

Version-Release number of selected component (if applicable):
anaconda as in F12 RC3

How reproducible:
always

Steps to Reproduce:
1. run dvd install and select custom layout for partitioning
2. decide to install grub on sda6
3. complete installation and get the post-install, install boot loader and congratulations small windows
  
Actual results:
The PC doesn't boot any more because it removed the bootable flag from the sda3 and placed the bootable flag to the sda6 partition.
In fact, if in congrat screen I then switch to console 2, I can see this disk layout:
[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

It seems that Vista boot loader, installed into MBR, without the bootable flag
set for the sda3 partition, is not able to boot.
It gives the message 
no operating system to boot 

Expected results:
Original boot loader not influenced

Additional info:

I can manually solve this problem going to console 2 and set the bootable flag for sda3 before reboot.
But I would expect anaconda to not remove the origanl flag for sda3

Now my sda has this partition layout:

[root@tekkaman Documents]# 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


To boot my F12 sda6 partition I can choose 2 methods:
- same as for F11 copying the 512 bytes of sda6 into a file accessible to Vista boot loader
- modify grub.conf of my previous F11 grub, inserting something like this:
title F12
        rootnoverify (hd0,5)
        chainloader +1

I would like some or all of these modifications:
- anaconda not removing previous existing bootable flags
- if one selects custom layout and decides to install onto a partition and not on MBR, a warning saying "Attention: choosing this option the F12 you are just installing could not be bootable without manual intervention! Are you sure?"
- a remark on release notes that installing on MBR will erase settings in case of previous operating systems installed and that installing boot loader in different place than MBR could lead to not bootable PC and or F12

I would like to notice that, if I remember well, with previous versions of Fedora (I think starting from F7 probably), this was not the behaviour, when installing on a partition.

Comment 1 Gianluca Cecchi 2009-11-13 11:45:21 UTC
Actually the presence of more partitions with bootable flag could be itself a problem.
I tried the same with another PC where on sda1 there is Windows XP with its boot loader in MBR.
I'm going to install F12 on sda2. Install completes, anaconda moves bootable flag from sda1 to sda2.
I add bootable flag to sda1, so that now both partitions have the flag.
PC is unable to boot. it gives the network pxe boot option....., as it wouldn't recognize the disk at all.
After booting into rescue and set bootable flag only to sda1, PC is able to boot from Windows XP boot loader again.

Comment 2 Bug Zapper 2009-11-16 15:28:12 UTC
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 3 Hans de Goede 2009-11-17 12:15:53 UTC
Hi,

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.

Parted agrees with you that only one bootable flag should be set, so when setting a bootable flag, the flag automatically gets cleared on any other partition which may have it.

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 warning about when selecting to install grub into a partition, normally you don't even get the choice! You explictly selected:
1) To configure disk yourself
2) To configure advanced bootloader options

That seems plenty of warning that when you enter this path you are assumed to
know what you are doing.

###

As for warning that installing into the mbr may make your current / other os unbootable, well for normal systems it should not do that, I know we have an issue where we will point the other os / windows entry in grub.conf to the rescue partition, see bug 534066, which I acknowledge is a real bug and we are
working on fixing this.

Regards,

Hans

Comment 4 Alexei Podtelezhnikov 2009-11-29 21:46:30 UTC
Fixed actually, see bug 533658

Comment 5 Hans de Goede 2009-11-30 10:15:26 UTC
(In reply to comment #4)
> Fixed actually, see bug 533658  

Correct, 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

Changing resolution of this bug to match.

*** This bug has been marked as a duplicate of bug 533658 ***


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