The system layout is:

/dev/hda1 /boot (hd0,0) IDE drive
/dev/hda2 / (hd0,1)
/dev/sda1 /alt_root (hd1,0) Was SCSI, now SATA 1
/dev/sdb1 /other (hd2,0) SATA 2
(other non-essential partitions omitted)

The device /dev/sda1 used to be SCSI, and my problem started when it died and I replaced it with a SATA drive.

The grub script for the old SCSI drive was:

title 12.0 -- 2.6.21.5 -- generic smp / new installation
root (hd0,0)
kernel /vmlinuz-generic-smp-2.6.21.5-smp ro root=/dev/sda1 hdb=ide-cd hdc=ide-cd
initrd /initrd-generic-smp-2.6.21.5-smp

This worked. I replaced the drive, and I can no longer get the new drive to mount as /.

Grub has been installed in /boot. It was re-installed after the SCSI to SATA switch, just to make sure things were set up right. It was installed with:

system: grub
grub> root (hd0,0)
grub> setup

I boot the new drive. Once up, I get:

cat /proc/cmdline; df /
ro root=/dev/sda1 hdb=ide-cd hdc=ide-cd
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 117679196 11459632 100241724 11% /

I looked around on the web, and found something that said that the grub root needs to be set to the system root. Did not appear to be required before, but I changed the script to:

title 12.0 -- 2.6.21.5 -- generic smp / new installation
root (hd1,0)
kernel /vmlinuz-xyzzy ro root=/dev/sda1
initrd /initrd-xyzzy

