[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[SOLVED] Re: How to move debian from one drive to another and keep it working?



 
After having installed Debian to a partition on an old hard drive, connected to the motherboard's IDE controller, because the new drive (where I wanted to place Debian) wasn't recognized by the Debian installer CD (unsupported PCI controller), I found that I needed to transfer my working Debian system to a set of partitions on the new drive.  (The kernel installed by the Debian installer did recognize the PCI controller, whereas the CD kernel would not.)
 
Here is my report on how I was able to solve the problem:
 
First, I should note that I was installing 5 operating systems including Debian, so there were partitions galore on the two hard disks.  The relevant partitions on the old drive (for me) were
 
/dev/hda7     '/'
/dev/hda5     swap
 
The working copy of Debian on /dev/hda7 was used to partition the new drive (/dev/hdg) as follows:
 
/dev/hdg1     [other OS]
/dev/hdg2     /boot
/dev/hdg3     [other OS]
/dev/hdg4     ["extended" partition containing the following "logical" partitions]
/dev/hdg5     /
/dev/hdg6     /usr
/dev/hdg7     /tmp
/dev/hdg8     /var
/dev/hdg9     /home
/dev/hdg10    [empty]
 
I used 'fdisk' to create all of these partitions.
  Following instructions in the
Next, I had to create file systems (format) the Linux partitions.  I made hdg[25] ext2, and the rest ext3.  Following the instructions in the "Hard Disk Upgrade Mini How-To", I used 'mkfs.ext2' and 'mkfs.ext3' to do the job:
 
  mkfs.ext2 /dev/hdg2  (same for hdg5)
  mkfs.ext3 /dev/hdg6  (same for 7,8,9)
 
Then I had to mount the new partitions so that I could copy files to them.  The docs are not always newbie-friendly, so to make this absolutely clear I will show all the steps I performed.  Order matters as you mount the partitions.  My new root was going to be /dev/hdg5, so I ran this command:
 
  mount -t ext2 /dev/hdg5 /mnt
 
Now, the other partitions need proper places to mount, so I created directories for them in /mnt (which actually creates the directories on hdg5, not on the partition you are currently using):
 
  mkdir  boot  usr  tmp  var  home
 
The other partitions may then be properly mounted.  For my setup, this meant:
 
  mount -t ext2  /dev/hdg2  /mnt/boot
  mount -t ext3  /dev/hdg6  /mnt/usr
  mount -t ext3  /dev/hdg7  /mnt/tmp
  mount -t ext3  /dev/hdg8  /mnt/var
  mount -t ext3  /dev/hdg9  /mnt/home
 
The "Hard Disk Upgrade" HOWTO recommended changing the permissions on the /tmp directory for technical reasons.  As a newbie myself, I don't pretend to understand, but I went along with the expert advice:
 
  chmod  1777  /mnt/tmp
 
With the partitions properly mounted, it was time to copy files.  In order to kill most running processes and making it possible to copy all system files (and not have some blocked by running processes), the HOWTO recommended moving to single-user mode (runlevel 1):
 
  telinit  1
 
Since my working Debian was located on a single partition on the old drive, I could use the easiest of the 3 methods listed in the HOWTO.  (For others using 2 or more partitions, not including swap, for their working Linux, the HOWTO mentioned above gives 2 other methods to get your files transferred.)  I used:
 
  cp  -ax  /  /mnt
 
The "-a" option preserves the attributes of your currently working system as much as possible, and the "-x" option keeps 'cp' from copying files located in other file systems (in this case /mnt and /proc).
 
On my system, an emtpy /proc directory was created (at /mnt/proc), but if this hadn't happened I would have had to create a /proc directory with "mkdir /mnt/proc".
 
The HOWTO suggested checking the new file systems before trying to boot the copied system.  That meant unmounting the partitions first; the deeper directories in the structure have to be unmounted first):
 
  umount  /mnt/home
  umount  /mnt/var
  umount  /mnt/tmp
  umount  /mnt/usr
  umount  /mnt/boot
 
  umount  /mnt
 
Then the file system checker can be run on each partition:
 
  fsck.ext2  /dev/hdg5   (and hdg2, for me)
  fsck.ext3  /dev/hdg6   (and 7,8,9)
 
