Wubi migration/resize script user support

One thing I liked about the Tips & Tutorial section on ubuntuforums.org was that users could post questions, give information, read others' questions and see the answers, etc. in a single place. From my point of view, in addition to being able to help users, I got great feedback as to how my scripts were used and what issues users were facing.

But the forums staff decided that the wiki's were the way to go. And I'm good with that (the reasons go beyond my own personal needs)... but I know that since that time, the once-regular questions have almost completely died away - and the support requests that I do see are randomly dispersed and often I don't get to see them until it's too late.

I'm specifically referring the Wubi migration and resize scripts that used to be here and here respectively. Now they are in the Wiki: https://help.ubuntu.com/community/MigrateWubi and https://help.ubuntu.com/community/ResizeandDuplicateWubiDisk

So, where can users go for help or just to discuss some issues? I don't really know. Of course you're welcome to email, but then that's not shared with the community. You could open issues in github, but that's more for code issues than support.

At this time, I recommend creating a new support thread on ubuntuforums.org, and then send me a PM there so I can come and find it. It means that the support requests will be watered down (not all in one place for other users to browse), but they'll still be searchable.

Wubi development and customisation

Wubi is managed by the Ubuntu-installer team. But you can still fix bugs and submit it to them to review, approve and merge. Or if you just want to create your own version of Wubi... how do you go about it?

To start off I am using a vanilla install (so I don't miss any steps). It happens to be a Wubi install, but this doesn't matter.

1. Preparing your machine

Install some packages that you'll need to get started:

sudo apt-get install packaging-dev

2. Launchpad setup

This involves registering on launchpad.net, signing their code of conduct (which involves creation of a GnuPG key), adding an SSH key (which you'll need if you want to push your code back to launchpad). You can find help for this on launchpad itself.

3. Identifying yourself

You should now have GnuPG and SSH key setup. Identify yourself to the debian packaging tools by adding the following lines to your .bashrc:
e.g.

export DEBFULLNAME='bcbc'
export DEBEMAIL='openbcbc@gmail.com'

To make the change take effect run:

source ~/.bashrc




4. Download the code for Wubi

First identify yourself to bzr (and launchpad):
e.g.

bzr launchpad-login bcbc
bzr whoami "bcbc <openbcbc@gmail.com>"

If you're working on the development release you can download it using:

bzr branch lp:wubi

If you want a production release e.g. precise, instead use:

bzr branch lp:~ubuntu-installer/wubi/precise

This will confirm the RSA fingerprint on the server and ask you to unlock your own SSH key; then download the code. Now you should review the README and compile wubi.exe because the first time you do it, it installs and configures wine and other software you require (there is a lot to install, when prompted accept the defaults except for a few things like accepting the EULA):

make

6. Make your changes
So in this case I'm going to fix a really easy bug. This affects 12.04.1 wubi.exe (but I'm fixing it in the dev branch 13.04). It doesn't matter, it will have to go in there as well. The problem is that with long term releases, not all flavours of Ubuntu get updates. So while there is a 12.04.1 release of Ubuntu/Kubuntu/Edubuntu etc., there isn't one for Lubuntu. And the 12.04.1 version of wubi.exe won't install a 12.04 version of Lubuntu.

There is a check that allows a 12.04 version of wubi.exe to install a 12.04.1 release, but I believe that's an error - it should be the other way round.

So, let's find the bug and the affected code. Here's the bug: https://bugs.launchpad.net/wubi/+bug/1043607 and here's the relevant output:

08-29 21:38 DEBUG CommonBackend: Checking C:\ubuntu\install\lubuntu-12.04-desktop-i386.iso
08-29 21:38 DEBUG Distro: checking Lubuntu ISO C:\ubuntu\install\lubuntu-12.04-desktop-i386.iso
08-29 21:38 DEBUG Distro: wrong version: 12.04 != 12.04.1

The highlighted part shows you where to find the code: its in distro.py which happens to be in src/wubi/backends/common (search on "wrong version" since the release numbers are variables...) and then make the fix. Here's the diff after fixing.:

=== modified file 'src/wubi/backends/common/distro.py'
--- src/wubi/backends/common/distro.py 2012-04-24 15:57:38 +0000
+++ src/wubi/backends/common/distro.py 2012-10-30 21:17:02 +0000
@@ -166,7 +166,7 @@
         if self.name and name != self.name:
             log.debug('wrong name: %s != %s' % (name, self.name))
             return False
-        if self.version and not (version == self.version or version.startswith(self.version + '.')):
+        if self.version and not (version == self.version or self.version.startswith(version + '.')):
             log.debug('wrong version: %s != %s' % (version, self.version))
             return False
         if check_arch and self.arch and arch != self.arch:

7. Edit the changelog

You can use dch -i to add a changelog entry. It does some automatic stuff for you, but make sure you correct the release number or it names it 12.10ubuntu1. Otherwise just use your favourite editor. Note: I'm not really sure of the convention here - but only the Ubuntu-installer team can merge changes to the main Wubi branch, so they'll sort that out if they have the time to look at it.

So here's what mine looks like:

wubi (13.04) UNRELEASED; urgency=low

  [ bcbc ]
  * Allow Wubi to install earlier release ISOs on LTS (LP: #1043607)

 -- bcbc <openbcbc@gmail.com>  Tue, 30 Oct 2012 14:41:50 -0700

8. Commit the changes

bcbc@ubuntu:~/wubi$ bzr commit -m 'Allow Wubi to install earlier release ISOs on LTS - LP 1043607'Committing to: /home/bcbc/wubi/                                                                  
modified debian/changelog
modified src/wubi/backends/common/distro.py
Committed revision 274. 

If you messed up, run bzr uncommit and you can change and recommit. It doesn't remove your changes, just the commit.

9. Push to a new branch

bcbc@ubuntu:~/wubi$ bzr push lp:~bcbc/wubi/lp1043607
Using default stacking branch /+branch-id/30119 at chroot-74436368:///~bcbc/wubi/
Created new stacked branch referring to /+branch-id/30119.    

10. Link it to the bug
Go to the page for the branch you just pushed: https://code.launchpad.net/~bcbc/wubi/lp1043607
Now you can link the bug report and open a merge request.

11. Final comment
You probably noticed I forgot to test my patch. That's not a good idea. So once you have made you changes you should run make again to build wubi.exe. You can find it in the build directory. You can copy that to your Windows machine and test it - or view the README for other test options.

PS. If you want to build a custom Wubi for your own ISO, review the README as well. It tells you what you need to change.

Getting ready for Ringtail

With the news that the Ubuntu 13.04 Raring Ringtail repositories are in place, I decided to try a different approach this time to using the development release. Usually, at some point in the cycle, I'll try out an upgrade - and if it seems usable - I'll keep it (I always have a full backup just in case).

With 12.04 Precise Pangolin the development release was really stable so I quite happily used it actively throughout the cycle... but unfortunately it wasn't quite as good with 12.10 Quantal Quetzal and I found that I relied more on my non-wubi 12.04 Edubuntu install (although that wasn't entirely without problems either).

The down side of switching to the development release is that I lose touch with the latest production release , which is more useful in keeping track of current issues, and since I'm not upgrading my Edubuntu machine I want to keep both 12.10 and 13.04 on the same machine (with Wubi).

I already have a Wubi-resize script that will duplicate a Wubi install (and keep it in synch). I've added a custom menu entry to boot the sychronized disk to make sure it's functional. Now I need to be able to switch and run independent Wubi installs (without the tedium of booting to Windows to manually switch the root.disks).

So that led me to my latest testing approach:
1. Duplicate the up-to-date 12.10 install using the Wubi resize script and rename the new.disk to raring.disk
2. Add a custom boot entry for this raring.disk
3. Manually update /usr/share/lupin-support/grub-mkimage on the Raring install to stop it splatting /wubildr whenever there's an update to Grub (which would make the raring intall the default)
4. Turn off Ubuntu One synchronization and other automatic backups on the Raring install
5. Go nuts without worrying about breakage

Here's the custom boot entry (modify the one on root.disk only and change the highlighted bits):

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Ubuntu - Raring Ringtail' --class ubuntu --class gnu-linux --class gnu --class os {
        gfxmode $linux_gfx_mode
        insmod gzio
        insmod ntfs
        set root='(hd0,msdos3)'
        search --no-floppy --fs-uuid --set=root 18B4B7BBB4B799A8
        loopback loop1 /ubuntu/disks/raring.disk
        set root=(loop1)
        linux /vmlinuz root=UUID=18B4B7BBB4B799A8 loop=/ubuntu/disks/raring.disk ro quiet splash $vt_handoff
        initrd /initrd.img
}

