Below is the method I personally found to work reliably:

apt-get install ifenslave
echo "bonding" >> /etc/modules
modprobe bonding
ifdown eth0

edit /etc/network/interfaces, changing “eth0″ (or your configured NIC) to “bond0″, and replacing “allow-hotplug” with “auto”.  The following sed line give you this automagically:

sed 's/eth0/bond0/;s/allow-hotplug bond0/auto bond0/' </etc/network/interfaces

Tell ifup and ifdown to add/remove devices to bond0 lines:

echo " up /sbin/ifenslave      bond0 eth0 eth1" >> /etc/network/interfaces
echo " down /sbin/ifenslave -d bond0 eth0 eth1" >> /etc/network/interfaces
ifup bond0;

And you’re done!

You can add all the options for the bonding module to the line in /etc/modules, like:

echo "bonding mode=1 miimon=250 primary=eth0" >> /etc/modules;

Details of all options available at linuxfoundation.org

This was born when someone brought me a near dead hard drive (a serious number of read errors, so bad that nothing could mount or fix the filesystem), asking if I could recover any data.

Now obviously (as almost any geek would know), the answer of course is a very likely yes. There are many ways of recovering data. One such way (which I performed) is using Foremost to find files based on their headers and structures. While this technique works really quite well, it does miss a lot of files, fragment others up, leave bits out and generally not retrieve any metadata (such as filenames etc).

This makes Matt mad. No filenames == days of renaming files.

So I booted up Helix, created a quick image of the drive to a 500GB external drive, and tried running Autopsy (the GUI of Sleuthkit). This is where things got interesting.

I say interesting, because Sleuthkit couldn’t read the filesystem. But it could retrieve the inodes, and the metadata along with them. And it could accordingly retrieve the data content of (some) files.

Observing this, I realized there was a high probability that I could somehow use Sleuthkit’s command line tools to retrieve the files which were not on bad clusters and recover the filenames from the inode. As it turns out, this wasn’t such a bad idea!

There are 3 tools which proved useful:

• ils
• ffind
• icat

ils “lists inode information” from the image, ffind “finds the name of the file or directory using the given inode” and icat “outputs the content of the file based on it’s inode number”. Using these three tools and a bit of bash, we can grab a list of inodes, get the filename from the metadata, create the directory structure beneath it, extract the file content, move on to the next.

So for this task I knocked up the following (really ugly, potentially unsafe) script:

#!/bin/sh
for inode in $(cat /tmp/inodes) ; do
 
/KNOPPIX/usr/local/sleuthkit-2.09/bin/ffind /dev/hda1 $inode
 
if [ $? -eq 0 ]
then
	echo "INODE: $inode"
	INODEDIR=`/KNOPPIX/usr/local/sleuthkit-2.09/bin/ffind /dev/hda1 $inode`
 
	REALDIR=/mnt/out`dirname "$INODEDIR"`
	FILENAME="/mnt/out$INODEDIR"
	mkdir -p "$REALDIR"
 
	echo "FILENAME: $FILENAME"
	/KNOPPIX/usr/local/sleuthkit-2.09/bin/icat /dev/hda1 $inode > "$FILENAME"
 
	if [ `du "$FILENAME" | awk '{print $1}'` == 1 ]
	then
		rm "$FILENAME"
		mkdir -p "$FILENAME"
	fi
	echo ""
fi
done

Really, I do warn you, take serious care running this!

It needs a lot of work, but enough is there for it to function. It reads a file of inode numbers (one per line) and uses ffind to get the filename. We extract the path, attempt to create it, output the file content and (this is important), take a wild guess at if the inode was a directory. Please note this is wildly inaccurate and needs serious rethinking! Currently we look at the file size, and assume directories alone use 1 byte.

We can populate a file with inode numbers like so:

ils -a /dev/hda1 | awk -F '|' '{print $1}' > /tmp/inodes

(Users of Helix will need to use the full pathname to ils as in the above script).

At some point (no garuntees when) I’ll tidy up the script and make it more bullet proof. In the meantime, I hope this saves some data!

Remember: No matter how much data you have, it’s always better to have 2 hard drives of half the size, mirrored than it is to have one large expensive drive. They will die unexpectedly! When you next buy a bigger hard drive, consider this: 1x500GB drive will loose you 500GB of data. 2x250GB will 99.9% probability loose you nothing. So if you’re on a tight budget, buy twice smaller. If you’ve a lot of money, buy twice big.

Oh, and always make regular backups. Cheap USB drives are good for this!

It’s essentially nothing more (but it is a lot!) than a front end to several other GPL’ed tools, including BZip, growisofs and busybox.  To cut a long story short, it builds a set of CDs, DVDs, USB sticks with a tiny bootable Linux distribution based on your server’s kernel, which can restore parts or all of your filesystem from tarballs on the media.  It can also backup to tape drives, NFS mounts or a local filesystem.

It has (imo) a nice, clean ncurses interface; and it’s quick to use.  On an AMD K6 clocked at 350MHz, with 60MB free memory, it took just under 6 hours to compress 8.5GB of data down to a single DVD (4.7GB).  Doing the backup with an “average” compression took far less time (around an hour), but would have eaten up several DVDs.

You’re presented with a wide variety of options when you boot up the produced rescue media.  You can “nuke” the system and start from scratch, or just restore the parts you want.  It can handle new disk geometry, and because the entire rescue system is burnt onto the media, (assuming you used CDs, DVDs or USB storage), it’ll work even if the target machine is clean.

