How to replace a hard drive...

Peter King peter.king-H217xnMUJC0sA/PxXw9srA at public.gmane.org
Thu May 12 18:51:15 UTC 2011


Things just get curiouser and curiouser.

I can boot from Sysresccd with the option "boot from an existing 32/64 bit Linux
system on disk" and, apart from a hiccup because the kernel on Sysresccd is older
than my kernel, it all loads without any problem. The existing installation, by the
way, is 64-bit kernel/userland.

Having gotten up and running in this fashion, I decided to re-install grub, and again 
to do so manually in the standard way:
   #grub --no-floppy
   grub> root (hd0,0)     <-- location of /boot, a.k.a. /dev/sda1
   grub> setup (hd0)      <-- install grub to MBR of /dev/sda
   grub> quit
It all seemed to work just fine. The grub.conf was unaltered, putting boot at (hd0,0)
-- which, confusingly, is written "root (hd0,0)" like above -- and then identifying the
location of the rootfs at /dev/sda3. This is the *exact* configuration on the old hard
disk, which works fine.

Yet somehow, when things get going, it all stalls and gives up after detecting the
keyboard. Must be a problem handing off to the rootfs somehow. But how? Sysresccd can
find the rootfs with no trouble.

Right after detecting the keyboard, as far as I can tell what happens in order is:

   * loading /sys
   * loading debug-fs
   * running udev

The natural suspect is /sys. That's as far as I can get. But this can't be all that
odd a situation -- surely others have tried to mirror hard drives, and the procedure I
used seems to be ordinary enough -- so why did it blow up? I don't really understand 
grub, but then again my ignorance hasn't posed any difficulties before. Now I really 
have run out of ideas. Suggestion, even wild ones, would be welcome.

-- 
Peter King			 	peter.king-H217xnMUJC0sA/PxXw9srA at public.gmane.org
Department of Philosophy
170 St. George Street #521
The University of Toronto		    (416)-978-4951 ofc
Toronto, ON  M5R 2M8
       CANADA

http://individual.utoronto.ca/pking/

=========================================================================
GPG keyID 0x7587EC42 (2B14 A355 46BC 2A16 D0BC  36F5 1FE6 D32A 7587 EC42)
gpg --keyserver pgp.mit.edu --recv-keys 7587EC42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://gtalug.org/pipermail/legacy/attachments/20110512/b4dc3ec4/attachment.sig>


More information about the Legacy mailing list