You’re probably thinking “why the hell would anyone want to do that?!”… well, the fact of the matter is you sometimes come across a client who is just too mind-set and refuses to use anything but Windows, so yes – sometimes you need to restore the Windows MBR, but how do you do that when you don’t have a Windows CD handy?

Well, here’s how to do it using nothing but an Ubuntu 9.10 Karmic LiveCD.

It’s a little known fact that the Windows bootloader is nothing special. In fact it contains nothing proprietary to Windows at all. All the Windows bootloader does is simply look for the partition marked as “bootable” or “active” and transfer control of the boot process to it.

And would you know it? The Ubuntu LiveCD has a binary image of a generic open source bootloader that does just that!

1. Boot your soon-to-be-Windows-only machine using the Ubuntu 9.10 Karmic LiveCD. Doesn’t matter if it’s the 32-bit or 64-bit version.
   .
2. Once booted on the LiveCD, open a terminal by going to the Applications menu and then choose Accessories and then Terminal.
   .
3. Find out what the designation of the Windows drive is (generally it will be the first drive, eg: /dev/sda or /dev/hda). If you are not sure, issue the command:

   $ sudo fdisk -l
   

   …and review the output, looking for your NTFS Windows partition. Make note of the drive that partition resides on (not the partition itself), eg: “/dev/sda”, not “/dev/sda1″.

4. Now type in the following (remembering to substitute the correct drive device name for your setup in place of “/dev/sda”):

   $ sudo dd if=/usr/lib/syslinux/mbr.bin of=/dev/sda

   …which will write the image of a standard MBR contained in the /usr/lib/syslinux directory of the LiveCD environment to the first hard-drive, overwriting GRUB. WARNING: Do NOT use a partition designation, eg: “sda1″ or “sda2″, etc. This will overwrite the start of that partition which will effectively destroy data. The MBR exists at the start of the drive only, so only specify “sda” with no number on the end.

5. Shutdown and reboot. Windows should now start “natively” without GRUB appearing at all.
   .
6. Normally I’d say “pat yourself on the back” here, but it’s Windows…

If your host is not configured with a Hosts file entry on your local PC or a DNS entry to associate a name with an IP address, Ubuntu can only use the IP address of that PC to communicate with it which means you have to remember what that IP address is with your feeble grey-matter in your head. Likewise, Ubuntu will not respond to a Windows PC pinging its NetBIOS name because Ubuntu does not use NetBIOS at all by default and so it will ignore such requests.

So how do we get Ubuntu to resolve NetBIOS names like Windows? And how can we allow Windows to ping Ubuntu like another Windows PC? Read on…

Let’s illustrate the problem first. You’ll need a Windows PC on your network to test this. For this article, the Ubuntu PC will be called “gordon” and the Windows PC will be called “alyx”.

On either PC, if you open a terminal or Command Line window and ping the opposing machine, eg:

$ ping alyx

or

C:\> ping gordon

You get an error stating that the host cannot be found. Now in the case of Windows, if you were to ping another Windows PC instead of an Ubuntu PC, you can ping its name with no problem.

Let’s sort this out, shall we?

Allowing Ubuntu to ping Windows NetBIOS names

Ubuntu is setup for Linux use, not Windows use, so we need to install a package that will allow Ubuntu to more readily mix in with Windows networks and use NetBIOS. This package is called “winbind”.

1. Open a terminal and type in the following at the terminal prompt:

   $ sudo apt-get install winbind

2. Once installed, we need to tell Ubuntu to use WINS (as provided by winbind) to resolve host names. Type in:

   $ sudo gedit /etc/nsswitch.conf

   …which will open the file into the Gnome Editor.
   .

3. Scroll down to the line that starts with “hosts:”. In Ubuntu Jaunty, it looks similar to this:

   hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

4. Add the word “wins” on the end of this line such that is now looks like:

   hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4 wins

5. Save and exit the editor.
   .
