Hi, all
Thanks to all for valuable comments. I am convinced now my problem was
in the right sata driver missing from the initrd image made on the
"hda" system (or a system trying to load a wrong driver for the disk
hosting new / partition. The trick I did was to rebuild initrd with
--fstab option pointing to the fstab file on the cloned disk, i.e.
/mnt/sdb1/etc/fstab. This way mkinird checks on what disk a would-be /
partition resides and inserts corresponding driver in the initrd
image.
Also, some colleges here advised to build a "fat" custom initrd,
containing many drivers, that can be then used for image cloning on
different hardware.
Thanks again for the help.
Artem
On Wed, Jul 15, 2009 at 9:16 PM, Billy Crook<[log in to unmask]> wrote:
> On Wed, Jul 15, 2009 at 12:16, Artem Trunov<[log in to unmask]> wrote:
>> This second machine also has an IDE drive, but a different
>> brand, which is recognized as sdb (sda is bootable usb stick), not
>> hda.
>
> It is worth mentioning that sd and hd have nothing whatsoever to do
> with the brand of drive, and they actually also have nothing to do
> with what type of cable is in use. What actually decides whether you
> get sd or hd device names is which driver you are using to access that
> storage. In the past, IDE had different drivers than did SCSI and
> SATA. The IDE drivers used hd the sata and scsi drivers used sd. The
> IDE driver names related to exact positions. I.E. hdc was ALWAYS the
> secondary master. Even if there was no primary master or slave.
> Today libata is the most commonly used driver. It includes support
> for most ide and sata controllers, and libata happens to make sd
> device names. libata (and AFAIK all block storage controller drivers
> using the sd namespace) just assign starting from a in the order
> detected. Which letter you get should be considered to be completely
> arbitrary and volatile. Instead of referencing /dev/sda1, reference
> LABEL= or /dev/disk/by-*/*. Those methods will be stable across
> reboots and hardware changes.
>
|
