« previous: Upgrades: Ubuntu, Gnome, Firefox | next: IIS error: The page cannot be found »

Ubuntu Linux Hard Drive Upgrade

# Filed on Oct 30, 2006 by Anthony DiSante / 16 replies

I needed to upgrade the hard drive in my Ubuntu Edgy Eft (6.10) system.  I first connected the new drive via USB enclosure and partitioned it, then copied my whole system onto it using rsync:

# rsync -av --delete --exclude /mnt/newdisk / /mnt/newdisk

Then I shut down, removed the old hard drive, and put the new one in.  But the system wouldn’t boot because there was no boot manager on the new disk’s MBR.  So I booted the Rescue Is Possible (RIP) Linux boot CD and at the grub prompt, I hit ’c’ to get a command prompt.  Then I did:

grub> setup (hd0) (hd0,0)

...which installs grub into the MBR of hd0 (hda) using the boot files that were already in /boot on hd0,0 (hda1).

Then the system booted, but the progress bar on the Ubuntu splash screen didn’t move at all.  After a few minutes it dumped me onto a text console which said:

ALERT! /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx does not exist.
Dropping to a shell!

BusyBox v1.1.3 (Debian 1:1.1.3-2ubuntu3) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
(initramfs)

Of course: because every disk has a different UUID, and the UUID of the old disk was still referenced in my /boot/grub/menu.lst file.  At this pseudo-shell prompt, I looked into the /dev/disk/by-uuid/ directory to find out what the new UUID was (and had to write it down, ugh).  Then I booted the RIP disc again to edit my menu.lst file and replace the old UUID with the new one.

Then the system booted a little more, but still got stuck -- because of course, /etc/fstab was still referencing the old UUID.  Again I booted the RIP disc and updated the UUID in the fstab file.  I also replaced "ext3" with "reiserfs" in there because I made the new disk’s partition a Reiser one instead.

Now the system really booted, but GDM gave me an error on an ugly GUI-made-of-text screen.  Apparently the filesystem was mounted read-only.  I could remount it manually, but why was it doing that in the first place?

I ran "dmesg" and saw this near the end of the output:

ReiserFS: hda1: warning: bad value "remount-ro" for option "errors"

So apparently the "errors=remount-ro" bit in the fstab file that worked fine for ext3 did not work with ReiserFS.  I removed that, rebooted, and finally the system booted successfully with the new hard drive.

Comments:

01. Jan 21, 2007 at 06:53am by Ben Margolin:

Good stuff... I was just about to do something very similar, but had already realized the UUID stuff was going to cause me trouble. The grub command you’ve got there is highly useful, thanks!

02. Jul 9, 2007 at 10:54am by W. James MacLean:

Can you give details of how you did the partitioning when the drive was connected as a USB drive? Did you use fdisk? Also, would it be possible to use vol_id to get the UUID info and change it on the new drive, so all that was left was to use ’setup’ to install grub?

03. Oct 15, 2007 at 02:32pm by ne0ph0enix:

Thanks for the info... i used it for upgrading my hard drive and it worked perfectly...

04. Dec 3, 2007 at 12:49am by sant paija:

Thank you very  much. Great help. I dont have exact same problem, but am tring to recover my ubuntu box.
Thank you !!

05. Dec 3, 2007 at 01:47am by Anthony DiSante:

Sorry for the late response on this!

Quoting W. James MacLean:

Can you give details of how you did the partitioning when the drive was connected as a USB drive? Did you use fdisk?

cfdisk, actually.  It’s like fdisk except that it’s actually usable.

Quoting W. James MacLean:

Also, would it be possible to use vol_id to get the UUID info and change it on the new drive

I’m not sure about that.  If you’re asking whether it’s possible to change a drive’s UUID, I suspect the answer is no.

06. Dec 8, 2007 at 03:17am by Brent Woodfield:

Yes, it is possible to use vol_id to get the UUID and update your fstab and grub’s menu.lst files.  The proper command would be sudo vol_id /dev/sda1 or whatever the device you want to know the UUID on. Simple as that.

07. Dec 8, 2007 at 05:47pm by Anthony DiSante:

Quoting Brent Woodfield:

Yes, it is possible to use vol_id to get the UUID and update your fstab and grub’s menu.lst files.  The proper command would be sudo vol_id /dev/sda1 or whatever the device you want to know the UUID on. Simple as that.

Yes, but when James asked whether it was possible to "get the UUID info and change it on the new drive", I thought he was referring to actually changing the UUID of the drive itself -- not updating your config files with the new UUID -- and I don’t believe that is possible.  I think a drive’s UUID is a permanent fixed value.

08. Feb 3, 2008 at 11:39am by Oystein Eliassen:

just a tip. if you add the x to rsync you dont have to exlude stuff like /dev/ or memory filesystems.

09. May 19, 2008 at 02:06am by d. german:

Thanks a lot!

I was able to upgrade the disk without any problems following your instructions.

I did, however, update /etc/fstab in the new disk before I installed it (using vol_id to get its id).

I also run grub from the old disk, in my case I first updated /boot/grub/menu.lst, then I run grub and used

setup (hd1) (hd1, 0)

replaced the disk, and ubuntu booted without any problems.

