Search site

Add to Google

Send a comment back

If you are not a registered user, your comment will be moderated and may be deleted subsequently by the author if it is deemed to contain inappropriate materials. All embedded URLs will automatically be turned into anchors, so there is no need to wrap them in HTML tags

by:Guest User
Your Name:
Your URL/Blog
(to link back to your site):
Workshop 1: Post installation problems for cloned Ubuntu drives back
Previous article: Workshop 1: clone NTFS and Linux partitions into a smaller disk view


Following on from the previously described workshop, I did notice a few niggling problems with using the newly cloned disk in another machine. Obviously, if you plug the disk into a machine of completely different hardware, you'd need the hardware drivers for it. This is not exactly the point for cloning. You usually clone so you do not have to re-install all the updates and service packs, or tweak the customisations on each machine, but usually you want the machines to be as similar in hardware specifications as possible. So why do we still get post installation problems ? Well, I found that surprisingly in cloning, Windows is more tolerant than Ubuntu. It will happily boot up a cloned partition without complaining too much (Windows however is very sensitive to changes in the partition table, even if the changes are nothing to do with its own partition, but that is another story).

The main problems I had were to do with Ubuntu, which seems to embed a lot of knowledge about the disk into its various files. The main thing is the UUID of the partitions, which get referenced in various configuration files in /etc and /boot. The few tell-tale signs of booting up a cloned Ubuntu partition are:

  • GRUB fails to boot, complaining the disk it is looking for is not present i.e. the ubiquitous error 21
  • No Ubuntu splashscreens displayed while booting
  • Ubuntu spashscreen is displayed, but half way through the boot sequence it switches to verbal text mode

GRUB fails to boot with error 21

One aspect of GRUB that really confuses me is it sometimes uses the UUID of the disk, while other times it uses the Windows style of disk addressing e.g hd0,0. Hell, it even understands the old UNIX fomat e.g. /dev/sda1. The UUID is a unique universally generated identifier for a particular partition, with the well meaning intention that it does not matter where you place the partition on the disk, it can always be uniquely located by GRUB in the boot process. This is an improvement over the old /dev/sda1, /dev/sda2 scheme, where the partitions are order dependent. Anyway, I digress. Let's say at the time you installed Ubuntu, the disks were not in the same order as when you finally deploy them. For example, I had three hard disks, one in the IDE slot, while the two others were plugged into the USB ports. Why ? because I was too lazy rebooting the Live CD, which takes ages. The disks would have been allocated names by the kernel as /dev/sda for the one in the IDE slot, then /dev/sdb and /dev/sdc for the two in the USB slots. Let's say if the Ubuntu partitions occupy the second position in each disk, they would be /dev/sda2, /dev/sdb2 and /dev/sdc2, respectively. These then translate into the Windows addressing scheme as hd0,1, hd1,1 and hd2,1, respectively. The Ubuntu installation process then installs GRUB on to, say, /dev/sdb, which would have written out the config file /boot/grub/menu.lst as:

## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd1,1)

Then when you swap the second disk into the IDE slot of a machine and boot it up, and bingo!, error 21. GRUB looks for the second disk, which is no longer there.

This is only one of the scenarios, merely to illustrate the point on how you can hit the dreaded error 21. All is not lost if this happens, you simply have to boot the machine up using the Live CD again, and mount the partition /dev/sda2 on to /mnt (sudo mount /dev/sda2 /mnt), then edit /mnt/boot/grub/menu.lst and /mnt/boot/grub/ files to change all references of hd1,* to hd0,*. Finally, you run sudo update-grub to update GRUB with these changes, then sudo grub-install to push the changes out.

No Ubuntu splashscreens displayed while booting

You deploy the newly cloned disk into the new machine it boots up fine, but for some reason the Ubuntu splash screen is not displayed while booting. The screen is completely blank. Usually, the way to fix this is to run sudo dpkg-reconfigure usplash to redeploy the splash screen. However, I discovered that for me it did not work. It took a while for me to finally nail down the problem, which is to do with the resolution of the machine which I ran the installation on (which has a default screen resolution of 1400x1050) and the machine the cloned drive went into (which has a resolution of 1024x768). This will completely push the Ubuntu splash screen off the screen's frame buffer. The remedy for this is to edit the file /etc/usplash.conf and change the xres and yres parameters, then re-run the command sudo dpkg-reconfigure usplash. Of course, you can force the vga resolution by passing the vga={code} parameter into the kernel boot parameter, as described here, but my take on this is the usplash mechanism is smart enough to update the boot image to position the splash screen without having to manually override it in the first place, as long as you give it a helping hand with the xres and yres parameters.

Booting process keeps switching back to text mode

Here is another problem. The splash screen first shows, then after a while it simply switches back to verbose text showing boot progress. It does not really affect the machine's functions after it fully boots, but it drove me crazy. I have got to the bottom of it finally, so would like to share here the findings.

It seems the Ubuntu splash progress screen is extremely sensitive to the swap space, and if for any reason this space is out of acttion, it will exhibit the behaviour described here. One reason for the swap space to be out of action is again to do with the UUID mentioned above. The swap space is usually the third partition on the disk, which provides an extension to the physical memory in the computer. The kernel will automatically swap the contents between this swap space and physical memory when and if it needs it. If the UUID is not correct due to the cloning, the swap space will be unreachable to the kernel. You will need to boot up the Live CD, mount the partition, and then edit the file /mnt/etc/fstab file to replace the UUID of the swap partition with that of the one on the cloned disk (this is described in details in the last article).

One other file which also references the UUID of the swap space is /etc/initramfs-tools/conf.d/resume. Once replacing the UUID in this file, you need to run the command sudo dpkg-reconfigure initramfs-tools in order to rebuild the boot image to incorporate this change.


Previous article: Workshop 1: clone NTFS and Linux partitions into a smaller disk view

 by by David at 22 Feb 2009 22:34:15
Copyrights © Transcraft Trading Limited 2006.All rights reserved.