Dual Boot

dthiele · 07-28-2008, 07:50 AM

Hi!
I am new to this forum but have been working with Linux (RHEL) at my job for a few months now and have played around with it some at home before that.

I am currently working on a triple boot machine that has 3 hard drives (one OS per HDD) and am trying to use our current kickstart images at load the first 2 HDDs (RHEL3 & 4).

So here is what I am running into so far:
I kickstart the 2nd HDD (RHEL4), login and everything works great :-)
I kickstart the 1st HDD (RHEL3), login and everything works great :-)
I edit the grub.conf file to boot to the 2nd HDD, restart and log back into RHEL3 - still works fine

Heres where it gets funky: I restart - grub into RHEL4 login works fine
Restart and grub into RHEL3 - eth0 fails to initiate and can't login.
I can restart - grub into RHEL4 - still works perfectly fine.

We use an LDAP Server for logins (no eth0 = no login)

So my question is: What does loading RHEL4 change in RHEL3 that it can't initiate eth0?

We have tried to initiate eth0 manually - have not gotten good results - it times out eventually.

What I'm wondering is if maybe it got a different driver after loading RHEL4 and then doesn't work for RHEL3? Is there some way that I can make RHEL3 point to a certain driver?

Let me know if more details are needed

PTrenholme · 07-28-2008, 08:28 AM

Since you're using RHEL, aren't you paying RH for support?

Check the /etc/fstab entries on both systems: It's possible (but not likely) that you're mixing file systems so, for example, the DNS cache is inadvertently being shared. See if you can use the UUID= device specification format in the fstab or set up the udev rules so you get a consistent device naming convention. (The point here is that each OS, when booted, may assign different physical drives the same device identifier, so, for example, /dev/hda in one fstab does not point to the same drive as hda references in the other fstab.)

Unless you tell the OS not to do so, it will use all swap partitions it can "see" as it's swap pool. Is it possible that information is being conveyed in the swap space? (That should not happen, but, for example, the swap space is used to hold "suspend" images so this might be a remote possibility.)

From the above, you can see I'm really at a loss.

<edit>
You might want to look at the map directive in GRUB for changing physical and logical drives, but (I think) the OS may not pay too much attention to GRUB's drive assignments.
</edit>

dthiele · 07-28-2008, 04:26 PM

Quote:

Originally Posted by PTrenholme

Since you're using RHEL, aren't you paying RH for support?

no RH support :-( not my choice to do this...

Quote:

Originally Posted by PTrenholme

Check the /etc/fstab entries on both systems: It's possible (but not likely) that you're mixing file systems so, for example, the DNS cache is inadvertently being shared. See if you can use the UUID= device specification format in the fstab or set up the udev rules so you get a consistent device naming convention. (The point here is that each OS, when booted, may assign different physical drives the same device identifier, so, for example, /dev/hda in one fstab does not point to the same drive as hda references in the other fstab.)

Unless you tell the OS not to do so, it will use all swap partitions it can "see" as it's swap pool. Is it possible that information is being conveyed in the swap space? (That should not happen, but, for example, the swap space is used to hold "suspend" images so this might be a remote possibility.)

From the above, you can see I'm really at a loss.

[edit]
You might want to look at the map directive in GRUB for changing physical and logical drives, but (I think) the OS may not pay too much attention to GRUB's drive assignments.
[/edit]

I would love to change some of the udev rules but I don't have udev. udev is only for 2.6.15 kernel and rhel4 runs 2.6.9 - rhel3 runs 2.4.21.

I'm not quite sure how to use the UUID= or how to look at the map directive. Could you give me some more detail on how to do both of these.

PTrenholme · 07-28-2008, 05:47 PM

Hum. First, do you a /dev/disk directory? I don't recall when that support was added to Linux, but it may depend on a more recent kernel then you're running on either of your systems. If you don't have that directory, the UUID= trick is not likely to work.

For your edification, here's Kubuntu fstab to show you how it's done:

Code:

$ cat /etc/fstab
proc            /proc           proc    defaults        0       0
UUID=17841f9e-fa3a-4850-aa52-0e6d0ba242e3 /               ext3    relatime,errors=remount-ro 0       1
UUID=22b2553f-6199-4b82-b20c-6ad7c7b6688f none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0
UUID=342D7D7923AC4107 /Vista    ntfs-3g rw,defaults 0 0

(I'd show you my Fedora fstab, but my laptop Fedora is on a USB drive not currently plugged in. But it is quite similar.)

As to the map directive, it is used by GRUB to swap drives before booting, so the physical drive order seen by the OS is in a specific order. It is most often need when, for example, you want to boot a Windows OS that requires your boot device to be what those OSs call the "C:" drive. The syntax is map (hd1) (hd0) to replace HD0 with HD1. These directives meed to be "paired," since the single one I typed in the last sentence would leave GRUB with two HD0s and no HD1. Here's an example where three drives are "rotated."

Code:

title Win98
      rootnoverify (hd0,0)
      map (hd0) (hd1)
      map (hd1) (hd2)
      map (hd2) (hd0)
      chainloader +1

If you put GRUB into "edit" mode, then you can use the "tab completion" feature to see what, exactly, GRUB has found on each boot drive, and experiment with different booting schemes to see if you get any difference. The GRUB documentation should be available on-line if you can't find it on your local system.

billymayday · 07-28-2008, 05:53 PM

Quick question - does a cold reboot fix it (it powering off and turning on rather than a warm restart). Used to fix all sorts of problems, but don't know if it still makes much difference with modern mobos

dthiele · 07-29-2008, 08:40 AM

Quote:

Originally Posted by billymayday

Quick question - does a cold reboot fix it (it powering off and turning on rather than a warm restart). Used to fix all sorts of problems, but don't know if it still makes much difference with modern mobos

So here's my latest update: I tried this once and it didn't work. Then I tried with unplugging the power cord (and waiting for the little click sound (about 5-10 secs.)) and RHEL3 initialized eth0. :-D

I could then login fine. I booted up RHEL4, it worked fine, as expected. Then loaded RHEL3 again. IT DIDN"T WORK!!! >-| It failed to initialize eth0. But if I unplug and wait for the click sound then restart it works again.

I'm hoping that this will help someone think of what might be truely wrong.

I REALLY appreciate everyones help!!! Thanks!

dthiele · 07-30-2008, 09:11 AM

Quote:

Originally Posted by dthiele

So here's my latest update: I tried this once and it didn't work. Then I tried with unplugging the power cord (and waiting for the little click sound (about 5-10 secs.)) and RHEL3 initialized eth0. :-D

I could then login fine. I booted up RHEL4, it worked fine, as expected. Then loaded RHEL3 again. IT DIDN"T WORK!!! >-| It failed to initialize eth0. But if I unplug and wait for the click sound then restart it works again.

I'm hoping that this will help someone think of what might be truely wrong.

I REALLY appreciate everyones help!!! Thanks!

No more suggestions?

billymayday · 07-30-2008, 03:46 PM

I take it that you've tried to manually take the device down and up again in RHEL3. Have you compared the config files under both distros (probably /etc/sysconfig/network/devices/ifcfg-eth0)?

Do you know what drivers are being installed under each?