Things you should never EVER type in Linux. Ever!

Things you should never EVER type in Linux. Ever! I feel that I need to put a warning at the top of this post because try as I might in the subject to be clear about what I mean, I know that someone will go and type/execute one of these things into their production server at work and then be horribly distraught and/or cause some sort of power grid catastrophe across the Pacific Northwest or something.

If you’re a Linux guru or or experienced enough to know what all of these things are then you probably don’t need this article and we can go our merry ways. If not, then DO NOT, DON’T, NEVER EVER EVER EVER run these commands in a terminal session. If you do you will render your system anything from useless without a forced reboot to devoid of any useful purpose ever.

Why write this article on ArsGeek then? Because you should be forewarned as a Linux user that there are people out there who consider it good fun to bait others into running destructive and harmful commands on their machines. Particularly those new to Linux. So use this list as a caution as to what not to do. And note that it’s not an exhaustive list, simply a quick reference against stuff you really don’t want to do. Bottom line is, research what you’re about to execute before you push the enter key and know what you’re doing to your system, yourself and your job prospects.

Let’s start with commands that delete things that probably shouldn’t be deleted, shall we?

The basic way to delete a file in Linux is with the rm command. rm foo will take foo, wring its skinny neck and throw it down the drain. Gone. See you later.

Now there are lots of variants on these commands. Let’s look at a few. Again, look but do not execute!
rm -rf ./ - Delete the files in a current directory (all of them)
rm -rf / - Delete the partition. (AHHH!)
rm -rf . - Delete the whole directory.
rm -rf * - Delete all visible files in a directory

Running all of these commands have certain real world utility. They’re also a great way to fubar your system if run in the wrong place. Remember ‘rm’ means remove. -r means recursive and -f means don’t bother asking me if you want me to really delete your /usr/bin directory – or any other for that matter.

Mean folks have gotten slightly more creative and regular Linux users have made this mistake more than once.

rm -rf .* - Delete all hidden (files that start with a ‘.’) files.

Now, how about the good old fork bomb! Sounds ominous eh? What a fork bomb does is eat up all of your available system processes, essentially bringing your system to it’s knees. A fork is when a program spawns another program – often a version of itself. A fork bomb is when this happens endlessly and nearly exponentially until there are no resources left on your system. Most often the only way to get out of this is to hard reboot (i.e. hold down the old power button) which can cause file system problems. Here’s a few examples of fork bombs to watch out for:
:(){ :|:& };: - The cutest one. Like a vorpal bunny.
#!/usr/bin/perl - for Perl meanies.
fork while 1

or also in perl:
fork while fork
#include <unistd.h>
int main(int argc, char* args[])
return 0;

That last one is in C. As you can see there are a bunch of ways to do this – the above examples are only that, examples. Just be careful of code you don’t know with the word ‘fork’ in it, or of typing lots of emoticons into your shell.

Even windows users can be subject to fork bombs in the form of malicious batch code. Here are two examples:

The next kind of code bomb is a tar bomb. Tar is a nifty program for compressing and uncompressing stuff so you don’t have to lug around hefty loads of data. Tared files can be crafted however to ‘explode’ into an existing directory, rather than into a new directory.

An example: Say you’re in your home directory and you have file called foo.tar you want to untar. So you do so and it should untar into a directory called /foo sitting in your home directory. Through malice or bad practice though, it could just untar all of it’s files into your /home directory. This is bad if there are say. . . 487,038 files in the tarbomb. Now you’ve got all the junk to sort through in your home directory. Ouch!

The same can be said for any uncompiled code. If you don’t know where it’s coming from think twice before compiling it. It’s very easy for someone to hide a chunk of malicious code in the thousands of lines of codeit takes to make a program.

Bottom line is – be cautious, don’t run things if you don’t know where they came from and always, always check what a command does if you’re not familiar with it. Not only will this make you more productive and more powerful user but it will help you protect yourself as well. Remember this isn’t an exhaustive list, there are plenty of other tricks out there as well. Be safe.

Edit: Thanks to the commenters for pointing out some errors – I’ve since corrected them!