I purposely did NOT place /*-xyzzy files on the disk. Grub would not boot as it could not find the kernel (yes, hd1 is really hd1). I installed the kernel and initrd files, it boots, but the root partition is still /dev/hda2.

What do I need to do to get grub to give me the right root? I know I could install grub on /sda, but that seems to be a bit much to fix something that used to work...

Any help or hints welcome.

In your bios setup what is the boot order of your hard drives? Make sure your ide hda drive is first followed by your new sata drive. At boot, grub enumerates the drives based on their boot order in the bios setup. The hard drive first in the bios boot order is usually given hd0 and the second one is given hd1, etc. This can change after the linux kernel loads, especially when you have both ide and sata drives. I've had instance where grub designates my sata drive hd0 at boot but if I check from a grub prompt after I boot into linux, the same drive was designated hd1. It can be very confusing.

You can check this out by going to a grub prompt at boot, usually by hitting the Esc key at the boot selection screen then "C" to get to a grub prompt. It varies by distro. Once at the grub prompt, run:

grub> find /sbin/init

That will tell you how grub is designating your root partitions(i.e. where /sbin/init is located) at boot. Note the output; it should look like:

(hd0,1)
(hd1,0)

If not, grub is seeing the partitions differently at boot than it does after the kernel is loaded.

each drive has its own mbr....and whether a mbr is visible or not depends on the bios.

if you bios allows boot order to be ide drive first....it it better to have grub in that mbr......but sata drives should be faster

Grub has been installed in /boot...is misleading unless you mean that you re-installed grub into the first partition....yet if I am reading you corrrectly, / was and always was on hda2.....please explain if I am wrong.

so sort out your bios for boot order...if you are happy for ide b4 sata
device.map file does not change

relink grub so its in the mbr of the ide drive hda...and links to hda1

root (hd0,0)
setup (hd0)

but if you stay with hda...your kernel line was / is a mess....kernels 2.6 and later can handle scsi or sata drives.

suggest
kernel /vmlinuz-(version) root=/dev/hda

2) if that is not what you meant or not what you want....because you want sata drive to be where / is....please be as explicit as possible thanks

Ok, I have more info.

I created a unique file on /dev/hda1, /dev/hda2, and /dev/sda1. I have verified that (hd0,0) is /dev/hda1, (hd0,1) is /dev/hda2, and that (hd1,0) is /dev/sda1 as far as the booting grub is concerned. These are the same mappings I see if I look in device.map. Everything here is consistent. That is one of the reasons I wanted grub installed on the IDE drive. It should be the first drive in all cases.

I went to the BIOS and verified that the boot order for the machine is the IDE device, sata1, and then sata2.

I messed up the cut/paste operations I did to post the original info, the 'setup' command for grub installed grub in the mbr for the IDE disk (hd0).

I am attempting to set the system up so I can boot either /dev/hda2 OR /dev/sda1 as the root partition for linux. I like to be able to install an upgrade, test it, and then upgrade my production partition. /dev/hda2 is the test root partition, /dev/sda1 is the production root partition. During this test process, I boot back and forth many times, and do it quite frequently over the network (changing the default value in menu.lst and rebooting). I am now that I am happy with my test upgrade, and am attempting to upgrade the production version on /dev/sda1. Unfortunately, I can no longer get it to mount.

To answer the other question that I know is coming, the /etc/fstab file on /dev/sda1 (the one that I cant seem to mount) correctly lists /dev/sda1 as the partition to mount on /.

I'd doubt it has anything at all to do with grub - it just loads the kernel (and initrd if demanded).
The initrd has to have the support for the pivot_root to succeed. I'd be looking there - except I never use initrd of course ...

then to make troubleshooting easier, especially if a kernel compile is suspect treat it as a simple dual boot

title hda
root (hd0,0)
kernel /vmlinuzetc root=/dev/hda1
initrd /initrdetc

title sata
root (hd1,0)......assuming you have a /boot folder not separate /boot partition
kernel /boot/vmlinuzetc root=/dev/sda1
initrd /boot/initrdetc

I am suggesting you can have one boot partition on hda that services hda
and one boot sub-folder to / = sda1.....but you don't mention if you have a /boot on sda....but I am suggesting you should rather than share

so bios jumps to mbr ide jumps to menu list on ide
hda is booted as above...sda is booted with kernel and initrd lines needed a /boot prefix

if that is wrong and you have a separate /boot partition on sda you know what to do...or read my signature

I am treating this as just another dual boot, is why I am so confused.

The two entries in my menu.lst file that are important are (there are a few others that I haven't cleaned up yet):

title 12.0 -- 2.6.21.5 -- generic smp / new installation
root (hd1,0)
kernel /vmlinuz-xyzzy ro root=/dev/sda1
initrd /initrd-xyzzy

title 12.0 -- 2.6.21.5 generic smp
root (hd0,0)
kernel /vmlinuz-generic-smp-2.6.21.5-smp ro root=/dev/hda2 hdb=ide-cd hdc=ide-cd
initrd /initrd-generic-smp-2.6.21.5-smp

The first boots and mounts /dev/hda2 as /.
The second boots and mounts /dev/hda2 as /.
Both have kernels/initrds located in the places specified above.

This same kernel/initrd used to work when /dev/sda1 was real SCSI and not a SATA drive, so I assume that pivot_root support was/is available during the boot. The thing that was interesting is that before, both entries had 'root (hd0,0)' entries, and they both worked.

If it was a kernel compile or initrd problem with sata , it seems you would be getting a kernel panic when using the sata drive root. I can't think of any circumstance where a recent 2.6 kernel would designate a ide drive, /dev/hda2, with an sda1 format but there may be kernel options which do that and that would only show up when a sata drive was attached. Somehow, your root=/dev/sda1 entry is mapping root to /dev/hda2 and for the life of me I can't figure out how that could be possible.

A lot of recent distros have gone to designating the root= entry in grub using the partition UUID instead of the device file. This is mainly due to the confusion caused by rolling all the ide drives into libata and giving ide drives sdx device file names in the recent kernels. They are also using UUID designations in fstab. Instead of using the device file, try using the UUID designation for sda1 in your grub entry for the new kernel. UUID will always point to sda1 regardless of the kernel naming. Boot up and run as root:

# blkid -s UUID

That will spit out the UUID indentifers for all recognized partitions. Find the one for sda1 and use that in your grub entry instead of the sda1 device. To demonstrate the syntax for UUID, here's how my sidux entry looks which is using UUID for everything instead of device files:

title sidux
kernel (hd2,7)/boot/vmlinuz root=UUID=7b5f311b-8108-45dd-ba17-ba50b8ea0a47 ro quiet vga=791
initrd (hd2,7)/boot/initrd.img

At least with the above, you can be sure that grub is unambiguously being directed to sda1 for root.

excellent idea....but I have a single sata...on Mdv.../dev/sda still works.

however, I appreciate all of fitz_lq attemps and just to be explicit how is sata set up for /boot....ie is sata /boot a subfolder to / or did you attempt to share it with hda /boot.

from your first post, I agree I am not interested in your non-essential partitions just the sata /boot either as a sub-folder or partition please

kilgoretrout....a small hijack

thanks for your uuid command.....I will probably update my grub howto as you think this may be an issue for some....as I said I never discovered it...as I have only one sata.

2) ways of uuid I found are...I use root powers for these:
blkid -s UUID
ls -l /dev/disk/by-uuid/
vol_id -u /dev/sda1

3) are you also suggesting that the OP should adopt an uuid fstab?

eg http://linux.byexamples.com/archives...tab-with-uuid/

thanks for any feedback and of course I hope this helps the OP

UUID (and LABEL) are fine in fstab.
Do *NOT* recommend them as generally available to the boot loader. These can only be used this early if the initrd has support for them. I suspect Fedora will fail if you pass a UUID to grub as the initrd probably only has LABEL support.

UUID? Just look in /dev/disk, you'll find that there are actually four ways of defining a partition using /dev/disk. I defined mine by ID for a change (using Debian, not Fedora - can't say what Fedora will do).

syg00

you appear to be correct
for others FYI see the label thread that David chats about here
http://www.groupsrv.com/linux/post-839460.html


I have just tested uuid for grub....and it works for me. Mdv using a distro kernel and initrd. I have not bothered to test fstab.

syg00 and kilgoretrout and any interested kernel hacker,

I can not hijack this thread any longer, altho the OP has not yet replied to the suggestions.

instead I have started a post on initrd and UUID support because it is not clear to me, that is the issue.

many thanks to all that have the time to read and offer any feedback.

http://www.linuxquestions.org/questi...6/#post3044296

Sorry about the delay, but I got blasted at work over the weekend.

Why the UUID should fix the problem, I have no idea, but I am a much happier camper now. Things are back to working. I am still puzzled as to what exactly caused the problem, so will continue to look around. If I can determine a cause, I will come back and add more detail.

Thanks to one and all for the comments.