I’ve recently persuaded myself not to purchase a new laptop, trying to get another year out of my HP Compaq nx7300 (running 32-bit Windows XP), which I purchased about four years ago. My home computing needs are fairly meagre, but I recently spent £23 upgrading my RAM to 4GB to see if I could get a strained instance of my SharePoint 2010 development environment running at home as needed. To this end, I decided I would clear enough System drive space to make room for Ubuntu (x64) and run my VMs from Virtual Box in the other partition, in order to get the most memory possible to my VMs. Like I said, strained…

So I loaded up the Ubuntu installation CD and launched GParted, cleared ~10GB for the OS and another 5GB for the SWAP partition, then installed. All went well, I installed VirtualBox, rebooted in to XP to make sure everything was cool over there. Went back in to Ubuntu to get a bit more familiar with the new version then shut down for the night. The next evening when I started up I was confronted with an ominous message:

No module name found
Aborted. Press any key to exit.

Non-System disk or disk error.

Not good. I checked I was booting to the right drive, then ran the Ubuntu installation disk again, which includes a no-installation trial option that runs entirely from CD/memory. I loaded up GParted again, checked all of the partitions, didn’t notice anything strange and then started searching for an answer. Luckily I dug a bit deeper than the first few results which recommended a full re-install of both boots. While that might have fixed the problem, it wouldn’t have been very desirable.

Eventually I found this Ubuntu forum thread, Grub “no module name found” after reboot, which points to this (in my opinion) definitive SourceForge article on Boot Problems:Windows Writes To MBR. While I would argue the problem actually has very little to do with Windows, it identifies the cause and four possible solutions. To summarise, the Windows partition contains software that writes to the Master Boot Record, which in turn corrupts GRUB, the Ubuntu bootloader. I say this has little to do with Windows because in all of the cases listed in this article and on the Ubuntu fora, the problem is caused by something that gets beneath Windows, like OEM “protection” tools, for lack of a better description. Here’s the list from SourceForge:

• HP: Credential Manager, Recovery Manager, ProtectTools, PC Angel, Backup and Recovery
• Dell: Recovery Tools, DataSafe Local Backup,
• Samsung: Recovery Solution III
• McAfee Security Center ???

This is all stuff that ships with your machine. I’ve always been distrustful of this software but I never got around to removing the HP tools on this laptop. Eventually I got worried that removing the credential management software might lock me out of the machine. Fairly irrational, I grant you, but as I say, I deeply distrust most things in Windows that appear to be getting beneath it and so I wind up avoiding them, even if they’re just sitting there doing nothing.

Back to the problem at hand, I eventually managed to restore the bootloader by following the first recommended solution from the SourceForge article – I uninstalled all of the HP software (except for Wireless/Bluetooth). However, there was one fiddle that’s worth noting. The HP Backup and Recovery Manager software did not have an entry in Add/Remove Programs and there was no uninstall option in the program or the Start menu. A quick search returned this recommendation, which launched the installer and started removing the tool.

RunDll32 C:\PROGRA~1\COMMON~1\INSTAL~1\PROFES~1\RunTime\10\01\Intel32\Ctor.dll,LaunchSetup "C:\Program Files\InstallShield Installation Information\{3F9F7336-6DF8-476F-ABF6-C70A17FAF619}\setup.exe" -l0x9 -uninst –removeonly

After rebooting into the Ubuntu installation media again I ran the recommended GRUB fix-up.

sudo mount /dev/sda6 /mnt
sudo grub-install --recheck --root-directory=/mnt /dev/sda

As recommended in the posts above, make sure “sda6″ and “sda” refer to the correct targets. Basically, make sure to familiarise yourself with those posts thoroughly before doing anything, and of source I present this without warranty.

After shutting down and starting up again I was presented with the GRUB bootloader as expected. After shutting down one more time, everything continued to work. That’s the key. Until the corrupting software is removed you can repair the GRUB bootloader with the install CD and it will remain fixed until shut down. On the first boot after shut down the MBR changes from the offending software in the Windows partition will be referenced and GRUB will fail to load. This is why the GRUB fix needs to be made after removing the offending software.

Rather irritatingly, I’d just started to doubt my suspicion of OEM software like this when I got to play with the Lenovo W520 tools briefly. They seemed quite useful. Indeed, my colleague Wes Hackett was just saying how much he liked the biometrics on it, so it’s a shame to have my suspicions slapped back in to place through this episode.

Item Level Recovery from host level backup: DPM 2010 Beta supports item level recovery (ILR) which allows you to do granular recovery of files and folders, volumes and virtual hard disks (VHD) from a host level backup of Hyper-V VMs to a network share or a volume on a DPM protected server.

Alternate Host Recovery: DPM 2010 Beta supports alternate location recovery (ALR) which allows you to recover a Hyper-V VM to an alternate stand-alone or clustered Hyper-V host.

And this general improvement:

You will see far fewer “Replica Inconsistent” errors and many of them will automatically get fixed by Auto-Rerun, Auto-CC (Consistency Check).