How to clone your bootable Ubuntu install to another drive

clone.jpgIf you’ve ever wanted to completely clone your Ubuntu install, with all of the tweaks, files you’ve downloaded and changes you’ve made to it, there’s a fairly simple way to do this. What you will learn in this ArsGeek tutorial is great if you want a complete backup, or if you’re looking to move your system to a newer (read: bigger, faster, stronger) hard drive or even just to clone your install to other business machines with the same hardware.

We’ll be using the terminal (Applications-> Accessories-> Terminal) and the dd command to do this. You’ll also need to have your second disk up and running when we get going. You can either have it installed and mounted internally or use an external disk enclosure and USB or Firewire. (Note: Doing this via USB 1 will be excruciatingly slow!)

You’ll also want to either be cloning your hard drive to one of the exact same size, or if you have a larger disk, make a partition of the same size on it and clone to that. Then, use an Ubuntu liveCD to change the partition size (System-> Administration-> Partition Editor). Lastly, you’ll need a Ubuntu LiveCD.

On to the good stuff. Got both disks plugged in? Good! Now you’ll need to figure out which disk you are copying from and which disk you are copying too. In your terminal, type:
df -h
Look first for the partition that’s mounted at root, or ‘/’. Here’s what my root partition looks like.
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 71G 46G 22G 68% /

If you’re using a SATA drive it will appear like that. IDE should be /dev/hda1. See that slash below the Mounted on? That’s the root drive.

