New release of Wubi migration script

I've released a new version of the Wubi migration script (wubi-move-2.0.sh). Here are some of the new features:

• You can migrate either Wubi or a normal install. It detects the type and handles accordingly. This is useful if you want to move your regular Ubuntu install, keep a working backup, or do some experimentation without jeopardizing anything. Also for Wubi users who migrate and then need to re-jig their partitions, it makes it easier to move the install (without worrying about UUID changes).
• It now supports grub-legacy. This was one area that was lacking - I don't know how many people have Wubi with grub-legacy, but there have been a few requests. So the migration supports releases with grub-legacy: 8.04 to 9.04 (as well as those that have been upgraded to 9.10 and later). The caveat is that the script replaces grub-legacy with Grub2 on the migrated install - so you probably don't want to be doing this prior to release 9.10 (I don't know how robust Grub2 is on 8.04.4, for example).
• It also supports migration from a root.disk file with the --root-disk= option. I had already come up with a manual solution for this before and it didn't seem too big a deal to add in to the script. So if you have a good root.disk, but you've lost the ability to boot into it, or you want to migrate to another machine, you can now boot a live CD and migrate from it. The root.disk must be a working, fully-contained Wubi install i.e. not have separate virtual disks for /boot, /usr or /home. (This rules out grub-legacy where /boot is always on the /host Windows partition.)
• Finally there are some minor tweaks. The new option --shared-swap will bypass the 'mkswap' command to preserve the UUID on the swap partition. Useful if you have multiple installs and you want to share the existing swap partition.
• I also split the output from --help into two separate options: --help and --notes to suppress the flood of output.
• Other notable changes - better validation, better error handling, for instance if there is an error in the chroot, the script attempts to cleanly unmount from the chroot before exiting. 

Testing all the possible scenarios and releases is a challenge. I've done a number of cases from releases 8.04.4 to 10.10 (except 8.10) including Wubi and non-Wubi, with Grub2 and Grub-legacy. But as always community feedback is always welcome.

Anticipating Natty Alpha 2 with Wubi

So, it's Alpha 2 week and what better time to check out Wubi again. But the news isn't good. In fact, things have gone from bad to worse. Before you could install Natty Wubi by replacing the buggy wubildr with a working Maverick copy to kick-start the installation. Now it just results in a loop in the installler (ubiquity) saying "No root filesystem has been defined".

So much for that... Let's try the upgrade option instead.

And the silver lining is... that the upgrade from Wubi Maverick to Natty was very smooth. No errors. No strange popups. No Afghanistan keyboard. In fact, the only thing I noticed was an "error: file not found" as grub booted into kernel 2.6.38-1.

So upgrading a Maverick install is still the preferred way to go if you want to test Natty on Wubi.

PS I didn't expect the fresh Natty Wubi install to work because the Natty wubi.exe hadn't been updated (since early December). And the new installer bug isn't too surprising either - it's Alpha after all and you need to expect these things. However, I do think it's fair to expect that sometime between December 2nd and February 2nd that the developer would have done one or two unit tests on Wubi.exe and discovered the problem  (or at least noticed the bug report).

To be honest, I'd prefer they stopped messing with Wubi Natty and fixed the far more important Lucid Grub issues... but I know that's not likely to happen.

Just today there was someone on Ubuntuforums.org who had their computer completely wiped (Factory restored) by some lousy 'tech support' due to the Wubi grub rescue issue. These are real, live, normal people trying out Ubuntu and it'd be nice if the devs took that a little more seriously.

The mystery of the disappearing root.disk

In the past month or so I've noticed a small but noticeable number of users losing their root.disk files (or the entire \ubuntu\disks\ directory). The reason for this is unclear and, so far, the recovery rate is 0%.

In one case, booting from a live CD and running "ls /host/ubuntu/disks gave the following:
# cd /media/win/ubuntu/disks
# ls -l
# d??????? ? ? ? ? ? disks

It's hard to know from the other side of the internet what attempts have been made to recover. But suggestions to run chkdsk don't seem to fix the problem. It's also impossible to know whether this is a new Wubi problem or whether this is a regular issue that has always affected Wubi. Time will tell.

What can you do in this case? The best insurance is a regular backup of your root.disk file, or the important contents contained within.

On that note, I also saw a thread where a user tried to reinstall Wubi to fix a problem. Reinstalling Wubi will always remove the current install, delete the root.disk, and destroy any existing Ubuntu data/settings.

"Just uninstall"
Unfortunately I also see many community members advising Wubi users to uninstall because they assume the problem is Wubi-related. Often this is not the case, but rather it is a normal Ubuntu problem that can be solved (and would still have to be solved after replacing Wubi with a normal install). It is important to let these well-meaning members know that this advice could destroy the user's important data. It's not hard to add a cautionary warning, and perhaps suggest to the user how to recover data from a root.disk from Windows (e.g. http://ext2read.blogspot.com/) before uninstalling.

A final comment... in my opinion, reinstalling an OS is not a solution to a problem - it's the last resort when there is no solution. All too often I see users quickly reinstalling at the first sign of a problem e.g. when their master boot record MBR is overwritten by Grub2. This is the simplest thing to fix and doesn't damage installed OS's or their data, so if they could just resist the urge to give up and reinstall it would save them a lot of trouble.

And remember - you can rid yourself of Wubi, but not lose any of the look and feel, settings or data on your current Wubi install, simply by migrating. There is a new migration script coming soon that supports grub-legacy (Wubi installed prior to release 9.10 and later upgraded) as well as migrations from a live CD/USB simply by pointing at a root.disk file.

WUBILDR, WUBILDR.MBR and GRLDR

It's fairly common to see messages such as Try (hd0,0) : FAT16 when booting Wubi. Usually it's innocuous, but sometimes booting fails. You might see it stuck on Try (hd0,0) : Ext2  


Rarely you'll see something like:
Try (hd0,0) : FAT16: No WUBILDR
Try (hd0,1) : NTSF5: No wubildr
Try (hd0,2) : FAT32: No WUBILDR
Try (hd0,3) : invalid or null
Try (fd,0) : invalid or null
ERROR: Cannot find GRLDR in all devices: Press ctrl+alt+delete to restart


So what does this all mean, and what is GRLDR? 


Wubi uses GRUB4DOS combined with Grub2 to boot Ubuntu. GRUB4DOS has two parts: grldr.mbr and grldr. Wubi has renamed these to wubildr.mbr and wubildr (you are free to rename them as long as you insert the new name of grldr in the .mbr file). 


The wubildr.mbr file corresponds to a grub legacy bootloader in the Master Boot Record. It is limited to scanning all partitions to find the rest of itself - the part that doesn't fit in the tiny MBR. These are the messages you see as it scans all partitions - and since it is based on grub legacy it outputs partitions with a zero index (unlike Grub2 which still uses zero based indexing on the drives, but not on partitions) i.e. hd0,0 in wubildr.mbr corresponds to hd0,1 in Grub2.


No matter where wubildr.mbr is, when it is called, it starts scanning the root on ALL partitions in the order dictated by BIOS to find the wubildr file. If it doesn't find it, you get an error that it can't find GRLDR, not WUBILDR. The reason it says GRLDR is likely a hardcoded message - for Wubi it's always WUBILDR that it can't find.


So what are the reasons for failure to find WUBILDR? 
1. The rather obvious, but unlikely - there is no WUBILDR 
2. Excessive fragmentation apparently
3. The wubildr file is > 137GB from the start of the partition
4. You have an ext4 partition that is read prior to the one containing WUBILDR.

WUBILDR.MBR cannot read ext4 partitions. The GRUB4DOS code it uses is from 2007 and it simply hangs when it encounters one of these. If you have an ext4 partition higher up in the BIOS order than your Windows partition, you're out of luck.

Some interesting points: when you install Wubi it installs WUBILDR.MBR and WUBILDR to the windows drive C:. But it also installs it to other partitions, like recovery partitions. If these happen to be physically before the windows partition, WUBILDR.MBR will find this WUBILDR and never use the one on your C: partition (it uses the first one it finds). And this is interesting as Grub2 updates the WUBILDR on your /host partition - not always the one used. Maybe this is a clue as to why Grub2 updates no longer boot on some installs.

Natty 11.04 Alpha 1 Upgrade with Wubi - Latest

I ran the Natty upgrade again today from my backed up maverick root.disk using the daily Alternate CD (January 12*). There are some interesting changes. For one, lots more errors during the upgrade including one saying the whole upgrade failed. But it didn't.

And a nice change is that as I logged in - forgetting to switch from Unity to the Classic desktop - there was a popup informing me that my hardware did not support unity and, would I like to switch to classic? Great! It didn't work, but a good idea all the same - and I assume it will work soon.

So after re-creating the 'logout launcher' I escaped Unity and switched manually to Classic Desktop and then it logged in fine (apart from having to reload all the crashing panel objects.)

Here are some pics from the upgrade process. The following popup appeared at least 3 times (and might have something to do with the fact that Natty has my keyboard set up as USA/Afghanistan now) ...

This one looked serious:

This one sounded like it was toast:

Despite the serious message - the upgrade worked, Natty booted first time... and nothing too exciting has happened since.

* I ran the upgrade from the daily image of the Alternate CD on January 10 and January 12 successfully. The images shown are from Jan 12; there were no material differences that I've noticed between the two. When I attempted to do it on Jan 11 it wouldn't allow the upgrade to begin due to some package with an incorrect version. The message is, if you find that the upgrade fails one day, just wait and try the following day (this is normal for alpha testing since the repositories are updated frequently and sometimes packages get out of synch). Also, be careful if you are offered a Partial Upgrade when running the Update Manager in Natty. Sometimes this is required but often it's an out of synch set of updates so it's best to be sure - use apt-get update and dist-upgrade to figure out what will be removed and decide whether it's an error or required.

Wubi and hibernation

Wubi doesn't support hibernation... out of the box. But as Agostino Russo (all hail the creator) points out this is only because Wubi uses swap files, not partitions (if you could partition, why use Wubi?)

So yes it's true you can hibernate a Wubi install. And if you're just using it to test, you may well already have a swap partition lying around, so why not use it? Especially with 10.04 and 10.10 that seem to be a bit heavier on memory use than 9.10.

To set up hibernation on Wubi is the same as on a regular install. Just take the UUID of the swap partition and make sure it's in /etc/fstab and /etc/initramfs-tools/conf.d/resume. Then run "update-initramfs -u" to update the initial ram disk to point to it and look for it to resume from hibernation.
For example, assuming your swap is /dev/sda7:
$ sudo blkid /dev/sda7
/dev/sda7: UUID="xxxxxx" TYPE="swap"

$ cat /etc/fstab | grep swap
UUID=xxxxxx none swap sw 0 0

$ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=xxxxxx

# if that's all good
$ sudo update-initramfs -u

Hint: if you are already using the Swap partition elsewhere don't run mkswap again or it will change the UUID.

Note: if you don't have a swap partition lying around and want to create one, make sure that it's big enough - to be safe I'd say the size of your RAM plus 1GB for overflow. Then run "sudo mkswap /dev/sda#" substituting # for your new swap partition and continue with the instructions above.
But if you're going to start creating partitions, I'd just take it one step further and migrate the Wubi install.

Warning on modifying Wubi Boot menus

When you install Ubuntu with Wubi, there really should be a release note popup - and it should contain some warnings:
1. Make sure you backup
2. Don't mess with the boot menus
3. Don't update packages grub-pc and grub-common

Well what can you say about point 1: Obvious. Point 3: covered ad nauseum already. But let's look at Point 2.

For some reason, many people are irritated about there being 2 boot menus. And they decide to remove one of them. And as I'll explain, that's not a good idea.

The first thing they try is to remove Grub. But grub is a little too smart for that - it prevents itself from being hidden if it detects multiple OS's. So you're out of luck unless you happened to find Ulrich Meierfrankenfeld's nice workaround.

So the next thing they try is to mess with the Windows Boot Manager. They have already noticed that the Grub menu already has an entry for Windows, so - they think - why not just set Ubuntu as the default in the Windows Boot Manager, and then set the Timeout to zero.

What they fail to realize is that the Windows option in Grub, does indeed boot Windows, however, Windows boots using it's Boot Manager - and they've just set that to boot Ubuntu automatically without a delay or prompt. Bye bye Windows.

So what can you do?
Apparently holding down the F8 key doesn't work as it's supposed to...

So if you're on XP, you can manually edit the boot.ini file from within Ubuntu to change the timeout - just be VERY careful - if you add the wrong line endings (i.e. carriage return/newline) then you'll be able to boot nothing - just get a HAL.DLL error.

If you're on Vista/7 I think you're out of luck. You will need a Windows repair disk and use the command line bcdedit to modify the timeout.

Final note, don't install burg on Wubi. It tends to install itself in the drive Master Boot Record and this stops your computer from booting.