Here's the diff on grub-mkimage (modify the one on raring.disk only):

--- /mnt/usr/share/lupin-support/grub-mkimage 2011-09-20 03:44:44.000000000 -0700
+++ /usr/share/lupin-support/grub-mkimage 2012-10-29 22:02:55.784517389 -0700
@@ -112,7 +112,7 @@
         exit 1
     fi
 fi
-
+exit 0 # for raring test install, bypass creation of wubildr
 wubildr_partitions="$(find_wubildr)"
 
 if [ ! -f "$target" ] && [ -z "$wubildr_partitions" ]; then

Now all I have to do is wait for something exciting to happen with Ringtail:

Tricking Wubi into installing Xubuntu 12.10

Xubuntu is no longer available on Wubi from release 12.10 and later - as I mentioned here: Xubuntu option to be removed from Wubi. However, there are some people that will want to try it out with Wubi anyway, so here's a way to do it.

Disclaimer: I don't recommend the technique I describe here, but it works fine if that's what you want to do.

It involves downloading two ISOs, one for Xubuntu and another one supported by Wubi. I'll choose lubuntu since it's the smallest.

1. Dowload the smallest supported ISO: lubuntu-12.10-desktop-i386.iso
2. Download xubuntu-12.10-desktop-amd64.iso (I want 64-bit, but you can use 32-bit too)
3. Check the xubuntu md5sum (Wubi will check lubuntu, but you need to check xubuntu).
4. Download wubi.exe for release 12.10
5. Make sure wubi.exe and the lubuntu ISO are in the same folder. Run Wubi and select lubuntu. 
6. When it tells you to reboot, select "Reboot later".
7. Replace C:\ubuntu\install\installation.iso with the Xubuntu ISO (renaming to installation.iso)
8. Mount the Xubuntu ISO and copy initrd.lz and vmlinuz from the /casper/ directory over the one in C:\ubuntu\install
9. Edit the preseed.cfg file in C:\ubuntu\install\custom-installation\ so that it installs xubuntu-desktop instead of lubuntu-desktop
10. Reboot the computer
11. Select Lubuntu
12. Watch Xubuntu install
13. Reboot, select Lubuntu and boot into your new Xubuntu install.