Now you’ve got to locate the drive you’re copying too. The same df -h command will do the trick. Look for another disk mounted on /dev/****. If you’re not sure what you’re looking for, first run the df -h command without your second disk mounted. Then plug the 2nd disk in (be sure to shut down if you’re doing this inside your machine and not via USB or FireWire) and run the df -h command again. The newest partition that appears is what you’re looking for!

So if your current root partition is /dev/sda1 and the partition you’re going to copy to is /dev/sdb1 (a USB mounted drive) here’s the command you’ll need to type in your terminal:

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

Replace with the correct paths for your drives if they differ. It’s going to take a while, so grab a book or start up a movie. Maybe go to bed.

Once it’s complete, you’ve got yourself a brand new copy of your current Ubuntu install. You’re not quite done yet though. Now you’ve got to install Grub on your new disk so you can boot from it. Make sure your new disk is attached to your machine and your old disk is unplugged and boot into the Ubuntu LiveCD.

Once your machine boots up, open up a terminal session and type:
sudo grub
Grub will launch and give you the grub> prompt. Here, type:
find /boot/grub/stage1
You should see something come back that looks like hd(0,0). Jot that down, you’ll need it in a second.

Now, still in the grub> prompt, type:
root hd(0,0)
You’ll put in whatever result you go above – it may be different than hd(0,0).

Once that completes, type:
setup (hd0)
Even if you got a result that differs from hd(0,0) above.

And you’re out of grub. Restart your machine, removing the LiveCD and you should be up and running on your new hard drive. You may also encounter a problem on your first boot where the system will try to scan your hard drive for bad sectors. If that fails, you’ll find yourself in a root terminal session. Just type:
Let the disk check finish and you should be good to go.


How to fix your Windows MBR with an Ubuntu liveCD

windows-mbr.jpgSomething happen to a windows Master Boot Record (MBR) that you’re responsible for? Want a very quick, very easy way to restore it with nothing but your craft, native intelligence and a liveCD?

Be cautious here – you’re working with your disks in a very direct manner. If you don’t have everything backed up or are unsure of anything, you may want to wait until you have a standard Windows CD/DVD.

Boot into your Ubuntu LiveCD on the offending machine. Once Ubuntu starts up, go to System -> Administration -> Software Sources and enable (by checking it off) the Universal repository.

Now, open a terminal session (Applications -> Accessories -> Terminal) and type the following:
sudo apt-get install ms-sys
ms-sys is a program used to write Microsoft compatible boot records.

Now you’ll need to figure out what partition is the one hosting your Windows operating system. Back in the command line, type:
sudo fdisk -l
That will list the available partitions. You’re looking for a partition that says something like
/dev/sda1 1 9327 74919096 83 NTFS
The two important bits are the ‘/dev/sda1‘ which is the partition itself and the ‘NTFS‘ which tells us it’s a Windows formatted partition. So your Windows partition exists on your drive sda and it’s partition 1. The MBR for drive sda (assuming you boot into windows using it’s native boot loader) is what you want to repair.

We want to fix the MBR on /dev/sda. To do so, type:
sudo ms-sys -m /dev/sda
You’ll want to change the ’sda’ bit if your results from ‘fdisk -l‘ are different. If for instance your windows install is on sdb or hda.

Once you do that, reboot the machine, removing the LiveCD from the drive and Windows should come back to you.

Sure, you could do this by inserting the correct Windows CD and booting into repair mode from it – but I find the Ubuntu way a bit faster and I’m more likely to have an Ubuntu LiveCD on me than a Windows CD. For alternative ways make sure to search through the posts on our homepage.


How to find your UUID’s for devices in Ubuntu (and other Debian based distros)

uuid.jpgHave a burning urge to discover the UUID’s of your disk partitions? Run Ubuntu or some other Debian based distro like maybe Debian? Well have I got the article for you friend! Here it is, two easy steps to discovering your UUID – and the best part? For two steps I’ll give you two different ways to get that pesky UUID on your screen.

But first, what exactly is a UUID? From Wikipedia we see that a UUID is a Universally Unique Identifier. “The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else.”

For a little more trivia: A UUID is a 16-byte (128-bit) number. The number of theoretically possible UUIDs is therefore 216*8 = 2128 = 25616 or about 3.4 × 1038. This means that 1 trillion UUIDs would have to be created every nanosecond for 10 billion years to exhaust the number of UUIDs. That’s a lot of UUIDs.

These unique ID’s are used by Ubuntu to identify your various partitions for the system. So if you do a quick
cat /etc/fstab
You should see at least one, probably two and possibly more UUID’s in there. One for your primary partition and one for your swap partition, plus more if you have any removable devices, other drives or other partitions around. It will look something like UUID=1c9e4ae2-0ddc-4e3c-8758-4cdd6c90407a.

So how do you discover just what partition belongs to which UUID? Open up a terminal session (Applications -> Accessories -> Terminal) and type the following:
On my system, the output is as follows:
/dev/sda1: UUID=”1c9e4ae2-0ddc-4e3c-8758-4cdd6c90407a” SEC_TYPE=”ext2″ TYPE=”ext3″
/dev/sda5: UUID=”a647ea33-74ee-4123-84bf-7edc32e2e39b” TYPE=”swap”

So sda1 (my primary partition) and sda5 (my swap partition) are identified.

Or, your could type:
ls -l /dev/disk/by-uuid
and see something like this:
lrwxrwxrwx 1 root root 10 2008-01-02 08:26 1c9e4ae2-0ddc-4e3c-8758-4cdd6c90407a -> ../../sda1
lrwxrwxrwx 1 root root 10 2008-01-02 08:26 a647ea33-74ee-4123-84bf-7edc32e2e39b -> ../../sda5

There you can get the UUID and also see who owns the partitions, when they were last touched, their permissions and finally, what they’re called (sda1 and sda5 in this case).

If you’re trying to pin down which UUID is associated with a particular thing, such as your root partition, you can cat /etc/fstab and look for the UUID associated with the mount point “/“.


Get USB devices mounted on your Virtualbox XP machine in Gutsy (Ubuntu 7.10)

vbox.pngThere’s nothing more frustrating than not being able to mount your USB devices in your virtual machines. Well, maybe there are lots of things that are more frustrating but this morning my inability to do something that should be simple, easy and fun was driving me nuts.

So I figured out how to do it and decided to share this software solution on Arsgeek. It’s not terribly pretty but here’s what you need to do.

First, Gutsy got rid of the previous versions of Ubuntu’s way of handling USB mounts by not using USBFS anymore. Doh. That’s an issue for Virtualbox and your virtual XP installs. So you’ll need to download and install the latest Vbox release, 1.5.2. Click on that link to download the .deb file. Save it on your desktop and then double click on it to install it.

For a quick and easy tutorial on using Virtualbox and installing a virtual XP instance, see UbuntuGeek.

Once you have your virtual XP machine running on your Gutsy host, it’s time to do a wee bit of hacking. Turn of your XP instance and let’s roll up our sleeves and get to work.

First, open a terminal session (Applications-> Accessories-> Terminal) and type in the following to edit a script file:
gksudo gedit /etc/init.d/
Once you’ve got that open in Gedit, type CTRL-F to search for a string. Search for ‘magic’ (sans quotes).

That should bring you to this:
# Magic to make /proc/bus/usb work
#mkdir -p /dev/bus/usb/.usbfs
#domount usbfs “” /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
#ln -s .usbfs/devices /dev/bus/usb/devices
#mount –rbind /dev/bus/usb /proc/bus/usb

All those pound signs are comments. Remove them from the last four lines so you end up with this:
# Magic to make /proc/bus/usb work
mkdir -p /dev/bus/usb/.usbfs
domount usbfs “” /dev/bus/usb/.usbfs -obusmode=0700,devmode=0600,listmode=0644
ln -s .usbfs/devices /dev/bus/usb/devices
mount –rbind /dev/bus/usb /proc/bus/usb

Save the file and exit Gedit. Round one goes to the user!

Now we’re going to create a group called usbusers. Go to System-> Administration-> Users and Groups. Type in your password and then click the Manage Groups button. From there click the Add Group button and name it usbusers. Check off your username below. Exit these windows and round two goes to us.


Now we’ve got to change a file in udev. So, let’s gedit it and gedit over with. I’ll apologize for the bad jokes in a later post.
gksu gedit /etc/udev/rules.d/40-permissions.rules
Again, CTRL-F to bring up the search dialog and search for ‘usbfs replacement’ (again, sans quotes). Once you find it, you should be looking at this:
USB devices (usbfs replacement)
SUBSYSTEM==”usb_device”, MODE=”0664″

You’ll want to change it to this:
# USB devices (usbfs replacement)
SUBSYSTEM==”usb_device”, GROUP=”usbusers”, MODE=”0664″

Save your file and exit out of Gedit.

Now, the last bit of hackery which may or may not be required for you. It was for me. We’re going to add a mount to /etc/fstab for usb devices using usbfs.
gksudo gedit /etc/fstab
At the bottom, add the following line:
none /proc/bus/usb usbfs devgid=46,devmode=664 0 0
Save the file and exit Gedit. Phew! Now, the easiest way to get all of these changes working on your system is to restart it. So go ahead and do that and then I’ll see you back here in a few.

Back? Great. Time to plug in your USB device, whether it’s a thumb drive, an iPod or something else, plug it in and let Ubuntu detect it.

Now, we’re going to open up Virtualbox and make some changes to your XP machine BEFORE you start it up. So go to Applications-> System Tools-> Virtualbox and get it started up.

Highlight your XP machine (if it’s not the only instance of a virtual machine) and click the Settings button at the top of Virtualbox. You should now have a USB option on the left hand side of your settings. Click the add icon on the right hand side (see the pic below) and select the device from the list. In my example, it’s a 512MB memory key. Now click the Okay button.


Start up your virtual XP machine and you will see a notice pop up courtesy of Ubuntu about unsafe device removal. Nod your head sagely and let’s continue on. Once XP is up and running, it should automatically detect the new USB device, and do it’s best to install it. With my memory key, it was as simple as turning the virtual XP machine on and letting XP take care of it.

You may have to go to the Devices menu on your virtual machine (once it starts up) select USB Devices and then uncheck whatever it is you’re trying to mount. Repeat the process, this time checking it off and it should mount if it didn’t automatically.


Ubuntu getting Xorg.conf GUI

Remember the good old days when to change a screen resolution or driver, you had to edit xorg.conf or reconfigure Those fine times are now over, or they will be, with the release of Ubuntu 7.10. As of an update from a few days ago, users are now able to access a graphical user interface for editing xorg.conf and it’s about time!