Tuesday, April 17, 2012

How to upgrade a Wubi install

Yes it's that time again. A new Ubuntu release is around the corner, and that means that many people will be upgrading. If you have a Wubi install and look for advice, you'll probably be sternly warned that "Wubi wasn't intended for long term use... blah blah yawn". That's all great, but you're using Wubi and want to upgrade, and the reality is many people will do it anyway.

Upgrades fail

Shocking, but true. Ubuntu upgrades do fail. Frequently. Many people swear by fresh installs. Personally, I've upgraded to every release since 9.10 and with Wubi testing since 8.04. And 9 times out of 10 they worked okay (for me). The upgrade to 10.04 was probably the worst as you had to Ctrl-C at some point during a loop etc.

But nonetheless, every install is different and many fail (Wubi and normal both). So what to do?

Backup

This is a no-brainer. It's so easy to write it and read it and agree with it. But the way that the Update Manager suddenly jumps up "A new release is available. Do you want to upgrade?" - it seems so easy to just click that button. Even without reading the release notes (which may help you but not in all cases).
So... DON'T DO IT. Not until you've got a disaster recovery plan in place (the work-speak way of saying you have a backup and know how to restore it).

You should probably already have all your important data backed up, stored on the /host or other normal partition (or synched to Ubuntu One). Because data on the virtual disk is at a higher risk of being lost.

Full Wubi backups

On Wubi, it's really simple to do make a fully bootable backup. If you installed on your C: 'drive', then boot Windows, and copy the entire C:\ubuntu\disks folder. It's going to be big, so make sure you have enough free space, or copy it to an external drive if you need to. If things go wrong during the upgrade, you just have to copy it back and you have a full Ubuntu restore.

Preparation for upgrade

Make sure you have enough free space on the root.disk. Many people underestimate how much space is needed (and apparently the Ubuntu upgrade process also underestimates it, or has in the past). Personally I would make sure there's 5GB free, maybe 3GB minimum (that's sucking it out of my thumb, but the message is don't try it with the bare minimum).  Note, you can also resize the root.disk if you need to. At the same time, process all updates to the current release before hand.
To check free space, run df -h from the terminal (Ctrl+Alt+T). You're looking for the amount of free space on /dev/loop0 (that's the 'loop-mounted' root.disk)

Browse the forums

Take the time to see how bad the upgrade is. Other people will be doing it and posting the results (if they are bad). Get a feel for what the problems are.

Alternate CD upgrade

I strongly recommend using the Alternate CD to upgrade. Why? Because when the new release comes, every man and his dog starts to upgrade, and the servers struggle. So a 1 hour download suddenly becomes 3 hours or longer. Or times out. And you're up at 2am watching it (because at some point you're going to have to click that darn "OK" button for some meaningless prompt, or else you'll have to do it when you wake up).

Whereas, if you download the Alternate CD ISO, using a bittorrent client, it will likely take 30 minutes. Then you upgrade offline (maybe not recommended by Canonical, because this stops you downloading the latest packages) and you've just saved yourself a couple of hours. 

There's no rush

It's not going to hurt you to wait a month to upgrade. At that point, it should be very clear what problems there are if any, and there may even be fixes. Also the servers will be quieter, so doing an online upgrade gets you the latest packages. You can still run the Alternate upgrade, but let it download the latest packages online (still quicker than downloading all the new packages).

Caveats

Normally by this time in the development cycle, I've run a few Wubi upgrades. So I'm usually speaking from a position of knowledge that the upgrade can work. This time, I've been unable to test due to one of my computers dying, and a bunch of other time consuming things. Maybe I'll get the time to do this still (9 days to go as at the time of writing, in which case I'll add a comment to indicate that).




Update: I ran two upgrades, 10.04 to 12.04 and 11.10 to 12.04. I ran both online (not with the alternate CD - it helps having a 50Mbps connection and minimal server traffic). I confirmed that 2 GB is too little space - it downloads about 1800 packages and 'unpacks' them - and this uses a lot of space (that is mostly freed up at the end). So be warned - the upgrade tool does not stop you running out of space.
The 11.10 upgrade was on a real, in use installation, and worked flawlessly. The 10.04 was on a brand new, bare-bones 10.04.4 install with updates applied, and gave a number of errors and some weirdness (empty message box with 2 unknown buttons) - but succeeded as well.

Summary
1. Backup (always prepare for the worst)
2. Minimum 3 GB free space (preferably more)
3. 1800 packages to download so consider using the Alternate CD to speed things up

Another update: if you have a custom graphics driver, or use ppas, then it seems to be recommended to remove these before upgrading, and then reinstall following the upgrade.

Wednesday, April 4, 2012

How to migrate - updated for release 12.04 Precise Pangolin

A new version of the Wubi migration script will be released for Ubuntu 12.04 Precise Pangolin. There have been some minor changes that are required for release 12.04, and a few features added.

The simple migration hasn't changed

It's still straightforward to do a migration, for example if the target partition is /dev/sda5 and the swap partition is /dev/sda6, you can migrate as follows:
sudo bash wubi-move-2.2.sh /dev/sda5 /dev/sda6

New features

These are some of the changes with version 2.2 of the script:
  • Simplified interaction
  • Improved validation and diagnostics
  • Migrate to separate target partitions e.g. for / (root), /boot, /usr, and /home
  • Run migration validation pre-check without making any changes
  • Resume a migration that failed due to e.g. a corrupt file, without having to recopy everything
  • Synchronize a migrated install (e.g. to keep a fully bootable backup)

More information

For full instructions run:
bash wubi-move-2.2.sh --help

How to download

As usual, you can download the script from the HOWTO: migrate wubi install to partition thread on ubuntuforums.org. Select the file wubi-move-2.2.tar.gz, download, then right-click, and Expand. This will create a new directory with 3 scripts: wubi-move-2.2.sh, check-source.sh and check-targets.sh.

How to migrate in pictures






How to migrate from a root.disk

In the following example, the partition containing the root.disk is labeled 'wubi install' so the mountpoint is: /media/wubi install (including the space). This needs to be 'escaped' with '\' when specifying the location as shown in the screenshots below. Note also that this example uses a swap partition that is already used by another install (so option --shared-swap is specified to prevent running mkswap):


How to migrate to separate partitions

In the following example, there is a separate partition for /boot and /home in addition to the standard target (/) and swap partition. In addition, this example uses the  --shared-swap and --no-bootloader option:


Some notes on --resume and --synch

The new options --resume and --synch are designed to save time, either when the migration terminates due to rsync copy errors, or a refreshed migration is desired. Normally the script will only proceed on an empty partition (to prevent loss of data), so these options are the only way to bypass this - and they make use of rsync's sychronization ability to only copy files that are missing/changed.

Since this does introduce a little risk, these options rely on a control file created the first time the migration is started. This ensures that the target partitions are the same as on the prior run. In other words, resubmit the migration command in the exact same way, but append --resume on the end.

The idea behind the --synch option is to keep a bootable backup e.g. on an external drive. This can be quickly syncronized prior to performing major updates (like an release upgrade). 
Warning - synchronization will remove anything added to the migrated install that's not on the source install (in other words, don't use this option if you are actively using the migrated install).
This option is probably more useful for non-Wubi installs, so use it after you've migrated from Wubi (the script works on normal installs too).