Red Hat Bugzilla – Bug 246049
yum installs kernel on wrong hard disk, mixing up mbr on
Last modified: 2007-11-30 17:12:08 EST
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
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
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.
Install a new kernel on /dev/sda while /dev/hda is mounted. The bios is set to
boot from /dev/sda.
Steps to Reproduce:
sda updates should not install on hda.
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.
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?
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
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
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.
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.
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)
Close this bug. User had no way to know that the two boot drives were swapped in
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.