[tlug] Boot Failure with Transplanted HDD

[Dennis McMurchy <denismcm@example.com>]

  Hi All,

  I just resubscribed to the list for the first time in ages - just
hadn't had the time to keep up with it lately.

  I have a problem recently that I've seen a number of times over the
years and never got around to resolving.  Actually, I'm _almost_ sure
that I've used the same procedure successfully in the past. Anyway,
here are the details:

  I have two virtually identical machines.  I copy my working LiGnux
partition (yes, I know I should use more than one!) onto a spare HDD,
plug it into the spare machine and boot it from the same boot floppy
that will boot up my working LiGnux partition when necessary.  Of course,
I'm taking care to ensure that the mirrored partition ends up also
being /dev/sda1 on the spare HDD.  (For completeness, I should probably
mention that I'm using Partition Magic 5 rather than 'dd' to do the
partition mirroring - apologies to purists).

  The boot starts up just fine, the (SCSI) HDD is correctly recognized
and everything is going great up to and including the partition check,
but the first attempt to actually read from the HDD results in failure.
This is what that looks like (painstakingly transcribed manually):

	<snip>
	Attached ascsi disk sda at scsi0, channel 0, id 1, lun 0
	(scsi 1:0:1:0) Synchronous at 80.0 Mbyte/sec, offset 30.
	SCSI device sda: 17916240 512-byte hdwr sectors (9173 MB)
	Partition check:
	 sda: sda1 < sda5 > sda2 sda3
	Loading 8139too module
	/lib/8139too.o: init_module: No such device
	Hint: insmod errors can be caused by incorrect module parameters,/
	including invalid IO or IRQ parameters
	ERROR: /bin/insmod exited abnormally!
	attempt to access beyond end of device
	08:01: rw=8, want=2, limit=1
	EXT2-fs: unable to read superblock
	attempt to access beyond end of device
	08:01: rw=8, want=33, limit=1
	isofs_read_super: bread failed, dev=08:01, iso_blknum=16, block=32
	Kernel panic: VFS: Unable to mount root fs on 08:01

  I hope someone has some idea how to get around this glitch.  Since
this sort of strategy is the only convenient way to keep my machine in
Canada in sync with the one I use here, this is of more than just
academic interest to me.

   Cheers, PuzzledinChinatown

-- 
Dennis McMurchy,
Sointula, B.C. / Tojinmachi, Fukuoka
Canada           Japan