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<[email protected]> wrote: > On Wed, Jul 15, 2009 at 12:16, Artem Trunov<[email protected]> 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. >
