On Wed, 15 Jul 2009, Artem Trunov wrote:

> Hi, all
>
> Found this old thread while trying to solve own hda/sda problem.
>
> I have installed SL5 on "hda" drive (and it was actually an IDE drive).
>
> Now I took the content of the root partition and cloned it to a second
> machine. This second machine also has an IDE drive, but a different
> brand, which is recognized as sdb (sda is bootable usb stick), not
> hda.
>
> Ok, so after I boot the second machine from the stick, partition the
> hard drive and close the image, I do chroot into the cloned partition
> and install mbr with grub shell. At the same time I notice that in
> chroot'ed env I have "/" mounted on /dev/hda, as reported by "df".
> While fdisk -l would still report /dev/sdb.

The df output will just be from the old mtab file (from when it was 
previously mounted), but will be replaced n a real boot...

> This is what I don't understand - where in the system it remembers
> that it was on /dev/hda before? I have only labels in /etc/fstab and
> grub.conf.
>
> Now, when I boot from the hard drive of the second mchine, is starts
> ok, loading the splash screen and boot image, but later it wont find
> the root partition and kernel panic in the process of boot. I suspect
> it's related to this fact that system remembers /dev/hda drive it was
> originally installed
>
> Any words of wisdom from SL gurus?
>
> If I clone to a machine whose HD is recognized as hda as in the case
> or ogriginal installation, all goes well. Only when a new HD is sda,
> it fails.

I'd guess that the problem is more that of guessing the BIOS hard disk 
order rather than whether the disks are sd or hd.

e.g. in the case you describe the installer may have assumed that sdb was 
the *second* disk since sda also existed.  However in the BIOS it probably 
has IDE/ATA/SATA disks before USB devices so the guessed order might well 
be wrong.  Hence you may end up with the grub config using (hd1,0) rather 
than (hd0,0) and then it won't find the kernel or initrd etc...

So what ends up in the sl /boot/grub/grub.conf after you have finished the 
installation?

Depending on when it fails it may also be that the initrd is lacking the 
support the this particular disk controller (since it wasn't there on the 
previous machine).

Is there a reason for installing machines this way rather than using the 
standard sl installer (which does a good job of fixing this stuff up 
automatically)?

  -- Jon