So the situation is, you’ve got two hard drives, one was more or less written off by a mouse urinating on it, the other is slightly smaller but fully functional. You want to move the Linux install (including all configuration etc) onto the better, smaller drive with minimal hassle. Believe it or not, it’s not that difficult.

Please note the instructions I give below worked for me. I don’t and will not hold and responsibility for you trashing your own computer by following them, YMMV.

Ok. Step one I figured was to copy the filesystem from the old HD to the new one. The simplest was I could see of doing this was:

• Plug the new HD in via my removable caddy
• Boot up the existing Linux install and mount the new HD

So far so good. Next I cleaned up the new HD (when I say new, it’s actually quite old, but it’s new relative to this project if you follow), so as root “fdisk /dev/hdc” (in my case, obviously replace hdc with your second HD’s device) and removed all the existing partitions. I then created a new one for my root filesystem (and you will probably want one for your swap space).

• fdisk /dev/

Next we generate a new filesystem. In my case, an easy “mke2fs -j /dev/hdc1“. Don’t forget to write down the locations of those backup superblocks! Might just save your data some day.

• mke2fs -j /dev/

Side note 1: I guess it’s entirely possible to copy your Linux install using this method to a mounted loop device (i.e. a disk image), although quite why you’d want to I can’t imagine… but the process would be exactly the same.

Side note 2: Personally I would always at this point perform a complete scan of the new HD just to be absolutely sure I’m not making things worse and wasting my time. The command “fsck.ext3 -cf” (for ext3 anyway) will perform a bad block scan, logging anything found for future avoidance. Even new HDs can come with bad blocks, if you notice a lot being reported, consider scapping that HD.

It’s important to take note at this point that you’re going to have problems if you’ve done one of the following things: a. created a new partition smaller than the amount of data in your existing partition (df -h will tell you) b. you’ve created a different filesystem type to what you’re currently using. It’s outside the scope of this blog to discuss those.

Next copy everything you want over to the new partition. In my case this was everything from /bin to /var, excluding /mnt and a few other mounted directories. Don’t copy mounted directories (that includes /proc and /mnt etc), rather just create them on the new partition with “mkdir /mnt/proc” etc). This can be easily achieved using “cp /bin /mnt/ -R” (and so on). Make sure you do copy /dev, I made that mistake first time and it produces some weird results.

• cp /everythingyouwant /mnt/ -R

OK! Nearly there. Shutdown, swap the two HD’s around and boot back up. Don’t forget to tell the BIOS of the changes and to check those jumper settings. Make sure your BIOS boots the old HD, at the moment GrUB doesn’t exist on the new one. Boot it, pass through GrUB as normal and you’ll hopefully be brought into Linux, from your new HD. If something goes wrong, post a comment and myself or someone else will try to help.

So assuming you’ve logged in all OK, you’re ready to install GrUB on your new HD. Once this is done, you’re ready to shutdown, remove the old HD, tell the BIOS to boot the new one and continue your normal work!

Run “grub-install” as root, let it figure out what exists and if all goes well, it’ll pick up your existing (copied from the old HD) /boot/grub/ directory and place it’s stage1 onto the new HD’s boot sector. If Grub doesn’t output any errors, you’re ready to try shutting down and rebooting. If Grub does complain, it might be something simple, it might be something complex. Again, feel free to leave a comment.

• grub-install

OK, reboot, set the BIOS to boot the new HD and see if it works. If it doesn’t, you’ve probably just mis-configured GrUB. A boot disk or booting the old HD will give you an environment to play in, the GrUB website has a lot of details on configuring GrUB correctly. Remember to keep the menu.lst the same as before, nothing in there should need changing (unless you’ve moved other HDs around or partitioned the new drive differently).

You should now be back, booted up and working! Congratulations! Told you it wasn’t too hard

Important note: If you’ve had serious problems with the old HD, it might be worth you reinstalling all packages (or reemerging if you’re a Gentoo user) to make sure none of your binaries are corrupt. On on Gentoo it’s something like “emerge –reemerge world” iirc, as for other distros I don’t know, look up the manuals. Also make sure none of your configurations or home brewed scripts need modifying now the HD has changed, I think particularly of SMART tools and software RAID. I also had a lot of problems getting Cron to run, so just watch your back and check everything extensively works before relying on it.

As always, any constructive comments would be appreciated.

I’d tried googling for the answer to this question without avail, so I’ve blogged it here to hopefully answer the question for someone else in my same situation.

The problem is you have a large hard disk, let’s say 80GB. The computer’s BIOS is old and can’t detect it properly. The question is, can Linux access / mount / detect a hard disk larger than the BIOS supports and can detect?

Well the answer it would seem is proved to be yes, in at least some circumstances.

I’m not saying this will work for everyone, because I’m not a Linux expert. But it did work for me, and I’ll give my educated guess at why.

When Linux boots (well actually just before it boots) the computer moves from 16bit to 32bit mode (“protected mode”, a 386 feature which stuck and exists even in the latest x86 AMD and Intel processors). When this happens, the BIOS is rendered fairly uesless (as I recall, it was a long time ago I was interested in writing my own 32bit OS!) and so the Operating System starts accessing hardware through “IO” ports, special registers (again, as I recall) in the processor. Through these, it can access all the hardware without going near the BIOS, so even if your HD is not supported by the BIOS, it may well be accessible by Linux, or any other 32bit Operating System.