How to move installation to a new Hard Drive?

jiml8 · 05-01-2007, 09:45 PM

/dev gets built very early in the boot process, when Linux is detecting what is connected to the system.

Quakeboy02 · 05-01-2007, 10:03 PM

Quote:

Won't work.

I agree. I had to do as you said about grub. I also did another one recently with a dual boot on a dmraid array. I couldn't make it work, and I'm reasonably certain that I ran exactly as you said. So, I've just accepted that automated grub-makers can do a better quicker job than I can. To fix the dual-boot dmraid I used "Super Grub Disk". I'd do it again.

rob.rice · 05-02-2007, 04:21 PM

Quote:

Originally Posted by jiml8

/dev gets built very early in the boot process, when Linux is detecting what is connected to the system.

the kernel still needs a basic set of nodes to do things like mount "/"
udev dosen't run untill after the kernel mounts "/" in read only mode
so you would need some nodes on the system befor udev runs

Quakeboy02 · 05-02-2007, 04:38 PM

Quote:

the kernel still needs a basic set of nodes to do things like mount "/"
udev dosen't run untill after the kernel mounts "/" in read only mode
so you would need some nodes on the system befor udev runs

You're looking at this backward. /dev is not usually on a separate partition. Thus, during boot, there is no /dev until / gets mounted. With no /dev, there is no need for /dev to be populated. Grub knows where the boot partition is to get the kernel. The kernel is loaded to memory and grub knows where the boot device is. Udev can populate /dev with no references to any previous contents of /dev. As I have already mentioned, /dev on the machine I tested with knoppix was empty as in nothing, no contents.

Speaking of knoppix: there is no need for /dev to be populated before knoppix starts. In fact, it would make the whole idea of a liveCD impossible.

hetOrakel · 05-03-2007, 05:22 PM

You all are great!