You don't strictly need to predownload the lubuntu ISO but it's faster than letting Wubi do it. If you decide to use the Ubuntu ISO instead of lubuntu you do have to download the ISO beforehand (because Ubuntu defaults to the preinstalled diskimage and that won't work with this technique).

Notes:
I used the C: drive for clarity - if you install to a different drive then modify as required.
If it bugs you, you can rename the Lubuntu menu entry to Xubuntu using bcdedit or easyBCD. 

Here are some screenshots for selected steps:



Step 3: Check Xubuntu MD5 sum




Step 5: Run wubi.exe with lubuntu in the same folder



Step 6: Select to reboot later




Step 7a: Delete the existing installation.iso




Step 7b: copy the Xubuntu ISO and rename to installation.iso




Step 8: Mount the xubuntu ISO and copy vmlinuz and initrd.lz







Step 9: Set it to install xubuntu-desktop




Step 11: Select Lubuntu




Step 12: Watch it install Xubuntu

Credit: I got this tip from here ironically to install lubuntu prior to it being supported by Wubi.

Update:
The original post had this line: "This technique will also likely work with other unsupported flavours e.g. ubuntu-studio". It does with one caveat. Ubuntu Studio doesn't include the package required by grub to generate the menu entries that can boot a loop mounted install (lupin-support). So it will install, but you have to manually boot it the first time from the grub prompt and then install lupin-support.

 Here's how to manually boot any Wubi install:

search -s -f -n /ubuntu/disks/root.disk
probe --set=diskuuid -u $root
loopback loop0 /ubuntu/disks/root.disk
set root=(loop0)
linux /vmlinuz root=UUID=$diskuuid loop=/ubuntu/disks/root.disk ro quiet splash
initrd /initrd.img
boot

Pass on upgrade to Quantal Quetzal 12.10

I've been following the development of Quantal Quetzal in passive mode. I need the development release to maintain the Wubi move and resize scripts, so I don't have much choice in the matter, but I haven't been as involved this time around.

The most striking difference between development on Quantal and that on Precise Pangolin 12.04 has been the quality drop-off. Precise was remarkably stable throughout the development cycle, whereas 12.10 has had some rough patches, making it barely usable at times. Most recently I've found the zombie application window problem - which is when I've closed some applications but they still appear to be active - almost like an overlay on the desktop. In fact, moving to separate workspaces shows these zombie windows and even the launcher has the active window indicator. Now normally this isn't too big a deal - in development we expect some weird stuff - but it's very close to release, and what's more, this is a recent 'development' (as it were). So that doesn't bode well.

So what's really new with Quantal? What new benefits are there?
I'm having a bit of a problem figuring this one out.

• During development they renamed "Shut down..." to "Switch off..." on the system menu (but not the Shut down dialog pop up). Then they renamed it back to "Shut down..." a few weeks ago. 
• They've added the "Restart..." option back to the System menu that was removed in 12.04.
• They've combined the User and System menu into one
• The i386 non-PAE kernel has been removed so the PAE kernel becomes default on 32-bit installs
• They've added Amazon online search results to the main Unity search lens that ironically seems to return adult-themed toys for innocent search strings dynamically as you type. Because as everyone knows, sometimes you just randomly decide to buy things online when you're searching for documents on your computer.
• They changed some icons on the mail envelope a lot and then removed them
• There's no more live CD since the ISO is too big to fit on a CD. So you'll need a DVD or USB.
• There's no more alternate CD because support and testing two images takes too much time and they figure that the text installer is not needed anymore - and for those that do they can use the netboot ISO.
• There's a new version of Grub that supports UEFI secure boot (I believe this is on 12.04 as well)
• For Wubi, you won't be able to install Xubuntu anymore, but they have finally fixed the links for Kubuntu so that will be available and working.

Okay that was a list of nothing. What are the benefits?

Well, I really like the new blue sky wallpaper. And there are obviously lots of other little changes that may be important to users, like updates to more recent versions of some applications.

Upgrade Recommendation
I'd say pass on the upgrade unless there's something specific that you need. But bear in mind that if you decide to upgrade to 13.04 later, you'll still need to upgrade to 12.10 along the way.
Remember that there will be some new bugs introduced with the mainly cosmetic changes, added to the unfixed bugs from 12.04.
If you do decide to upgrade please make sure you have at least 3 GB free space - see here for more upgrade tips.

Wubi default
For new Wubi users, you'll be installing 12.10 by default from here. Get the wubi.exe for 12.04 from here instead if you prefer.

Windows 8 - Fast-start and hybrid sleep

Windows 8 is around the corner... but already many people have been testing it and dual-booting with Ubuntu. One of the new features they've stumbled across is the new 'fast-start' and while it works okay with Wubi, it doesn't play well with a normal Ubuntu dual-boot. But hybrid sleep is a bit of a nasty piece for Wubi  (assuming the bug I'll describe here doesn't get fixed by Microsoft).

What is fast-start?
Microsoft figure that hibernation is awesome, making booting really fast. But for some reason, not all users are comfortable with it. I know, I've run into some users with hibernation-anxiety in the past: comments like "it will run down my battery", or "it fails to resume after a few times"... etc.
So Microsoft thought, what if we don't tell users that they're hibernating - then it will be quick to startup and they'll be none the wiser. Hey presto, welcome to 'fast-start' or what I like to call partial, hidden, hibernation. As described here:
"Now here’s the key difference for Windows 8: as in Windows 7, we close the user sessions, but instead of closing the kernel session, we hibernate it. Compared to a full hibernate, which includes a lot of memory pages in use by apps, session 0 hibernation data is much smaller, which takes substantially less time to write to disk. If you’re not familiar with hibernation, we’re effectively saving the system state and memory contents to a file on disk (hiberfil.sys) and then reading that back in on resume and restoring contents back to memory. Using this technique with boot gives us a significant advantage for boot times, since reading the hiberfile in and reinitializing drivers is much faster on most systems (30-70% faster on most systems we’ve tested)."

So what's the problem?
Anyone who dual boots knows that you can't mount your windows partitions read-write when they're hibernated. And now even when you don't think they're 'hibernated' they might be. So that's clearly a problem for a normal Ubuntu dual-boot. It's not a problem for Wubi because the Windows Boot Manager is smart enough to recognize that when you boot some 'other' OS (basically anything other than the default Windows 8 option) it removes the hibernated 'state' before proceeding. By the time Wubi gets to boot the partition is free to be mounted. That's different to a normal dual-boot where you have the Grub2 bootloader installed. Probably this will lead to bigger uptake of the easyBCD solution - where you can boot a normal Ubuntu dual-boot via the Windows Boot Manager.

When does the 'fast-start' occur?
Only when you Shutdown windows, not when you Restart the system. That's fine if you're rebooting into Ubuntu, but shutting down and booting up Ubuntu later won't work. Oh and trying to install Ubuntu when doing a cold boot on a USB thumb-drive will probably give you problems.

What about the hybrid-sleep?
This is a nasty little piece (for Ubuntu anyway). Basically, the idea is that it saves your session to disk and goes into an ultra-low power consumption mode. But it leaves some artifacts that make it appear as if you're hibernated. And the catch? It isn't cleaned up with Restart, only with Shutdown. So this is the opposite of the fast start, in that you have to shutdown after sleeping to clear the artifacts... and this does affect Wubi.

For Wubi what will you see?
If you have hybrid-sleep enabled and you try to boot, you may see a message saying that the partition cannot be mounted because it is hibernated. Then the fix is to boot back into Windows, and Shutdown. Or better, turn off hybrid-sleep. As far as I know, hybrid-sleep is not switched on by default, so avoid switching it on. In my own tests, it wasn't clear what was happening because the busybox prompt with the error message wasn't being displayed at all, just a purple screen. And booting in recovery mode mounts drives as read-only so the problem wouldn't be apparent either. I had to edit my grub boot options just to see the error. (This is probably specific to my graphics setup, but be prepared for this symptom). Note, in my opinion, this is a Windows bug - surely Microsoft don't intend to leave the computer in a 'mixed' hibernated state? But whether they intend to fix it before release is unclear.

For normal dual boot, what can you do?
You can boot Ubuntu using easyBCD as stated before... maybe this will be the golden era for easyBCD. Or you can simply turn off fast start and hybrid-sleep (this last link isn't specific to sleep but does show how to get to the advanced sleep settings)

12.04.1 wubi.exe released... Wrong version error

With the 12.04.1 release, Wubi.exe was also bumped to 12.04.1. For those that don't know, Wubi.exe is very particular about which version it will install: it first checks the ISO and rejects it if it doesn't match.

DEBUG Distro: wrong version: 12.04 != 12.04.1
So, why is this a problem? Simply that not all flavours of Ubuntu e.g. Lubuntu/Xubuntu/Mythbuntu get a 12.04.1 ISO released. And Wubi.exe is clever enough to know that - it still has the address for the 12.04 ISOs for these flavours and will happily download the entire thing... and then stupidly reject it.

So that all seems rather pointless and frustrating to the users. Especially since the same thing happened with 10.04.1 - someone might've figured out the pattern by now. But in their defence, it's taken me 10 minutes to write up this post, so you can see why it'd be so difficult to fix.

Actually a look at the code indicates that Wubi.exe for 12.04 will happily install a 12.04.1 ISO, just not the other way round. So if they had just left it at 12.04 and updated the link to the 12.04.1 ISOs then... no breakage.

Workaround
An easy workaround is to use the 12.04 Wubi.exe for your favourite flavour (anything other than Ubuntu... except Kubuntu which has been broken for Wubi installs since 12.04 was released). So you can install Xubuntu, Lubuntu, Mythbuntu, Edubuntu in this manner. Here is a link to it: http://people.canonical.com/~evand/wubi/precise/wubi-r266-signed.exe

Update
Probably to repay me for doing just 10 minutes of research, I've found out that Xubuntu, Mythbuntu, Edubuntu and Kubuntu all have a 12.04.1 release. So in fact, it's Wubi 12.04.1 that is at fault here for not updating the metalinks. It's only Lubuntu that's stuck on 12.04. Either way, none of these work without some manual workaround.

Workaround part 2
If you want Kubuntu, Mythbuntu, Edubuntu or Xubuntu, download the ISO first, save it in the same folder as the 12.04.1 Wubi.exe and run wubi from there (disconnect from the Internet prior to running).

Six Wubi rules

These are my Wubi rules to make your experience trouble free... hopefully:

1. Never force shutdown the computer while Ubuntu is running. Linux has a built-in safe-reboot option that you should familiarize yourself with upfront: Alt+SysRq R-E-I-S-U-B. If that fails and it's totally hung up (no hard drive activity light) then you have no choice, but to hard-reset. But first make sure you entered REISUB correctly.
2. Don't change the boot order from Windows to Ubuntu, or shorten the timeout. Windows is the host operating system and it should take priority or you might fall into a fairly common trap that leaves only the Wubi install bootable. When you want Ubuntu to be Number One, then you can install a normal dual boot or replace Windows.
3. Create a Windows Repair CD before you need it. It will help if you don't follow the advice in Rule 2. Also, you can repair NTFS (using chkdsk) from a Windows repair CD, but not from Ubuntu.
4. Have a good data recovery plan. If you don't have a Windows Install DVD, make sure you create Windows Restore DVDs. When you start to play with multiple operating systems and, later, partition, you want to have good backups. Also, if you don't follow Rule 1, or you have hardware incompatibilities, you could lose data on the Wubi install. So backups are important. 
5. Don't migrate data to your Wubi install. Wubi uses a virtual disk, a large file. Moving personal photos, videos, music from your Windows host to the Wubi install is like combining all those individual files into a huge, single file archive. So your risk of data loss just went up exponentially. It's totally unnecessary to move data that is easily accessible on /host or other NTFS partitions. And on top of that, data on the virtual disk is not (easily) accessible from Windows. Obviously there's some data that has to be on the virtual disk, but don't blindly copy everything.  Make use of the free Ubuntu One service to automatically synchronize backups of your important folders.
6. Be very careful going for help when you get stuck. Sometimes it's critical to mention you have Wubi, sometimes it's not. Knowing the difference is not always clear so it's safer just to state it up-front. Remember that most hardcore Ubuntu users and developers don't use Wubi, so consider all advice carefully. Anything to do with installing Grub, bootloaders, reinstalling Ubuntu from a CD, wiping partitions... are likely to be invalid and will damage Windows - and this is the most common advice given to Wubi users. Remember that Wubi does not have a hardcore base of experienced users so proceed with caution...

So that's about it. Some people choose to use Wubi long-term - or once they start using it they don't see the need to switch to a normal dual-boot. Personally, I'd recommend switching to the normal dual-boot, but if you follow the above advice you're at least  minimizing risk to yourself.

I have already given other advice on how to upgrade a wubi install here, and how to take a fully-bootable backup of your Wubi install here, so haven't included these here.

Boot-repair and Wubi

Boot-repair is a product that has appeared in the past year or so and has speedily been incorporated in community-editable support documentation (basically all Ubuntu documentation). There's no question that the author has put a lot of effort has gone into creating and maintaining Boot-repair and it has apparently been embraced as a very useful tool by the community at large.

But I wouldn't recommend it for Wubi installations and here's why...

Wubi boot problems are different
There are some key differences in the way that Wubi boots. It uses the Windows boot mangler, not the bootloader in the drive MBR to boot. So that's the first thing to check... do you actually have boot problems or is it something different?

If Windows boots okay then boot-repair is not for you
As mentioned, Wubi boots via the Windows boot manager (yes that was a deliberate typo before). So technically your computer boots okay. Boot-repair is more concerned with the boot mechanisms that occur prior to the Windows boot manager showing e.g. the bootloader (drive MBR), the boot flag, etc. So running it isn't going to help. In one case it has stopped Windows booting. To be fair to the author, the problem mentioned in that thread has apparently been fixed, but I'm not sure that boot-repair is mature enough to handle all the myriad of Windows configurations out there.

If Windows doesn't boot, then you should use Windows Repair instead
As stated before, if you do have issues with Windows, then your best bet is a Windows repair disk. Windows repair is an official Windows repair mechanism supported by Microsoft, who hopefully understand their product.

If Wubi isn't booting then probably you need to run chkdsk
This cannot be done using boot-repair, only through Windows or Windows Repair. The most popular post on this blog is all about the damaged root.disk. This is by far the most common problem with Wubi installs, and the first thing you should consider when you have issues.

What Boot-repair will do
Boot-repair detects Wubi installs and will fsck the root.disk (fsck will fix any ext4 file system damage on the virtual disk). It's not always clear to new Ubuntu users how to do this, since you need to create an Ubuntu CD/USB, boot from it, mount the partition containing the root.disk and then fsck it. There are many guides on how to do all this, but of course it's easier to have this all automated for you.

Summary
I have no doubt that boot-repair has helped many people - and there don't seem to be too many misgivings about it out there in the community. But at the same time, in my opinion, it's been incorporated too rapidly into the official documentation e.g. here without sufficient warning that the tool is not officially supported by Canonical, and in some cases, might be classified as experimental.

Xubuntu option to be removed from Wubi

It looks like Xubuntu will no longer be offered with Wubi, from release 12.10 onwards.

I was browsing the Wubi code the other day and noticed this revision: Drop Wubi for Xubuntu at the request of Pasi Lallinaho. Pasi Lallinaho is the project lead for Xubuntu: https://wiki.ubuntu.com/PasiLallinaho/

Xubuntu is typically used on lower spec hardware so it's probably not a big surprise to see this move. The minimum requirements for Xubuntu typically are lower than that of the Ubuntu installer (ubiquity) so in some cases the Wubi install would fail when a normal Xubuntu install would succeed. But I don't know the real reason behind this move.

Weird clicking noise in Chrome

For anyone who is experiencing sound issues in Chrome, there is a workaround. I use the browser a lot and it's been making my Ubuntu experience very irritating lately. Videos have been impossible to listen too and even using Gmail has been irritating with a background 'static heartbeat' that runs continually.

It doesn't affect Firefox, so that's an option, but if you depend on Chrome like me... here's the fix:

1. Go to chrome://plugins/
2. Expand the Details (click plus sign on right side)
3. Disable the Pepperflash plugin

It looks like the issue is documented as a chromium issue in a number of places e.g. here and here.

What's wrong with Wubi/Ubuntu

It speaks volumes that the most popular post on this blog is Missing the root.disk. It has nearly double the hits to the next most popular post (that also relates to Wubi boot problems).

What does this mean: to be missing the root.disk? 
Well it's the catastrophic failure of Wubi, the damage and possible destruction of the virtual disk, in other words, the entire Ubuntu operating system and data. There really can't be much worse of a failure.

What is the cause?
It could be the forced shutdown of the computer, for example, due to a system freeze. In some cases, users reported a crash. In other cases, they reported nothing more than running available updates. It's not conclusive what the main cause is.

Why do people force shutdown?
There are probably many reasons this happens... like any bug that causes a system freeze. E.g. on my 12.04 Ubuntu install when I come back from suspend the screen sometimes remains black (mouse still visible). This isn't a freeze but there is no obvious way to shutdown or restart and no apparent fix/workaround. It would be totally understandable that some people might force shutdown if that happened to them. Especially coming from a Windows background where there is no alternative to REISUB. In fact, on my test Windows 8 install it freezes frequently and - as far as I know - that's my only option to reset.

So usability bugs like that could also be behind the corruption.
PS For this particular bug, I generally Ctrl+Alt+F1 and restart the lightdm desktop service (but it still kills all open apps). 

Why does a forced shutdown corrupt the ext4 and/or ntfs file system?
This is perhaps the more relevant question. Maybe the journalling built into ext4 leads to corruption (speed over stability?). But this is pure speculation - and I thought Wubi installs were supposed to automatically sync all changes, precisely to avoid this problem.
And why would  this affect the root.disk, a fixed-size file on NTFS...why does Wubi even update anything that could lead to this fixed file becoming corrupt? This seems like a major flaw.

How unstable is Wubi?
It's not possible to answer this without understanding how many people use Wubi and how many of those experience corruption of the root.disk. The fact is that I have never lost a root.disk to corruption in multiple years of testing Wubi, and over a year of continual use of Wubi (running the development releases)... so while I can't definitively say what is going on, I don't believe it's that unstable.
Regardless, the fact is, it shouldn't happen to anyone, and clearly it happens to many.

Why do people use Wubi?
I get that Wubi is a great way to try out Ubuntu without partitioning. It runs extremely close to a normal dual boot, that it showcases Ubuntu for those that are understandably nervous about partitioning. That makes sense. But why do they people keep on using it? Probably because it works too well. There isn't a whole lot of understanding about why it's not a great idea to do all your university coursework on a Wubi install and not bother to back it up. There also isn't any notification or warning when you install Wubi from here that there could be problems ahead or even an explanation of how Wubi is different unless you follow the links. In short, there's no reason for a user to switch to a partitioned install (usually until a major failure and the resulting investigation).

What do I think about Wubi?
I think it's pretty amazing to try out Ubuntu, but that it's poorly supported: I don't believe there is a credible maintenance and testing infrastructure for Wubi. If there were then you would see some effort to resolve these sorts of issues. And from experience I can assure you that getting even well-understood, major Wubi issues resolved (even when the fix is known), can be like pushing a rope.
Having said that, 12.04 is probably the most stable Wubi release ever - there's a huge drop in support requests. So it's working better than ever before and it seems to be popular and part of Canonical's strategy to spread Ubuntu.

Wubi maintenance
I touched on the fact that I don't believe there is a credible maintenance plan in place for Wubi. My impression is that, in general, Canonical's resources are stretched too thin. There are many important, unresolved issues with Ubuntu at any point in time, and Wubi's issues are obviously not high on that list. I've been using 12.04 since it's release and I've found a number of usability bugs that make it a frustrating experience. On top of that, the seemingly small Ubuntu developer team are always fully occupied, working hard to produce these relentless 6 month releases, which I believe is far too frequent. All that time spent on a development release for zero production users is time taken away from millions of real production users. This doesn't make any sense to me whatsoever. It should be the other way around. Because of this endless cycle of less than perfect releases and not fixing existing problems they are slowly going to whittle away at the support base and scare off newcomers. So... in short I believe the Wubi maintenance issues are minor compared to the general maintenance issues.

Edubuntu - it burns!!!

Lately I've decided to use Edubuntu... But there have been some pain points, none more-so than the boot splash screen. You know, that white Edubuntu spash screen that modern laptops on full brightness just about shatter your retina as it boots? If all you know is the soothing Ubuntu purple screen (haha) then consider yourself fortunate.

So what can you do... surely you can just change it? Yeah, go to software center and search on boot and/or splash and/or eye's burning and ... nothing. But surely you know the boot process thing is called "Plymouth"? Oh yeah, okay try that... nothing!

No, you have to search on plymouth-theme. That will trick Software Center's advanced heuristic irritation algorithm to show you what you want!? (Why on earth would a search on plymouth not produce results that plymouth-theme produces?)

So, there it finally is - the Solar Theme I love. It's darker blues will soothe my eyes and not excite the senses (like that rude purple). Install it... bing, bang, boom, done!!! Ah, no, that's not the way it's done. It still comes up all whitey-brighty.

Well, duh, I didn't tell it to use Solar as default. How would it know!!! (Stupid me). What you obviously have to do is go to a terminal and run:
sudo update-alternatives --config default.plymouth
And select the number that matches the Solar Theme. Enjoy.

Please someone post a comment and tell me what I missed - there must be an easier way!!!

Wubi usage/opinion survey

Things have been a little quiet on the Wubi support front, since the 12.04 release (which resolved a lot of the usability bugs in Wubi.) So while twiddling my thumbs, I decided to find out how Wubi is perceived in the community.

Clearly there are many vocal 'anti-Wubi' voices, but how - I wondered - does the general community receive this product? I created a survey via surveymonkey.com and advertised it in The Community Cafe section on ubuntuforums.org. The idea was to target more seasoned Ubuntu community members.

Q. What sorts of users responded to the survey

77% of the respondents stated that they used Ubuntu more than Windows.
65% had experience with Wubi, either running it currently (9%) or having run it in the past (56%) 

Q. How many users responded

43 users completed the survey

Q. What was the opinion of Wubi

The following chart shows the opinion the respondents had of Wubi. e.g. 30% neither liked nor disliked Wubi.

The following chart shows the average opinion rating, broken down by category of user (on the chart a value of 1 = "Hate it", 2 = "Dislike it", 3 = "Neither Like nor Dislike it", 4 = "Like it"  and 5 = "Love it".)

The first column is the average for all respondents (3.28), and the rest are broken down by whether the respondent has ever used Wubi (or is currently using it). It shows that the opinion of Wubi is higher amongst those who have used Wubi (perhaps not surprisingly).

Q. Who would recommend Wubi

The following graph shows who would recommend Wubi to others to try out Ubuntu. The graph is broken down by category of user (first column is all respondents.) Again, not surprisingly, those who had used Wubi were more likely to recommend it.  Users who had no experience with Wubi were extremely reluctant to recommend it.

Conclusion
I was a little surprised to see the results. I expected to see more negativity to Wubi amongst non-Wubi users. But it should be noted that even though the average opinion rating wasn't bad in this category (2.47) only 7% would recommend Wubi to a new user to 'Try out Ubuntu'.

Contrast that with the average opinion rating of those that have used Wubi (3.54) or those that currently use Wubi (4.75) and you see a recommendation of 67% and 100% respectively. So these users clearly feel there is some value for introducing Ubuntu to newcomers.

Appendix
Here is a list of the questions on the survey. Questions with an asterix were mandatory.

1. *Do you run Ubuntu installed with Wubi? (Yes/No)
2.  If you answer No to Q1, have you ever installed Ubuntu using Wubi (Yes/No)
3.  If you used or are using Wubi, how long have you used it? (<1 day /<1week /<1month /<3months /<1year />1year)
4. Have you upgraded releases using Wubi? (Yes/Yes but it failed/No)
5. *Do you use Ubuntu more or less than Windows? (Less/Same/More)
6. *Do you ever force shutdown (power off) your computer if it hangs? (Never/ Sometimes/Frequently)
7.  If you are currently using Wubi, are you planning to move to a normal dual boot in the future, or stay with Wubi? (Reinstall/Migrate/Stay with Wubi/Not sure)
8. *Would you recommend Wubi to others to try out Ubuntu? (Yes/No)
9. *What's your overall opinion of Wubi (1-Hate it/2-Dislike it/3-Neither like nor dislike it/4-Like it/5-Love it)

Wubi Kubuntu not working in 12.04

You cannot install 12.04 Kubuntu when running wubi.exe standalone at this time. The addresses of the ISOs are incorrect so it will fail.

Cause
I'm not entirely sure but perhaps this has something to do with Canonical no longer supporting Kubuntu. Whatever the reason, the ISOs are now hosted on http://cdimages.ubuntu.com/kubuntu/releases/12.04/release/ instead of http://releases.ubuntu.com/releases/kubuntu/ (as it was in prior releases). Unfortunately this wasn't picked up in testing as Wubi uses a different download site while in development. It's only after release that this switches over.

Fix?
I've submitted a bug patch that may or may not be accepted as an SRU (stable release update) - if you read a previous post you'll know that these are now possible for wubi.exe whereas they weren't previously. But in the meantime you'll have to use a workaround to try Kubuntu

Workaround
Download the Kubuntu Desktop CD ISO manually from here and save it in the same folder as wubi.exe before running.

How to run the development release with Wubi

Prepare for breakage

This goes without saying, but I like to say it anyway. If you choose to follow these instructions, and you lose your installation/data or worse - you're on your own. That said, I've been running the development release on Wubi since 11.10 and with a few precautions you should be okay. 

Note: Since the 32-bit non-pae kernel will not be supported in 12.10, I advise not following these instructions if you are using the 32-bit non-pae kernel.

Backup and restore

Even though I am aware that things could go awry, it's still irritating to lose the install. So I keep a fully synched backup of the root.disk. After running updates (which you'll probably get used to doing every time you boot), once you've rebooted and confirmed things are stable, you can resynch your backup. 

Here's how to do it:

1. Make a copy of your root.disk using the Wubi resize script 
2. Keep it synchronized by rerunning the script, but supplying the --resume option (which will copy only files that have been modified/added and delete ones that have been removed).
3. Make the new.disk bootable (so you can confirm it works without booting to Windows to rename the disks). You do this by adding the following lines to /etc/grub.d/40_custom (changing the bits in red to match your own settings):

menuentry 'Ubuntu - backup new.disk' --class ubuntu --class gnu-linux --class gnu --class os {

        set gfxpayload=$linux_gfx_mode

        insmod part_msdos

        insmod ntfs

        set root='(hd0,msdos3)'

        search --no-floppy --fs-uuid --set=root 18B4B7BBB4B799A8

        loopback loop1 /ubuntu/disks/new.disk

        set root=(loop1)

        linux   /vmlinuz root=UUID=18B4B7BBB4B799A8 loop=/ubuntu/disks/new.disk ro   quiet splash vt.handoff=7

        initrd  /initrd.img

}

Then you'll see "Ubuntu - backup new.disk" at the bottom of the grub menu when you boot. If you don't see the grub menu, hold down the Shift key after selecting Ubuntu.

Upgrading to Quantal

Since there is no Wubi.exe version for Quantal available at this early stage of development, the only way to get it is to install 12.04 Precise Pangolin, and then modify your sources.list. (Note, once the Alpha1 is released you may be able to install normally and in this case you should not use this method).

sudo sed -i 's/precise/quantal/g' /etc/apt/sources.list

sudo apt-get update && sudo apt-get dist-upgrade 

Partial upgrades

Always review the results before running dist-upgrades. In particular, look at what is being removed. It's fairly common for the packages to be out of synch at times during the development release, and if you're not careful you might uninstall critical bits. My rule of thumb is, if anything is being deleted look for a newer version of it being installed. If there is no corresponding entry, then wait a few days. Sometimes you'll find the packages are no longer listed as being removed. In other cases, they're still there and it's probably safe to proceed. If you notice a lot of packages being deleted, run away.

Where to go for help

Please review the Sticky threads in the Ubuntu+1 forum on ubuntuforums.org. If you have any questions or problems, look there to see if someone else has a solution or post your own questions. 

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.

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).

