Bug 246049 - yum installs kernel on wrong hard disk, mixing up mbr on
Summary: yum installs kernel on wrong hard disk, mixing up mbr on
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd   
(Show other bugs)
Version: 7
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-28 04:00 UTC by Leslie Satenstein
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-12 00:29:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Leslie Satenstein 2007-06-28 04:00:25 UTC
Description of problem:

Here is my configuration.  A two disk system, consisting of /dev/hda and
/dev/sda  (ide drive is hda  sata is sda)

The bios points to sda for booting.

Initial Installation was done as follows:
hda -- remove connection to sda and install 32bit fedora fc7 onto /dev/hda

sda -- remove connection to hda and install 64bit fedora fc7 (including xen)onto

fstabs on each disk allows that system to have rw access to the mount points of
the other disk. 

With the above technique, no problem is encountered and standard system updates
take place as expected, but....

Version-Release number of selected component (if applicable):
Not relevent, happens with May31 release and sooner.

In normal use, the bios is set to boot either hda or sda (depending upon needs)

========= The problem =============
System bios points to sda  and system was booted with sda.
Yum install had kernel update (64bit) for sda, and a XEN install on sda.

For some unexplained reason, the xen kernel gets installed on the hda drive,
when hda is not the boot drive and when the mbr on sda points to sda. (sda is
boot drive)

1) After a xen update, it appears that the mbr on sda now points to hda. Or
something is causing the grub.conf file that was there to be used. 

2) Changing grub.conf on sda has no effect. The grub file on hda selects the
kernel installed on sda.  That is, the offset value to select title and boot on
hda actually selects from the sda drive. Kernel titles do not match. 

Moreover, if the bios is changed to boot hda, then the grub.conf on hda selects
the kernel installed onto hda.  

3) The problem is that after a yum install where both drives are powered online,
grub.conf on hda is made the controling file for kernel selection. Thus, once an
update with a kernel takes place, with both drives online, the grub.conf on hda
represents both sda and drive hda, one cannot manage to select the boot kernel
on sda. 

The selection of the appropriate kernel for one system (example display 2)
results in the 2nd kernel for sda being booted, or the 2nd kernel for hda being

My desire is that sda be my 64 bit dual core system, and hda be my 32 bit system
remain isolatd from each other, as expected.

This problem has not been resolved by changing the diskmap file in sda disk
/boot/grub to indicate hd0 is mapped to /dev/sda 
Why??? I am doing re-installs because I cannot fix it via the tools available to
me, or with my knowledge of fedora internals.

How reproducible:

Install a new kernel on /dev/sda while /dev/hda is mounted. The bios is set to
boot from /dev/sda. 

Steps to Reproduce:
Actual results:

Expected results:

sda updates should not install on hda. 

Additional info:

Problem is there since fc6.

Is it possible that the script for kernel install that is in the kernel package
has the bug?  I presume that it is the problem.

Comment 1 Ignacio Vazquez-Abrams 2007-06-28 04:56:38 UTC
The kernel package and the new-kernel-pkg script only affect /boot. Are you sure
you have the correct partition mounted as /boot when you install the kernel package?

Comment 2 Leslie Satenstein 2007-06-28 12:33:17 UTC
My fstab follows   The /boot is below
######### This is a combined file for the 250 gig sata drive ################
########  Adding the /hda ###################################################
/dev/main/root         /hdaroot                 ext3    defaults        1 1
LABEL=/boot1           /hdaboot                 ext3    defaults        1 1
/dev/main/data         /hdadata                 ext3    defaults        1 1
/dev/main/home         /hdahome                 ext3    defaults        1 2
/dev/main/tmp          /hdatmp                  ext3    defaults        1 2
/dev/MainSda/root       /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
/dev/MainSda/data       /data                   ext3    defaults        1 2
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
/dev/MainSda/home       /home                   ext3    defaults        1 2
proc                    /proc                   proc    defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0
/dev/MainSda/tmp        /tmp                    ext3    defaults        1 2
/dev/MainSda/swap       swap                    swap    defaults        0 0

