The machine starts up fine, but when you try and hit the network, you can’t. Closer inspection using the ifconfig command reveals that there is no “eth0″ adapter configured. Why?

Here’s how to fix it.

Ubuntu Server keeps tabs on the MAC address of the configured ethernet adapter. Unlike Ubuntu Desktop, you can’t simply change network cards willy nilly – while Ubuntu Server does detect and automatically setup new cards, it won’t automatically replace any adapter already configured as eth0 with another one, so you need to tell Ubuntu Server that you no longer need the old adapter.

This problem can also appear if you have a virtual machine such as one from Virtualbox, and you move or copy it from one host to another without ensuring that the MAC address configured for that VM’s ethernet adapter is 100% identical to the previous one.

These instructions were done with Ubuntu Server 9.04 Jaunty Jackalope in mind, but should apply to just about any release.

1. Since you can’t SSH in, you will need to login directly on the Ubuntu Server console as an appropriate user with sudo rights.
   .
2. Once logged in, type in the following and hit Enter:

   $ sudo nano /etc/udev/rules.d/70-persistent-net.rules

3. You are now presented with the Nano text editor and some info that looks similar to the following:

   # This file was automatically generated by the /lib/udev/write_net_rules
   # program, run by the persistent-net-generator.rules rules file.
   #
   # You can modify it, as long as you keep each rule on a single
   # line, and change only the value of the NAME= key.
   
   # PCI device 0x8086:0x1004 (e1000)
   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="0a:03:27:c2:b4:eb", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

4. Delete the last two lines or simply comment out the SUBSYSTEM line on the end. This is a rule defining what MAC address should be explicitly assigned to “eth0″. Since you no longer have an ethernet card with the specified MAC address in this machine (it’s on the old PC, remember), Ubuntu Server effectively ignores your new ethernet adapter because its MAC address does not match the defined rule for “eth0″.
   .
5. Once you’ve made your changes, press CTRL + X and then Y and then Enter to save your changes.
   .
6. Now reboot your box with:

   $ sudo reboot

7. Upon reboot, Ubuntu Server will detect the “new” ethernet adapter in your PC and will automatically write a new rule into the /etc/udev/rules.d/70-persistent-net.rules file, thus enabling networking over eth0 for your server.
   .
8. To verify that the new adapter is working, type in:

   $ ifconfig

   …and you should see eth0 now listed with your defined IP address.
   .

9. Test remote connectivity to the server and if all is well, then pat yourself on the back. You’re done.

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…

Like most people, I use an external hard-drive to backup data to, or to shift things around if I’m low on space on my PC’s internal drive. Well, today that external drive reported that it was full. Damn.

So I fire up Ubuntu’s Disk Usage Analyser, aka Boabab, to find out what’s consuming the most space. I use a 1TB external drive and it’s formatted total is about 916GB, which is about right, however Boabab reported that the total consumption of data on the drive only added up to about 860GB – wtf? Even Nautilus’s Volume Properties window was reporting that the drive still had 50GB-odd free, so why is the system telling me it’s full?

I use Ext3 on my drives and, being a journalled filesystem, some space on the drive is reserved to record these journals among other functions which is expected, but 50GB worth? I did some research and found out that the Ext3 filesystem reserves 5% of disk space by default for itself! In this day and age of large drives, that’s a huge chunk of lost space!!

Thankfully there is a way to tell Linux not to reserve so much space. Read on…

1. First up, unmount your drive. You can do that by either right-clicking on the drive icon on the desktop and choosing “Unmount volume” or by clicking on the Eject icon next to it in the Places pane of any Nautilus window.
   .
2. Next, open up a terminal and type the following:

   $ sudo fdisk -l
   

   This will list all your available drives. Identify which one is your external drive and take note of the device name, eg: in my case my external drive appears as /dev/sdb with one partition on it, sdb1.
   .

3. Now type in the following:

   $ sudo tune2fs -m 1 /dev/sdb1
   

   This will modify the filesystem on that drive, on that one partition, to only reserve 1% instead of the default 5%.
   .

4. Now re-mount your drive by clicking on its name in the Places pane in a Naultilus window.
   .
5. The Nautilus Device Properties window will still show the same free space as before, because it reports the true total free space, but any Nautilus File Manager window only reports usable free space, which in the case of my external drive had now freed up a very sizable 37GB!
   .
6. Lather, rinse, repeat on any other non-system drive partitions on the same or different drive you want to reclaim space back for.

You learn something new everyday.

• 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