« previous: Upgrades: Ubuntu, Gnome, Firefox | next: IIS error: The page cannot be found »
Ubuntu Linux Hard Drive Upgrade
Filed on Oct 30, 2006 by / 14 repliesI 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:
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!
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?
Thanks for the info... i used it for upgrading my hard drive and it worked perfectly...
Thank you very much. Great help. I dont have exact same problem, but am tring to recover my ubuntu box.
Thank you !!
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.
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.
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.
just a tip. if you add the x to rsync you dont have to exlude stuff like /dev/ or memory filesystems.
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:
in my case I only had the original disk (hd0)
and the new diwk (hd1)
voila!
thanks again,
--dmg
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!!
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.
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.
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.
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.
Reply to this message here:
[ archives ]