6. Now let’s ping the name of our Windows box again.

   $ ping alyx

   …and it now resolves!
   .

7. Pat yourself on the back.

Allowing Windows to ping Ubuntu NetBIOS names

This is just one half of the equation. We now need to allow Windows to be able to ping Ubuntu PC’s using its NetBIOS name. This requires Ubuntu to recognise and respond to that request. We need to setup a server daemon to do this. In Ubuntu, this particular server daemon is called Samba.

1. Installing Samba is simplicity itself. Open a terminal and type in:

   $ sudo apt-get install samba

2. Once that has finished, your Ubuntu PC will automagically respond to all NetBIOS queries for its hostname straight away, and that’s not just from Windows machines, but other Ubuntu machines (configured with the “winbind” package) as well.
   .
3. Pat yourself on the back again.

• Backup to an image file
• Clone to another hard-drive (eg: building multiple identical workstations) either directly or via an image file
• Data recovery (it’s safer and easier to examine an image file than risk further damage to the hard-drive itself)

Linux has a neat little command that can do this for us called simply “dd”. It is completely filesystem independent, so you can backup any hard-drive regardless of whether it was Linux formatted, Mac formatted or Windows formatted. It copies the drive bit by bit, sector by sector, not file by file.

WARNING: The following article describes commands that can destroy the information on your hard-drive with next-to-no-chance of being able to rescue what’s left. Make sure that you have full backups of your data prior to using these commands. You use these commands at your own risk!

First up, your drive/partition being backed up or written to should be unmounted before you begin. If you were trying to backup the partition containing your system’s root filesystem, you should boot up your system on a LiveCD so you can access your root partition unmounted.

You then need to determine which drive or partition you want to backup. Easiest way to do this is to fire up a terminal session and type in:

$ sudo fdisk -l

…which will list all your drives, their partitions and sizes. Note down the device name of the drive or partition you wish to backup, eg: /dev/sda for the whole of your first drive or /dev/sda1 for just the first partition of that drive, and you’re ready to begin backup.

At its simplest, backing up a drive takes two basic parameters – input device and output device or file as follows:

$ sudo dd if=/dev/sda1 of=/dev/sdb1

…will copy the content of the first partition on drive sda to the first partition of drive sdb (destroying whatever was in /dev/sdb1 previously).

$ sudo dd if=/dev/sda1 of=~/mybackup.img

…will copy the content of the first partition on drive sda to a file called mybackup.img in your Home directory.

If you wish to backup an entire drive rather than just a partition, drop the number on the drive name, ie: /dev/sda1 becomes /dev/sda instead.

To restore the image to a drive, simply reverse the parameters:

$ sudo dd if=~/mybackup.img of=/dev/sda1

How simple is that? The only issue with this method of backup, though, is that if you were to backup a 10GB partition containing only 5GB of actual data, the resulting image file will still be 10GB as dd does not simply copy active data from the drive, it copies everything.

So with that in mind, let’s compress the image, so any empty space on the drive doesn’t take up unnecessary space in the image file. We can do this by piping the data from dd into gzip before writing it to a file:

$ sudo dd if=/dev/sda1 | gzip -9 > ~/mybackup.img.gz

…and to restore, we simply pipe the decompressed data into dd again for writing to the drive:

$ gunzip -c ~/mybackup.img.gz | sudo dd of=/dev/sda1

But wait! There’s more!

This just scratches the surface of what you can do with dd. For example, you can also use dd to destroy a drive’s content before you dispose of, or sell the drive by using the following:

$ sudo dd if=/dev/random of=/dev/sda1

…which will write random data to the partition sda1 using the virtual random device, completely obliterating it.

Or, if you want a more uniform destruction, try:

$ sudo dd if=/dev/zero of=/dev/sda1

…which will – no surprises here – write zeros across the entire partition.