Recapitulating:

  • I copied the entire disk using rsync -a -x

  • I then updated the /etc/fstab of the new disk

  • I updated /boot/grup/menu.lst of the new disk

  • run grup with command setup (hd1) (hd1,0)

    •   in my case I only had the original disk (hd0)
      and the new diwk (hd1)
  • formatted the swap partition

  • replaced disks

  • rebooted

    • voila!

    thanks again,

    --dmg

    10. May 30, 2008 at 04:37am by malapin:

    Ok! it works for me. I change hard disk in a Kubuntu 7.10 machine from the old 40Gb to the new one 200Gb.
    I have difficulties to edit file /boot/grub/menu.lst and /etc/fstab with the boot CD "RIP" because i don’t know how.
    I edit this files with a live CD Kubuntu 7.10 mounting the new hard disk in a temp folder.
    Thanks a lot!!

    11. Jul 8, 2008 at 05:27pm by mooneroid:

    FWIW, it should not be impossible to change the UUID on a disk.  See this page: http://ubuntuforums.org/archive/index.php/t-479047.html 

    For those of you wanting to clone your disk to one exactly the same size, these directions are perfect.  For those wanting to upgrade to more space, use gparted (or something similar) after the dd command completes to resize partitions to utilize the bigger space.  This will make sense after you’ve read the directions linked above, and maybe my experience below.

    I just followed these directions (with the partition resize tweak), cloned my existing 80 GB drive to a 250 GB drive with dd, resized partitions to use the bigger space (because dd copies the partition table), replaced the 80 GB with the 250 GB in my system (laptop) and the computer boots fine.  No UUID problems at all, because dd copied the old UUID to the new disk.  Now my two disks have the same UUID, and automount has problems mounting the original 80 GB when I put it in an enclosure.  I tried the ’mk2fs -U random /dev/sdb1’ command and was told ’command not found’, and I can’t connect the laptop to the internet currently to find that utility

    So, while I can’t vouch for it personally at the moment, it should be possible to change the UUID on a disk.  And for all of you wanting to replace your disk with a bigger, use dd instead of rsync, cp, tar, or anything else.  It’s much easier.

    12. Jul 8, 2008 at 05:39pm by mooneroid:

    I found the replacement for the mk2fs command, which is no longer available in Ubuntu.  Simply replace it with tune2fs.  So, to change the UUID of a partition, use ’tune2fs -U random /dev/sdb1’ (or whichever device you’re targeting).  Worked for me, and I’m up and running.  Happy camper.

    13. Jul 8, 2007 at 06:15pm by AnthonyDiSante:

    Quoting mooneroid:

    I tried the ’mk2fs -U random /dev/sdb1’ command and was told ’command not found’

    The more common command is mke2fs; have you tried that?  The filesystem type is "ext2" which is what the "e2" in the command means, so I’m not sure there even is an "mk2fs" command.  Google returns a few results for it, but they appear to be mostly typos, and there are 100x more results for mke2fs.

    Sounds like you’ve taken care of it with tune2fs instead, though, which works too, modifying the UUID of the filesystem after it’s created, rather than setting the UUID at the time of filesystem creation with mke2fs.

    Quoting mooneroid:

    And for all of you wanting to replace your disk with a bigger, use dd instead of rsync, cp, tar, or anything else.  It’s much easier.

    I wouldn’t do it with cp or tar, but I still prefer rsync to dd.  Both have their strengths, but I generally prefer to cfdisk & mke2fs the new partition normally, then rsync all the files over to it, rather than messing with dd, which copies empty space as well, plus the partition table, etc.

    14. Jul 8, 2008 at 06:52pm by mooneroid:

    mke2fs didn’t have an option for just changing the UUID, as far as I could tell.  I found references to that tool a lot as well when I searched for mk2fs.  They are not (were not?) the same tool.  I’m pretty sure tune2fs is the right tool for that job. 

    I guess using dd and then resizing partitions is about the same amount of work and complexity as using rsync and then editing some files.  They both get the job done.  I was just very impressed at how slick using dd was.

    Thanks for this post.  I’m always interested in broadening my horizons and learning more good ways to do things.  And I’m glad to share what I’ve found to help others do the same.

    15. Feb 24, 2009 at 12:41pm by Vitke:

    Copying a live system from within itself can get you into trouble, like it got me with 8.04. Some files are locked and won’t copy, like ~/.gvfs, so finally some things did not work, for example the network. You can boot the system from a CD to avoid this problem.

    Next, add the -H option to rsync to copy the hard links too. You may want to rsync it over the network with -e ssh.

    Next, -x option ensures that you don’t copy other file systems, but if you have some parts of your file system mounted to some mount points within the same file system, like I have /home on /chroot/hardy-ia32/home, then rsync will copy your data twice and possibly use up your disk. You should umount these things prior to rsyncing. Take a look at /etc/fstab to see what is mounted.

    16. Feb 25, 2009 at 12:41am by AnthonyDiSante:

    Quoting Vitke:

    Copying a live system from within itself can get you into trouble

    Booting from a Live CD to do the job is probably a good idea.  However, I’ve used the method here (copying the system while live) to clone systems quite a few times, and I’ve never had any of the problems that you mention.

    I don’t think there are many hard links in the system files, or at least, none which would cause any problems if they were simply each replaced with the full file individually; and I think they’d get "fixed" during future software updates anyway.

    Regarding the -x option for rsync, I should have mentioned that I --exclude things like /proc, /mnt, etc; I left that out of the command for simplicity’s sake...

    Overall, I agree: booting from a Live CD to do the rsync is probably the best way to go.

    Reply to this message here:

    Your name
    Email (why?)
    Website (if you have one)
    Subject
    search posts:

    [ home | archives ]