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