Or perhaps you have a drive that isn’t playing nice, for example Microsoft Windows can get stroppy when working with, or removing partitions created by a foreign OS. The easiest way to fix this is to simply destroy the Master Boor Record (MBR). You can achieve this by specifying a blocksize parameter. The MBR is inside the first 512 bytes of the drive, so all we have to do is blank those 512 bytes out using:

$ sudo dd if=/dev/zero of=/dev/sda bs=512 count=1

The bs parameter specifies the block size in bytes (in this case 512) and the count parameter specifies how many blocks of 512 bytes we’re doing (only one in this case, the first 512 bytes of the drive where the MBR resides).

Any PC will now view this hard-drive as a brand new, never partitioned drive.

Rescuing a dying hard-drive

The dd command is particularly useful for recovering data on a drive that’s about to become a paperweight. As long as it can power up and identify itself to the system, you can attempt data recovery by taking an image of the drive and then try to recover the files from that image.

Since dying hard-drives are typically sown with errors, we need to tell dd to ignore them and keep pulling as much data off as possible. Taking our first imaging example, we add a couple of parameters to the command as follows:

$ sudo dd if=/dev/sda of=~/mybackup.img conv=noerror,sync

This will make a full backup of all partitions on drive /dev/sda to a file called mybackup.img in your Home directory, and the conv parameter tells dd to ignore any errors found during the read by skipping over them. The sync parameter tells dd to replace the errors with null values – blanks – so that the resulting image file is the same data length as the drive.

Once the backup is complete, you can then mount the image to view its content. As long as the MBR (the first 512 bytes of the hard-drive) were not damaged, you will be able to now recover most, if not all your files, without worrying about further failure to the drive or odd behaviour due to the physical errors on the drive itself.

To mount the image file, you do the following. First we need a mountpoint – a place to reference the mounted image volume:

$ mkdir /dev/shm/myrecoveryimage

This creates a directory called “myrecoverytimage” in your system’s RAM drive. Before you point out that you have less physical RAM than the capacity of your hard-drive, don’t worry – this is just a mount-point. The image will still be physically read from wherever you put it on another drive.

Now we mount the image. Let’s say we backed up a standard Linux ext3-formatted drive:

$ sudo mount -t ext3 -o loop ~/.mybackup.img /dev/shm/myrecoveryimage

…or for a Windows NTFS formatted backup image:

$ sudo mount -t ntfs -o loop ~/.mybackup.img /dev/shm/myrecoveryimage

We have told the system to mount an image file of filesystem type Ext3 (or NTFS). We have to specify the loopback device because an image file is not a block device like a hard-drive is. We then specify the filename of the image we are wanting to mount, and finally where we are mounting it to.

You can now simply switch over to the mountpoint directory and see the content of the image file as though it were any normally mounted hard-drive.

$ cd /dev/shm/myrecoveryimage
$ ls -l

There are a plethora of filesystems that the mount command can manage including FAT, NTFS network filesystems etc. Refer to the man page for the mount command for more details.

When you have finished with the image, you can unmount it with:

$ sudo umount /dev/shm/myrecoveryimage

…and that will make the /dev/shm/myrecoverimage directory revert back to an ordinary empty directory again (which, being in the RAM disk, will be lost when you reboot).

Happy dd’ing!

Like

Unlike

For this comparison, I have pitted the following versions of Ubuntu and Vista against each other:

• Microsoft Windows Vista Ultimate with Service Pack 1 and all system updates to 29th October 2008
• Ubuntu Linux 8.04.1 Hardy Heron with all system updates to 29th October 2008
• Ubuntu Linux 8.10 Intrepid Ibex Release Candidate with all system updates to 29th October 2008 (just for kicks)

The tests would be simple. A fresh vanilla install of Ubuntu and Vista doing four of the most common things a typical user might do everyday:

1. Nothing
2. View a web page
3. Listen to an MP3 music track
4. Play Solitaire

