Natty is natty

In my previous post I mentioned that Natty is now working with Wubi (on the current daily-live image), and also that the new Unity desktop is now working on my old Dell with an ATI X1300 Radeon (whereas with 10.10 netbook edition and early Natty Alphas, Unity did not work at all).

Since then I've reinstalled a number of times and I'm coming to like Natty and Unity. It feels - well - "natty". Not that that's a word I'd use frequently and I consider it only marginally better than the upcoming Oneiric Ocelot (that must be some good weed over at Canonical).

The only Wubi issues I've found are a couple of boot problems with the latest version of Grub. The first was fixed very quickly, and the second only seems to affect my installs when they're not on the main Windows partition. I've worked around this by manually booting and then editing grub.cfg by hand.  I believe that it's basically the same grub rebooting issue from 10.04 and upgrades to 10.10, but this time there is no workaround - other than changing the  00_header script in /etc/grub.d/ but hopefully this will be resolved before release.

The more people that test and report bugs, the better. So if you decide to try Natty on Wubi, please report any bugs you find in launchpad.net and make it better for newcomers to Ubuntu.

Wubi finally working in Natty Narwhal

I've just tested the latest Wubi.exe available here. It took a while to download the latest daily-live Desktop CD image (in the end I did that myself from here). But after that installing Wubi was painless. Apart from a benign grub2 message, the Ubiquity installer was impressive - looking ready for release - and seemed faster than prior releases, as did booting up for the first time.

Surprisingly Unity even worked on my computer - I'm not totally sold on it and there were some rendering issues, but at least now I have the opportunity to review it, instead of staring at a blank screen.

So - in summary - the installation of Wubi Natty Narwhal worked flawlessly. As always, alpha testing has risks, so take necessary precautions.

Wubi pulled from Natty Alpha3

For those hoping to test Natty Narwhal 11.04 using Wubi, it will not be fixed in time for Alpha3 (the bug report is available here). The new target for a fix is Beta1.

If you read my previous posts, you will know that you could install Alpha1 with Wubi (with some workarounds), but with Alpha2 a new ubiquity bug prevented this from working. I haven't tested this lately, so I don't know whether ubiquity has been fixed. But it's safe to assume that the only option now for Wubi Natty testing is to install Maverick 10.10 and then upgrade.

It shouldn't really be a surprise. Wubi is intended for the newcomer to Ubuntu so having a working Wubi option early in development is not a top priority. Although I am puzzled what the major difficulty is. Also, the fact that there are so many major changes to grub and ubiquity between Maverick and Natty should be sobering for those that like to upgrade to each new release (these don't seem to be very stable products). When you also factor in the major changes to the front-end (Unity) and it seems to me that the Ubuntu developers are being stretched pretty thin. At the same time there've been some pretty major bugs in Lucid that have gone unpatched for over a year.

Wubi itself is due for an upgrade. With a 2007 version of grub4dos that hangs up on ext4 partitions, and some pretty bad usability bugs (e.g. the python code that chokes on multimedia card readers) and confusing (meaningless) error messages... someone needs to step up.

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.