Comment 3 Leslie Satenstein 2007-07-13 00:32:01 UTC
Since the last report, I re-installed both linuxes, taking care to remove power
from the alternate drive.
Then I removed the link to the alternate boot drive.
That fixed the problem, until a kernel update.

With the kernel update the problem reoccurs as follows:
a) system-config-boot (via system-->admin-->bootmanager always points to the
disk with the 32bit code. This is true for both the 64bit and 32bit systems.
Thus, changing the information from the 32bit system for the 32 bit system is
fine.  But changing the information using the alternate drive and the 64 bit
system changes the display=x value on the 32 bit system and as well the 64 bit
system on the alternate drive.

So, there is something wrong here.  Also, the grub.conf on each disk reflects
what is on that disk. 

Am I going nuts here?  Why is system-config-boot not being restricted to the
drive from where the kernel was booted? 

The version selection at system boot time on my 64 bit Sata drive does not show
the XEN kernels. However, the version selection at boot time on my 32 bit
installation (HDA) drive does show all the installed kernels on that drive.

Finally, what is the purpose of device.map in /boot/grub  I changed values and
saw no effect. Is this file a historical remnant?

Can someone address this problem please?  I know vacation time is now, but I am

Comment 4 Leslie Satenstein 2007-07-24 02:02:08 UTC
Here is a more clear picture
a) two disk system. 
/hda (now /sda with fc7)  is the ide hard drive with 32bit fc7
/sda (now /sdb with fc7)  is the sata hard drive with 64bit fc7

I have the bios set to boot /sdb  and no paths from /sda are linked to /sdb

I did a xen install after booting the 64 bit system. The system booted from /sdb
and not indirectly via /sda

After the xen install, On the reboot, xen was not seen on the /sdb  It was
installed on the /sda   and that is wrong. 
I moved over the appropriate /boot files and updated the grub/menu file to
include the new kernels and now I can choose the kernel I wish at boot time.

So, to make certain that the kernel updates for /sdb go to /sdb, I had to
poweroff the /sda drive (removed power plug by opening the case).

It appears that the install script that comes with xen, may be in error.
When it executes it should look to determine the boot drive and the kernel
assigned to that boot drive (32bit or 64bit) and take appropriate action (refuse
to install a 32bit fcx on a 64bit boot partition. and vice versa.
Also, since I booted /sdb and /sdb was my 64bit fedora version and since I was
installing the 64bit xen version, to me it is clear that the installation went
to the wrong drive.
Note.  On the wrong drive (/sda), the grub.conf, had the added kernels to its
list. Booting the 32 bit system while pointing to that kernel did not work.


Comment 5 Leslie Satenstein 2007-08-27 02:57:20 UTC
Perhaps this will help, as the problem still persists.  
The info grub documentation states that grub gets very confused when one hard
disk is an ide drive and the second is a sata (scsi emulation by Intel mother
Annaconda does not detect the two disk types and flip-flops the boot drives for
the map files.
So, if both drives are connected, and I edit the boot on the ide drive, it gives
me the boot on the sata, and vice versa.
If I boot from the Sata (after having reset the bios), the vmlinuz file etc gets
installed on the ide drive.

To circumvent the problem thus far, I remove power from the drive I want to
protect. Then the kernel update works as it should.

This is only a problem when both drives are connected and the sata is the one
wanting to be updated.

Comment 6 Leslie Satenstein 2007-08-27 02:59:49 UTC
I presume that if both drives were sata, that the problem would not exist.
However, I have mixed drive types, and have to open the cover each time I want
to keep the two systems apart. (fc7 32 bit apart from fc7 64 bit)

Comment 7 Leslie Satenstein 2007-10-12 00:29:34 UTC
Close this bug. User had no way to know that the two boot drives were swapped in
the fstab.

Ergo, system booted correctly (because of bios), but then the fstab mappings
were criss-crossed for each boot drive, and of course YUM installed as per the

Flipping defs for boot drives solved the problem.

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