To keep things as fair as possible, I used Virtualbox 2.0.4 and created three VM’s each sporting 1GB RAM, 32MB video RAM and an 8GB HDD file each, except for Vista which needed more HDD estate, so it got a 20GB HDD file instead (this is not boding well for Vista already!).

The Ubuntu installs each had a 512MB swap partition created while Vista went ahead and stormed in with an automatically-created 2GB swap file. Shouldn’t be an issue as the tests are not going to tax the OS’ anyway.

All installed OS’ are the 32-bit versions. All had the Virtualbox Guest Additions drivers added, but since these drivers do not support acceleration, OpenGL and DirectX eye-candy (such as Compiz in Ubuntu and Aero in Vista) were automatically disabled by the system.

The host hardware for the VM’s is an Intel Quad-core Q9450 based machine with 8GB RAM running the 64-bit version of Ubuntu 8.04.1 Hardy Heron.

Installed Disk Usage

So let’s start with the simple stuff  – how much disk space does a vanilla install of each OS chew up? The following table shows a completely stock installation of each OS, including subsequently downloaded update files:

Ubuntu has been dubbed by some to be the “Windows” of Linux distros in terms of its overall weight, but it’s anorexic compared to Vista. Why does any OS need over 10GB of disk space just for itself? Consider also that Ubuntu’s installed space also includes a full office suite – not even Vista has that, yet it’s so much bigger.

It was interesting to note that Ubuntu Intrepid consumed a whole 400MB less disk space than Ubuntu Hardy, however part of this could be attributed to possibly less extra update files downloaded compared to Hardy. In any case, both are well under 5GB, let alone 10GB!

So far one point to Linux and a big fat zero to Vista.

Idle RAM Usage

With disk usage now established, how does the RAM stack up? Each desktop was at its standard setup with standard wallpaper, panels, widgets, etc and only the resource manager window on-screen:

Vista SP1	411MB
Ubuntu 8.04.1 Hardy	122MB
Ubuntu 8.10 Intrepid RC	142MB

Another win for Ubuntu by a good 250MB. Also, again a surprise showing by Intrepid that despite the smaller HDD footprint, its resource usage was 20MB greater than Hardy, but what was alarming was that Vista was already using 387MB of its 2GB swap file while both Ubuntu installations had not touched theirs…!

Two points for Ubuntu, none for Vista.

Browsing a Common Web Site

Now to up the ante – all three installations now used their default web browser (Firefox 3.0.3 for Ubuntu, Internet Exploiter, uh, Explorer 7.0.6 for Vista) to view a common website containing Flash, animated GIFs, lots of frames, blocks of formatted text and graphics – the Sydney Morning Herald homepage.

All three OS’ do not have Flash installed as standard and thus did not play any of the Flash content, however the rest of the page did load and render successfully.

The memory usage now stands at:

Vista SP1	490MB
Ubuntu 8.04.1 Hardy	179MB
Ubuntu 8.10 Intrepid RC	198MB

A notable jump by all three candidates in this case, as one might expect, though while Ubuntu jumped up some 55MB, Vista jumped up an extra 80MB.

Curiously, Vista’s CPU usage jumped up and down a lot while the site sat idle and the spike of usage you see at the end of the graph is when the site automatically refreshed itself. No such major jumps from Ubuntu.

Another point for Ubuntu for a total of three. Vista is yet to score.

Listening to an MP3 Music Track

Browsing any website would just not be fun without some background music. Using the default music player (Totem 2.22.1 and 2.24.2 for Ubuntu Hardy and Intrepid respectively, Windows Media Player 11 for Vista), I perused the SMH website (without clicking on any new links) and listened to the same 3.3MB MP3 music track for 1 minute to allow memory usage to level out.

Vista SP1	560MB
Ubuntu 8.04.1 Hardy	211MB
Ubuntu 8.10 Intrepid RC	237MB

