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 /dev/sda 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 booted. 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: 1. 2. 3. 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.
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 patient.
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 board). 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 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 fstab. Flipping defs for boot drives solved the problem.