Wubi disabled on live CD?

I wasn't going to blog about this... but since it made OMG! Ubuntu as a sensational article, I'd be remiss not to mention it.

Yes, it was floated on the ubuntu-devel mailing list to disable the ability to install using Wubi on the Ubuntu desktop CD. This didn't receive much discussion and so it's unclear what decision was made (if any), but I guess we'll find out soon enough with just a handful of weeks to go before 12.04 Precise Pangolin is released.

Background
Wubi.exe is released as part of the desktop CD ISO. This is fixed at release. So whenever you download the ISO you are getting the exact same one that others got on the release date... e.g. 11.04 - it's been out for a year, lots of updates, but the ISO is the same. Once you install Ubuntu 11.04, you'll be downloading 300+MB of patches. But since Wubi.exe is on the ISO it's also fixed for the duration of each cycle.

Why is this a problem? Wubi.exe typically gets limited testing during the development cycle. It doesn't get much development either - as the basic function doesn't usually change that much (11.10 was an exception to this). Most of this development tends to be after everything else is frozen, so the testing that was done early in development isn't always relevant. I could come up with other reasons, but you get the point. You're saddled with whatever bugs there are (some pretty irritating ones) - and even though many people download wubi.exe standalone, it's still fixed in stone.

Conclusion
So, in theory this is a great idea. We wouldn't have to live with irritating bugs, and instead of all the volunteers who support Wubi on Ubuntuforums.org having to repeat the same response 500 times, they could spend less effort making sure that the bugs are reported clearly so that a speedy fix can result.