Memory usage has increased by nearly 40MB on Ubuntu but by 70MB on Vista. This is not really too surprising given the heavyweight that is Media Player versus the simpler Totem, though Totem did prompt me to download and install the GStreamer Extras MP3 codec, so there’s extra memory usage there too.

The observant among you might say that it would be a fairer comparison to compare Windows Media Player with Rhythmbox, however I decided to go with whatever launched as the default MP3 player and at the end of the day, all that matters is that I can hear my music and Ubuntu has delivered 30MB ahead here.

Four points for Ubuntu, still none for Vista.

Playing Solitaire

Surfing the ‘net is hard work and what better way to unwind than with a relaxing game of Solitaire. In this test, I played Solitaire for two minutes whilst listening to my MP3 track and leaving the web browser open with our self-refreshing homepage.

Vista SP1	605MB
Ubuntu 8.04.1 Hardy	224MB
Ubuntu 8.10 Intrepid RC	244MB

Really, Solitaire isn’t a terribly complex application and Ubuntu’s Solitaire bears a remarkable resemblance to all the Windows versions… except Vista which was drastically revamped with extra visual effects, new card textures, etc. No wonder the memory footprint is so much bigger, but a 45MB difference??

Ubuntu Hardy went up 13MB and Intrepid didn’t even break double-figures with only a 7MB increase.

We could keep testing common applications until the cows come home, but I think it’s pretty clear that the established pattern is that Microsoft Vista uses up much more memory and disk space on average than Ubuntu Linux.

Probably what was the most worrying here was that Vista’s swap usage had increased to 692MB and there was an unusually high amount of CPU usage, while both Ubuntu’s had left their swap on the plate, uneaten.

So the final score is five points for the trim and healthy Ubuntu and still nothing, nada, zip for the obese whale that is Vista.

Conclusion

I think some people might say all I’ve done is confirm what everyone already knew, and perhaps that is the case, but it still made for an interesting comparison and certainly highlights that Microsoft need to do some serious fat trimming.

For those that are interested, the host machine used up a total of 4GB RAM to run all three VM’s simultaneously plus a bunch of other apps that I had running at the time of testing, and it only nibbled at 44MB of swap.

Click for the full-size version – 681K

To address the CRC issues, the drive had CHKDSK /F run on it within Windows, and this reported a number of issues that were supposedly fixed. Unfortunately it seemed to make things far worse – you plug the drive into a Windows PC now and the drive would take several minutes to appear, and even then the Explorer window was empty! All his files were gone! Panic stations!

Not one to give up so easily, he asked me to have a look at it. First thing I did was plug it into my Ubuntu-based EeePC 701, and while still slow to appear, Nautilus popped up showing most of the files! Some entries appeared to be missing, but we put that down to CHKDSK having removed corrupted entries from the allocation table.

Unfortunately I didn’t have enough space to make an image copy of his drive which would be the preferred method of recovery (it’s a 750GB drive), so we decided to try and hit the files directly.

I tried copying a single directory of files, and they copied successfully, so I spent an evening doing drag and drop between two Nautilus windows (I tried using RSync to do it from the command line, but there are several individual files that come up as corrupt and throw RSync out). Copying one directory at a time seemed to be the best way to keep track of what was recovered and what wasn’t.

This weekend I’ll be trying to go deeper and see if I can recover the “lost” files that CHKDSK managed to hide away from us.

It’s great to see that Linux can do a better job of recovering NTFS than Windows can!

EDIT: Well, the recovery of nearly everything was successful. Unlike Windows, Linux did an admirable job of trying to copy as much of an existing file as possible before aborting at the CRC error in the file. Turns out not too much of the hard-drive was corrupted and my friend only lost half of about 5 individual movies and some of his non-essential work backups. All in all, a good recovery.

As a test, we tried plugging the drive into a Windows PC again to see if it could read any of it, and true to form, Windows Explorer remained blank – oblivious to the files that Linux was so aptly able to read and recover.

Like

Unlike