I partitioned the drive and copied everything but
/proc, /sys, /dev, /tmp like Quakeboy02 said. I copied /home to another partition.
I used tar for the copy: (/excludes contains the dir's to exclude)

tar cf - * -X /excludes | (cd /new_boot_drive_partition; tar xpf -)

after that, installed grub like jiml8 said. Editted /etc/fstab and /boot/grub/menu.lst and rebooted.
Everything is working fine!!!

Thank you all.

PS:

Quote:

Originally Posted by jiml8

Note that grub identifies hda as hd0, hdb as hd1,and so forth. Partitions count from 1, so hda1 is (hd0,1); hdb4 is (hd1,4) and so forth.

My grub counts partitions from 0.

And:
I have 3 disks sda sdb and hda.
When my bios boot-sequence is set to SCSI first the drives are identified as:
hd0 hd1 hda2 for sda sdb hda
When the boot-sequence is to HDD-0 first this is
hd0 hd1 hd2 for hda sda sdb
Is that normal?

jiml8 · 05-05-2007, 10:39 AM

Quote:

PS:

My grub counts partitions from 0.

D'uh!

You are absolutely right. I must have been having a major brain fart when I wrote that.

Quote:

And:
I have 3 disks sda sdb and hda.
When my bios boot-sequence is set to SCSI first the drives are identified as:
hd0 hd1 hda2 for sda sdb hda
When the boot-sequence is to HDD-0 first this is
hd0 hd1 hd2 for hda sda sdb
Is that normal?

Yes. The ordering that grub gives the drives depends upon the order they are detected by the BIOS. The implications for how you boot are obvious.

However, to accommodate changes in your drive organization, there is the device.map file which will be found in /boot/grub. This file allows you to dictate to grub which drive is to be named what, thus allowing you to maintain a system organization even when you move drives around.

For example, here is my device.map file:

(hd0) /dev/sdc
(hd1) /dev/sda
(hd2) /dev/sdb
(hd3) /dev/sdd

I constructed this map file after a drive reorganization (I removed a 4.3 gig and replaced it with a 50 Gig) caused my drive detection order to change. By creating this device.map file, I had to do nothing else to get the system to boot and come up with fstab working as expected.

daflame · 05-25-2008, 01:56 AM

Quote:

Originally Posted by Quakeboy02

You're looking at this backward. /dev is not usually on a separate partition. Thus, during boot, there is no /dev until / gets mounted. With no /dev, there is no need for /dev to be populated. Grub knows where the boot partition is to get the kernel. The kernel is loaded to memory and grub knows where the boot device is. Udev can populate /dev with no references to any previous contents of /dev. As I have already mentioned, /dev on the machine I tested with knoppix was empty as in nothing, no contents.

Speaking of knoppix: there is no need for /dev to be populated before knoppix starts. In fact, it would make the whole idea of a liveCD impossible.

That may be, but I have noticed (on my live system at least) that when I mount / there are /dev nodes there already, even though (as you said) there should be no need for that anymore. That may just be a carryover from an older system that I upgraded from though.

Also, as a side note I noticed no one mentioned mounting root a second time? If you want to make a SAFE root environment to copy, just mount your root, boot, tmp, etc partitions (no sys, proc or dev) on a subdirectory of / or /mnt, you can delete this temporary mount point later or exclude it from the copy:

[all partitions that you want to merge to one]
mkdir /mnt/newroot
mount /dev/(newrootdevice) /mnt/newroot

mkdir /mnt/oldroot
mount /dev/(oldrootdevice) /mnt/oldroot
mount /dev/(oldxxxdevice) /mnt/oldroot/(xxx)
(repeat to rebuild full partition to transfer without sys proc and dev)

Transfer to the new root system like so
cp -av /mnt/oldroot/* /mnt/newroot

Repeat the above for each new partition to create. The advantage of the above is that you are not limited to only recreating the same partition scheme, nor are you limited to your /tmp space as in the tar pipe method above. No need to use the x option as that would only harm the point of possibly merging partitions from the source if you need to (which I did).
Note: It may not be necessary to separate partition copying, but in my case I had a failing home partition that I could not copy safely so I did that separately.

Don't forget to unmount all devices and follow the grub install steps mentioned above.

chadwick · 12-30-2009, 02:04 PM

I just successfully moved the contents of my Debian installation to an external USB drive. So I can boot from my local hard drive or from the external drive, depending on what I specify to the BIOS. My distribution is Debian Squeeze updated just a couple days ago.

I found that I did in fact need to copy the contents of /tmp. Everything booted fine up to the gdm login, with or without the contents of /tmp. But without /tmp copied, when I tried to go beyond the gdm login, I would get:

Quote:

GDM could not write to your authorization file. This could mean that you are out of disk space or that your home directory could not be opened for writing. In any case, it is not possible to log in. Please contact your system administrator

I'm using Gnome.

This had nothing to do with the space left on any of the mounted drives since there was plenty of space on all of them. Nor did it have anything to do with permissions of any of the files or directories in my $HOME directory. To be absolutely certain, I changed /etc/fstab to mount my original /home partition (the uncopied one that works perfectly and resides on my local hard drive) and then rebooted the computer into the external drive (i.e. leaving out the new /home partition that's on the external drive, just in case something went wrong in copying to the new external drive). The same problem arose with the original /home partition mounted, but did not arise when I booted into the local drive which uses the same original /home partition.

I had only created the /tmp directory but had not copied its contents since I thought maybe the contents didn't matter. So I booted back into the local drive, recursively copied the /tmp directory from the local drive to the external drive:

Code:

root-prompt# rm -rf /mnt/sdb3/tmp/
root-prompt# cp -a /tmp/ /mnt/sdb3/

where /mnt/sdb3 is where I have the external / partition mounted (I have /tmp on the same partition as /).

Once I did this, I rebooted into the external drive and everything worked well. I was able to use X and my Gnome Desktop.

So I guess you might as well copy the contents of /tmp. I did however not copy, but did make directories for, /dev, /proc and /sys (by just using mkdir as root).

===========

Some extraneous info about my system perhaps relevant to the issue of not being to get beyond the gdm login:

X info (using X -version):

Code:

X.Org X Server 1.6.5
Release Date: 2009-10-11
X Protocol Version 11, Revision 0

Code:

Build Date: 13 October 2009  11:25:51AM
xorg-server 2:1.6.5-1 (buildd@murphy.debian.org)

GDM (using gdm --version):

Code:

GDM 2.20.10

Using Gnome Desktop (looking under System->About GNOME):

Quote:

Version: 2.28.0
Distributor: Debian
Build Date: 11/21/2009

Linux kernel (uname -snrvmo)

Quote:

Linux lucky 2.6.30-2-686 #1 SMP Fri Dec 4 00:53:20 UTC 2009 i686 GNU/Linux

daflame · 01-03-2010, 08:20 PM

Quote:

Originally Posted by chadwick

I found that I did in fact need to copy the contents of /tmp. Everything booted fine up to the gdm login, with or without the contents of /tmp. But without /tmp copied, when I tried to go beyond the gdm login, I would get:

Did you make sure to set the permissions of /tmp to 1777 ?
chmod 1777 /tmp

The extra 1 sets the area as a user owned read/write only temp space. Without that you have all kinds of errors that pop up.

chadwick · 01-03-2010, 08:32 PM

Quote:

Originally Posted by daflame

Did you make sure to set the permissions of /tmp to 1777 ?

Come to think of it I didn't. That was almost definitely the problem then.

daflame · 01-03-2010, 08:39 PM

Quote:

Originally Posted by chadwick

Come to think of it I didn't. That was almost definitely the problem then.

Most likely was, if you copy the directory then all permissions are copied automatically and that is the best way in my opinion anyhow.

ttguy · 09-22-2010, 10:36 AM

So I had to do this recently and found this thread had useful info spread through it. I put together this "how-to" that might be useful.
The process can be divided into 7 main steps:

1. Physically Install your new drive in the machine
2. partition and format the new drive
3. Move your linux swap
4. Copy the old file system to the new drive
5. Change fstab on the new drive so it mounts the new drive as root
6. install the bootloader on the new drive
7. Change the bios so it boots from the new drive

I will expand on these steps below

1. Physically Install your new drive in the machine
Plug it in.

2. partition and format the new drive
partition and format it using System>Administration>Gparted and/or System>Administration>Disk Utility

You probably want to move the linux swap to your new drive too. So you should use Gparted to create two partitions on your HD.

One large one: with an Ext3 or Ext4 files system on board and with a boot flag set on it (use Gparted . Manage Flags to set the boot flag). The size of this partition can be =[total disk size - swap size (eg 6gig)]

A second partition for the linux swap: This needs to be created inside an extended partition. So create an extended partition using Gparted. And then create a linux swap partition inside this extended partition.
Use GParted to format the paritition to linux-swap.
https://help.ubuntu.com/community/SwapFaq discusses how much swap you might want. I have a about 6gig.

Make sure you can mount your new large partition - Use Disk Utility to test mount it.

While you are in disk utility make note of what device your new drive attaches to the system as and what device your old drive comes in as. The addition of a new drive can change the device labelling.

I note that my old drive is /dev/sda1 and my new partition where I want my new install to be is /dev/sdc2.
My new swap is /dev/sdc5

I did things incrementally. So at this point I want to see if we can successfully move the swap to the new disk.

in a terminal window type:

Code:

sudo blkid

The results returns info about all the partitions your system can see. The results on my system included

Code:

/dev/sdc5: UUID="0aad67ee-f3cc-45c4-ad55-92da827fde1f" TYPE="swap" 
/dev/sda5: UUID="471c8224-aefa-45e0-b711-9debc98cb254" TYPE="swap"

one of these is the existing swap partition - /dev/sda5
and the other one is my new swap on /dev/sdc5

So we need to change the /etc/fstab (file system table) so that we will boot to the new swap.
backup fstab:

Code:

cd /etc
sudo cp fstab fstab_bu

edit fstab:

Code:

gksudo gedit fstab

There will be line in fstab that mounts your existing swap
eg

Code:

UUID=471c8224-aefa-45e0-b711-9debc98cb254 none swap sw 0 0

- note how the UUID of this line matches the UUID for sda5 as returned by blkid

duplicate this line
Comment out one of the duplicates with a hash
edit the other one so the UUID matches the UUID of the new swap partition as returned by blkid

And you end up with:

Code:

#UUID=471c8224-aefa-45e0-b711-9debc98cb254 none  swap    sw   0       0
 UUID=0aad67ee-f3cc-45c4-ad55-92da827fde1f none  swap    sw   0       0

Save the modified fstab

Now Reboot.

After the system comes back in a terminal do

Code:

 swapon -s

and it should return something like

Code:

Filename				Type		Size	Used	Priority
/dev/sdc5                               partition	6209080	0	-1

Which tells me that my swap is on /dev/sdc5 - my new partition.

So we have successfully moved our swap to our new drive.

4. Copy the old file system to the new drive

Now we move the main boot partition.

use sudo blkid to get the UUID of the new drive

eg

Code:

/dev/sda1: UUID="a45017f8-cff6-4bee-8369-f8b288ea0ca9" SEC_TYPE="ext2" TYPE="ext3"  <- current drive
/dev/sdc2: UUID="30c4ac3a-5da9-4e68-ba6e-6d9f30c23117" SEC_TYPE="ext2" TYPE="ext3"  <- new drive

Also check how your grub is setup
run grub:

Code:

sudo grub

at the grub> prompt

Code:

grub> find /boot/grub/stage1

Mine returns:
(hd0,0)

This means we are booting from /dev/sda1 (hd0 = a and ,0 means partition 0 which is the 1 in the sda1.)

quit grub with the quit command.

Now we want to copy all the files from the old to the new drive and we want to do this while none of the files are in use.

So we need to boot to a live CD of Ubuntu.
after the live CD of Ubuntu starts open a terminal

pwd
returns "/home/ubuntu/"

make a directory for mounting the new disk

Code:

sudo mkdir newdisk

mount the new disk. mine has a ext3 file system and the new disk is /dev/sdc2 - yours might be different

Code:

sudo mount -t ext3 /dev/sdc2 newdisk

mount the old (existing) disk at the /mnt directory. my old disk is /dev/sda1 - yours might be different.

Code:

sudo mount -t ext3 /dev/sda1 /mnt

Now we can see our old disk at /mnt and our new disk at /home/ubuntu/newdisk

Now we need to copy the files from our old to our new disk. Various posts to this thread offer up various copy commands that can be used

sudo cp -axuv /mnt/* /home/ubuntu/newdisk
or
sudo cp -a /mnt/* /home/ubuntu/newdisk
or
sudo cp -vax /mnt/* /home/ubuntu/newdisk
or
sudo cp -av /mnt/* /home/ubuntu/newdisk
or
sudo cp -rpf /mnt/* /home/ubuntu/newdisk

you can decide what is the best copy command. I used the first one -axuv
There is not much difference between these commands

one critical thing is the -a switch which makes it do recursive copy of directories, preserving the file mode ownership and timestamps and not following the symbolic links in the source.

I chose the one with x in it because I did not want to copy my /home folder that actually lives on a different file system. But leave the x out if you would like to merge partitions from the source

man page on cp tells me

-v, --verbose explain what is being done

-a = --archive same as -dpR
-d same as --no-dereference –preserve=links
--no-dereference never follow symbolic links in SOURCE
-v, --verbose explain what is being done
-x, stay on this file system
--preserve[=ATTR_LIST]
preserve the specified attributes (default: mode,owner‐
ship,timestamps), if possible additional attributes: context,
links, all
-p same as –preserve=mode,ownership,timestamps
-u, --update copy only when the SOURCE file is newer than the destination
file or when the destination file is missing

-R, -r, --recursive copy directories recursively

-f, --force if an existing destination file cannot be opened, remove it and try again

Various posts mention that you do not want to copy /tmp , /dev
/proc and /sys but create directorys for them. The trouble with creating directories for these by hand is getting the directory permissions correct. So what I did was copy these directories too but then I deleted the files from them on the /home/ubuntu/newdisk
delete files from /home/ubuntu/newdisk/tmp and /home/ubuntu/newdisk/dev

Running nautilus as root can be handy for this:

Code:

gksudo nautilus

I found that /proc and /sys did not have any files

5. Change fstab on the new drive so it mounts the new drive as root

Now we want to modify the /etc/fstab that will be the fstab when our new drive boots up. we want to tell it which
disk to mount as root

Code:

gksudo /home/ubuntu/newdisk/etc/fstab

This fstab file will be copy of your old one. Find the line in it that mounts root (look for the / )
mine is

Code:

UUID=a45017f8-cff6-4bee-8369-f8b288ea0ca9 / ext3    relatime,errors=remount-ro 0       1

which is the UUID of /dev/sda1 identified previously by blkid
Duplicate this line. Comment one of them out and edit the other one pasting in the UUID of the new drive
Thus:

Code:

#UUID=a45017f8-cff6-4bee-8369-f8b288ea0ca9 / ext3    relatime,errors=remount-ro 0       1
UUID=30c4ac3a-5da9-4e68-ba6e-6d9f30c23117 / ext3    relatime,errors=remount-ro 0       1

6. install the bootloader on the new drive

Now we need to setup the bootloader on the new drive to boot from the correct partition.

modify the menu.lst on the new drive in /boot/grub by putting the above UUID in place as described below.

Backup the old menu.lst to /boot/grub/menu_bu1.lst

Code:

sudo cp /home/ubuntu/newdisk/boot/grub/menu.lst /home/ubuntu/newdisk/boot/grub/menu_bu.lst

edit the menu.lst

Code:

gksudo gedit /home/ubuntu/newdisk/boot/grub/menu.lst

towards the end of the menu.lst file you see "## ## End Default Options ##"
and after this is a list of kernals you can currently boot to. If the start of the file says default 0 then the first item in the list is the kernal that will boot by default.
We need to make this the kernal that lives on the new drive. So I copy the first two titles and change the titles on them to something appropriate - eg add new drive to the title.
And you replace the UUID on the kernal line and the UUID on the uuid line with the UUID of the new drive as returned by blkid above
eg:

Code:

title		Ubuntu 10.04.1 LTS, kernel 2.6.32-23-generic - new drive
uuid		30c4ac3a-5da9-4e68-ba6e-6d9f30c23117
kernel		/boot/vmlinuz-2.6.32-23-generic root=UUID=UUID=30c4ac3a-5da9-4e68-ba6e-6d9f30c23117 ro quiet splash 
initrd		/boot/initrd.img-2.6.32-23-generic
quiet

title		Ubuntu 10.04.1 LTS, kernel 2.6.32-23-generic (recovery mode) new drive
uuid		30c4ac3a-5da9-4e68-ba6e-6d9f30c23117
kernel		/boot/vmlinuz-2.6.32-23-generic root=UUID=UUID=30c4ac3a-5da9-4e68-ba6e-6d9f30c23117 ro  single
initrd		/boot/initrd.img-2.6.32-23-generic

We also need to run grub to set up the master boot record correctly on the new drive.

so...

Code:

 
cd /home/ubuntu/newdisk/boot/grub/
sudo grub

at the grub prompt

Code:

grub> find /boot/grub/stage1

Mine returned
(hd0,0)
(hd2,1)

What I think this means is that there are now two options where you could boot from hd0,0 and hd2,1. hd0,0 was what grub reported before and is /dev/sda1

hd2,1 is the new drive
hd2 = disk c (a=0,b=1,c=2).
The ,1 is partition 2

so hd2,1 = /dev/sdc2 = our new disk

So we want to set up hd2 to boot from - so at the grub prompt type

Code:

setup (hd2)

It reports something like

Code:

 Checking if "/boot/grub/stage1" exists... yes 
 Checking if "/boot/grub/stage2" exists... yes 
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes 
 Running "embed /boot/grub/e2fs_stage1_5 (hd2)"...  20 sectors are embedded. 
succeeded 
 Running "install /boot/grub/stage1 (hd2) (hd2)1+20 p (hd2,1)/boot/grub/stage2 
/boot/grub/menu.lst"... succeeded 
Done.

quit grub.

7. Change the bios so it boots from the new drive

We are almost done now. There are two bootable disks on the system now. And it is now up to the computers bios as to which one will boot the PC. So we need to shut down the live CD and remove the disk and restart the PC.
If you just let the PC boot it should boot fine from your old drive which you have not changed. - This is a back-out strategy.

However, if you boot and then hit the del key (or whatever it is that you do to enter your computers bios set up) you can then change what disk the PC boots from first. You need to select the new disk as the first boot disk.

If you do this then it should boot up off your new drive.

You can check after you log in by using the disk utility to check if your new drive is mounted at root (/)

If you fail to boot to the new drive then use the bios settings to put the old one back.
and ... post to this thread maybe.