However
It's still kind've nice to hand over a CD to someone and let them try out Ubuntu using Wubi, without having to download anything. I don't know how often this happens, but I guess there will be some who miss it. The question is, do you have to completely disable the CD install method to allow a stable release update to the standalone wubi.exe? Why not support both options?

Wubi call for testing

We're about 7 weeks away from the next LTS release, 12.04 Precise Pangolin, and this is a critical phase to get all the Wubi bugs ironed out. The reason is simple: after the release Wubi.exe is not modified so we'll have to live with any bugs for at least 6 months.

Wubi development testing is typically under-represented by the Ubuntu community because it's mostly used by newcomers to Ubuntu (and many hardcore users don't have Windows). Wubi is the first impression of Ubuntu for many, and so it's important that this is a good experience. Since 11.04 was released, Wubi has been very stable, but there's always room for improvement and to get rid of any irritating bugs.

With that in mind there has been a call to testing on ubuntuforums.org. If you have the ability then please help out, and provide feedback in that thread and/or file bugs on https://bugs.launchpad.net/wubi/+filebug.

There are a number of ways to run Wubi tests:
1. Download wubi.exe and run it standalone (during dev you can get it from here)
2. Download the Desktop CD ISO, burn it to CD if it fits (or DVD), and run it from there.

Note: each time you install Wubi it uninstalls any existing Wubi install (so if you use Wubi normally you can't easily test it unless you are comfortable backing up your current install).

There are a few tricks you can use. E.g. running wubi.exe standalone will download the preinstalled images i386.tar.xz or amd64.tar.xz from here. That's a 500MB download each time you run it, so instead you can download it once, save it, and then point it at your local copy with a command line option. This saves a lot of time if you are repeatedly testing. e.g. for a 32 bit pc:
wubi.exe --dimagepath=C:\xxx\i386.tar.xz

You can also test the ISO install without burning a CD or DVD each time, by saving it in the same directory as wubi.exe (which you can get off the ISO or use the standalone download).

If you run wubi.exe standalone, but install something other than 'plain' Ubuntu it will always download the ISO instead of the disk image. You can also override this download by copying the ISO into the same directory as Wubi.exe, but note that since the ISO changes frequently in development, chances are it will try to download a new one anyway. To get around this (if you know the MD5SUM of your ISO is good,) you can disconnect from the Internet for the first part of the install.

Remember you can use Wubi to install:

• Ubuntu
• Kubuntu
• Xubuntu
• Mythbuntu
• Lubuntu
• Edubuntu

All of these need to be tested. For Edubuntu, you download the DVD ISO (there is no CD ISO), but for the others you need the Desktop CD ISO.

Pay attention to the latest wubi.exe revision .e.g as of the time of writing, the latest is wubi-r256.exe. This version won't install Edubuntu, but forthcoming ones will. And whenever a new revision is published it's important to retest to make sure the bug fixes work and make sure there are no regressions.

Good luck.

Wubi must overcome some hurdles for Edubuntu

From 12.04 you will be able to install Edubuntu with Wubi. There are a few hurdles to overcome. The first is that Edubuntu requires a DVD image to install, and Wubi has built-in checks to prevent this - the ISO must be < 900,000,000 bytes (or 858MB) .

These same checks are what prevents users from installing a normal desktop CD image from a USB stick. These days USB sticks are generally large - in fact the Ubuntu download site states that a minimum of 2GB free space is required when creating a bootable USB.
But the way Wubi works is to copy the entire USB partition as the 'ISO' during the installation, and following that it performs the 900,000,000 byte check, and fails.
There is another danger because the USB partition is copied without any space checks. So imagine if you have 10GB space left on your hard drive, Wubi proceeds to install, but then tries to copy a 16GB USB stick partition onto that same hard drive. (That can only end badly). And even if you have enough space - it's going to fail the size check anyway.

Why is this an issue? More and more users are using USB sticks as they are cheaper, readily available and much less hassle than CDs (bad burn anyone?). But even more importantly, there have been reports that the Ubuntu desktop CD ISO will be increased 750MB size from release 12.04 on. This rules out the use of standards CDs. You can still burn a CD ISO onto a DVD - that works because the ISO does not expand to the DVD size in the same way as with a USB partition.

Relevant bugs:
Edubuntu https://bugs.launchpad.net/bugs/913354
USB https://bugs.launchpad.net/bugs/461566

Wubi will support Lubuntu in release 12.04

Lubuntu
Coming with 12.04 precise pangolin, Wubi will support Lubuntu. Preliminary tests using the daily live CD and this wubi.exe are successful. Note you have to logon blind for now while bug 918401 is sorted out.

I found that Lubuntu ran very well on my junky old test laptop - while it was very sluggish with 11.10 Ubuntu. So Lubuntu might be a better option for older machines.

If you're going to be testing Wubi remember to use zsync to keep your test ISOs up to date. It's a great tool.

Other wishlist
It'd be nice if Wubi could install from a USB stick with 12.04 - since the desktop CD ISO is supposed to be around 750MB it won't fit on a CD so I expect many people will try with USB. Waiting on longstanding bug 461566.

Also, it'd be nice if some of the obscure error messages that have appeared since 11.10 could be replaced by human-understandable text. For example "WindowsBackend object has no attribute 'iso-path'". I suppose it's no better than 'Permission denied' being used indiscriminately, but I suppose we were used to that.

For the 'preinstalled image' install method, I'd like to see an easier way to override the kernel boot options for users with ATI or NVIDIA cards requiring 'nomodeset'.

From a personal point of view I'd like to have an installable Wubi migration gui app ready - but it's not looking like it will happen in time.