Web Apps Since 2004.

Is your website boring?  Kick it up a notch.  Encodable apps easily drop into your website to make it modern, fun, and interactive, with features like file uploads, user accounts, paid subscriptions, protected pages, live chat, visitor logging, mailing lists, and more.
All Encodable apps include:
• Easy setup
• Lifetime license
• Free tech support
• Full customizability

« 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 ]

    Shopping Cart

    Client Quotes

    I just wanted to say that yours is the first product that I've tested so far that hasn't failed on handling uploads.  This is going to work for a print company, so they are handling nothing but large files and all the other solutions I've tried so far have not been reliable.  So far yours has been 100% successful in my tests.
    – Kevin H.
    I looked all over trying to find a simple cgi script.  I found that FileChucker was by far the best.  If you have issues with your hosting service's php.ini max upload size then this is the way to go.  Looking forward to future enhancements.
    – Bob C.
    Just one word: Fantastic.  10-minute job to plug FileChucker into my app, and it now works a treat.  It's through the hard work by people like yourselves that make my job so much easier.  Congratulations on an outstanding product... Many many thanks.
    – Sean F.
    FileChucker is a great drop-in solution for file uploads, and worth every penny of its very reasonable cost.  Encodable's support is excellent to boot.
    – Loren A.
    I just installed the demo of your product and got it up and running in no time.  I searched high and low for a decent login script and thank God I found yours.
    – Adrian F.
    I just want to say you guys really stand alone in that you have a quality product and you provide genuine customer service.  It's sad but those qualities are seldom found separately, much less together.  Thanks again for your time and help.
    – Alex S.
    You've done a wonderful job with FileChucker and UserBase, and they have made a big difference to how our website runs.
    – Nicholas H.
    Why didn't I just do this from the get-go?  So much easier.  Thanks for your work.  FileChucker makes my work easier.
    – Dominic M.
    Do you know how rare it is to have a "canned" shopping cart that can easily do complex pricing options on a single item?  Basically, they don't exist!  I have looked.  Everywhere!  And the few that might even come close to CornerStore's functionality cost a fortune!
    – Tashina P.
    FileChucker is working great...  Clients love it.  Vendors love it.  We love it.
    – Gerry W.
    FileChucker is helping drive the backend of several high profile entertainment sites for people like Shania Twain and Dolly Parton.  We're also using it to drive backend file uploads for a multi-billion dollar banking institution.  It's a great product.  We've tried other "chucking" upload solutions with progress bars using flash and php, but nothing works as reliably as FileChucker.
    – Michael W.
    Thanks again for a great product and great support - beyond expectations.
    – Greg S.
    The amount of customization in the program is incredible.  I was able to integrate it into my existing page layout relatively simply.  I was also able to easily customize the look/feel to match the current site.
    – Jason M.
    The work, the thought and the organization you put into this app is incredible.
    – Bruce C.
    I want to thank you for your efforts on Userbase. It has become an integral part of our business and has allowed us to branch out and begin using automation on a lot of our processes. Userbase has become the gateway to advancement for our company's processes for our clients and employees.
    – Guy Smith, Critical Signal Technologies
    Nice script, it's saving the day on our project.
    – Aaron W.
    Thank you VERY much for all of your help.  You've really impressed me.  We have support agreements for other software that costs thousands of dollars / year (just for the support), and most of them aren't as helpful as you have been.
    – Keith Y.
    Our members think your software is fantastic...  I would recommend your software and your company to anyone.  Thanks for all your help.  It has been a pleasure dealing with you.
    – Tommy A.