No problems on any of them for me.
 
The HOWTO also suggested it might be possible to see if the contents of regular files copied correctly.  (This takes a long time, and is merely optional.)  First, remount the partitions (same steps as above), then run (all one long command):
 
  find  /  -path /proc -prune -o -path /mnt -prune -o -xtype f -exec cmp {} /mnt{} \;
 
With the new partitions mounted, you can then edit the 'fstab' file to make the new copy of Linux use the new partitions instead of the old one(s):
 
  cd /mnt/etc
  nano fstab
 
I had to add entries for hdg5,2,6,7,8, and 9, and remove my entry for hda7 (see my partition scheme listed above).  I left the swap partition on the other drive, since it was located where I wanted it to be from the beginning.
 
I then had to edit 'menu.lst' so that I could boot to the new copy of Debian using 'grub'.  For me, the necessary changes were not obvious because I hadn't dealt with 'grub' configurations before.  As an oversimplified example, my original working Debian was configured this way in /boot/grub/menu.lst:
 
title    Debian GNU/Linux (...)
root    (hd0,6)
kernel /boot/vmlinuz...
initrd   /boot/initrd.img...
boot
 
What was confusing for a newbie, like me, was how to change "root," "kernel," and "initrd" in menu.lst to get Debian to boot from the partitions on the new drive.  Reading the docs for grub (after running "apt-get install grub-doc") still left me wondering what exactly to change.
 
I knew that the "root" had to be changed to point to the new partitions, but it was unclear whether it should point to the '/' partition (hdg5) or the partition with grub's files (hdg2).  Since this is grub we're trying to configure, it turns out that it has to point to the grub files.
 
Then, the kernel and initrd files are no longer in a /boot subdirectory on the partition where they are placed (in grub's eyes, at least), so both of those lines had to be altered.  Finally, the kernel needed to be told explicitly which partition contained the root ('/') directory.
 
I copied the lines for my working Debian in grub's menu.lst, and make the necessary changes.  With respect to the oversimplified example I gave above -- remember, I have 5 operating system configured in menu.lst, so I don't want to show the whole thing here -- the changes would have looked like this:
 
title    Copy of Debian GNU/Linux (...)
root    (hd1,1)
kernel /vmlinuz...  root=/dev/hdg5
initrd   /initrd.img...
boot
 
In this case, the "(hd1,1)" notation refers to hdg2, my /boot partition.  The kernel and initrd files are located in the root directory of that partition, which explains the location specified for "kernel" and "initrd".
 
When I went to reboot, I had a serious problem.  The initialization process began and appeared to work when I tried to boot Debian on the new partitions, but it screeched to a halt with the following 3 lines:
 
  /sbin/init: 431:  cannot create /dev/null:  Read-only file system
  /sbin/init: 432:  cannot open /dev/console:  No such file
  Kernel panic:  Attempted to kill init!
 
Not a good feeling for a newbie to have!  I supposed that something very essential had failed to copy from the /dev directory on my working version of Debian.  I rebooted to single-user mode on the working Debian, ran 'fsck' on the new partitions (like above), and mounted the root partition (hdg5):
 
  mount -t ext2  /dev/hdg5  /mnt
 
The I went looking in the /dev directory there:
 
  cd /mnt/dev
 
I found that there was very little listed there.  For example, these 2 commands
 
  ls /dev
  ls /mnt/dev
 
produced a large listing in the first case, but a very short listing in the second case!  So, I tried just copying /dev one more time:
 
  cp -a /dev /mnt
 
When I viewed the new /dev directory ("ls /mnt/dev") it seemed populated by the right stuff.  When I rebooted and tried the new copy of Debian again, everything worked!
 
 
That is basically the end of the story for anyone wanting a working copy of Debian on partitions located on a drive connected to a controller not recognized by the Debian installer.  For me, the struggle continues.  I want to make the new drive bootable -- only possible because of BIOS support on my controller card -- but that means installing grub to the MBR of the new drive.  So far, I haven't had any success trying to install grub there, but I've only begun to fight!
 
 
Thanks for the various help received from folks on debian-user, especially Jacob S. who pointed out the "Hard Disk Upgrade" HOWTO to me this morning.
 
Dave Witbrodt
 

Reply to: