Linux Tips + Tricks

Here are a bunch of tips and tricks, things that I've found that I don't want to forget, but if I don't write them down I will forget, so I figured you'd find them helpful too.

Some of this stuff is Debian oriented, some of it is GenToo oriented, depending on what distribution I was using at the time. However some things are general to all distros.

Assumptions:

I assume, in these tips, that you know how to use a text editor, you know how to read man pages, and you know how to get around using the command-line interface (shell) and how to edit the setup files for your chosen shell. I also assume that you know how to install software on your chosen Linux distribution. If you don't, I'm afraid giving such tutorials is beyond the scope of this document.

Nifty Programs

You'd wonder why there would be nifty programs that I'd forget, but if you don't use them all the time, then you do, and then you kick yourself because you can't remember the name of whatever it was.

  • pgmcrater: generates an image full of random lunar-style craters (rather pristine and artificial craters, but it's a nice starting point)
  • ppmforge: generates "fractal forgeries" of planets, starry skies, and clouds. The clouds especially look very cool.

Annoyances

Nautilus

Nautilus is a file manager which also likes to take over the desktop thinking that it's MS-Windows. Which is fine if you like that sort of thing. Of course, one could just say, "well, don't use Nautilus, then" but, unfortunately, some programs are set up to launch Nautilus if it exists on the system at all, so one can suddenly find that, without so much as a by-your-leave, Nautilus has taken over your desktop.

One used to be able to turn this behaviour off, but the GNOME folks in all their wisdom, removed that option from the GUI.

This is very annoying.

However, it is still possible to disable the desktop takeover by using the command-line G-conf tool like so:

gconftool -t bool /apps/nautilus/preferences/show_desktop -s false

You may not have the exact same program, though: I had to use "gconftool-2" instead.

General Admin

Restarting Services

Before you decide to reboot the machine to see if your configuration change worked, check to see if the program in question has a file in /etc/init.d or /etc/rc* (depending on your system). These are the startup/shutdown scripts used by the system on reboot/shutdown. Generally called by the name of the program, they take one argument, either "start", "stop" or "restart". So if you want to restart the program as if the computer had rebooted, call the script (as root) with the "restart" argument. And if that doesn't work, then try calling it with "stop" and then call it with "start".

I know with some programs you can force them to re-read their config files by sending them an INT signal or some other signal, without having to stop and start them, but I just find it simpler to just restart them. No grovelling around trying to find the process-ID of the program, not to mention figuring out the right signal to send, not to mention that it might not be one of those interruptable processes anyway.

Devices

Before Installing Linux

I find it useful to write all my hardware information on a little file card (or a small notebook) before I install Linux on a new machine. Having the "vital statistics" of your machine handy, can be very helpful. You may not need any of it, but if you do, it's handy to have it available "just in case".

  • serial port 1 (COM1) memory address (and what is hanging off it)
  • serial port 2 (COM2) memory address
  • parallel port 1 (LPT1) memory address (and what is hanging off it)
  • the addresses and IRQ numbers of other ports (USB, SCSI etc)
  • type of sound card, memory address, IRQ
  • type of monitor
    • if a normal (CRT) monitor
      • Horizontal sync rate
      • Vertical sync rate
    • if an LCD monitor
      • resolution
  • type and version of video card, amount of on-board memory on it
  • amount of RAM you have
  • type of any other extra cards (such as ethernet)

The reason why it's good to know the IRQ is in case any of them conflict. The reason why it's good to know the memory address of a device is in case you have to tell that to the kernel in order for it to be able to find the device. Most of the time things are auto-detected, but if they aren't...

The sync rates of your monitor are good to know if you want to set up X-Windows in an advanced fashion. If you have an LCD monitor you'll want to know its resolution likewise.

Another thing is that you may need to check your BIOS and enable it to do its own plug-and-play PCI setting (in other words, disable anything in the BIOS which assumes that MS-Windows is going to be the operating system).

Also, write down the disk partitions (hda1 hda2 etc) and where you plan to mount them.

Disk Maintenance

If you normally leave your computer running all the time (as I do, so that it can go off and do cron jobs while I'm asleep) then if you plan to actually turn the machine off for more than a short time, you need to be careful, or you may kill your hard disk. This happened to me over Y2K -- I'd turned the machine off as advised by friends, and ended up killing one of my two hard disks. My friend the hardware guru who investigated (and finally replaced said disk) told me that for PCs which are normally on all the time, if you just stop them cold, then this is a Bad Thing, and what one is supposed to do is:

  • turn the machine off
  • wait 15 minutes
  • turn the machine on
  • turn the machine off

Don't ask me why this works, I'm not a hardware guru. Something to do with thermal stress, or disk heads sticking, or something.

Linux Filesystem on Zip Disk

If you have a IOMEGA Zip Drive (probably going the way of the dinosaurs now that CD-RW drives are so cheap...) then you know that the disks by default have a standard MS-Windows filesystem on them. However, if you don't think you'll be using a given disk on MS-Windows, but just on Linux, it would be nicer actually having a Linux filesystem on it (since then you can preserve all the usual permissions and soft links etc).

First, use fdisk:

fdisk /dev/sda

(obviously don't use /dev/sda if that isn't the device of your zip drive)

Remove any existing partitions, and make the whole thing a linux partition on /sda1 (note that by default, the Zip Disk has its MS-Windows filesystem on /sda4)

(Linux native (ext2) partitions are type 83)

Then format the partition.

mke2fs /dev/sda1

Moving the Root Partition

I found myself faced with this when my root partition ('/') and my /var partition were filling up, yet I had plenty of space on my general files partition ('/files'), and then discovered that I also had an empty partition I wasn't using (I think I'd put it there to use for experimental installs, but I decided I wasn't going to do that any more since I was using the machine as a server).

So, I had the space, but I couldn't use it.

First of all, I moved everything from /files to /files2 (which was an extra disk I had). That left me with two empty partitions, one quite big, and one not so big. I unmounted them both, and used gparted to redistribute the space between them. The gparted program is nice for manipulating unmounted partitions.

Unfortunately, I couldn't use that to move the contents of / and /var (I decided needed to combine them) into the new partition while I was using them to run with. Things like dd and partimage weren't that good for copying live systems, and were fussy about partition sizes. But if I booted from a liveCD (such as knoppix or an install CD) then they probably wouldn't have useful programs like gparted on them anyway. What to do?

Solution:

Reboot with my GenToo install disk (any sort of liveCD/rescue disk will do, provided you can get yourself a command line and that the CD has somewhere that you can use as a mount point).

My partitions were as follows:

/dev/hda3 was my old root /dev/hda5 was my old /var /dev/hda6 was where I was going to put my new root + var /dev/hda7 was a big empty partition (which was going to be my new /files)

They were all ext3 partitions, but that's just a detail.

The mount point in the GenToo install disk is /mnt/gentoo

So I did the following:

mount -t ext3 /dev/hda7 /mnt/gentoo

That gave me space to play with. Then I mounted the old root:

mkdir /mnt/gentoo/oldroot mount -t ext3 /dev/hda3 /mnt/gentoo/oldroot

Then I mounted the old /var where it should go in the old root:

mount -t ext3 /dev/hda5 /mnt/gentoo/oldroot/var

Then I mounted the new root:

mkdir /mnt/gentoo/newroot mount -t ext3 /dev/hda6 /mnt/gentoo/newroot

Then I did exactly what GenToo does for its installations: I made a tarball. cd /mnt/gentoo/oldroot tar czvf ../root.tar.gz .

and then untarred it in the new root:

cd /mnt/gentoo/newroot tar xzvpf ../root.tar.gz

This may not be possible if you don't have more space on the placeholder partition than you do on the original root + var. If that's the case, then you can do a tar through a pipe, which is more complicated, which I why I chose the simpler more space-consuming method.

The next step is to edit the /etc/fstab of the new root

vim /mnt/gentoo/newroot/etc/fstab

so that its root partition points to the new root "/dev/hda6" instead of the old one "/dev/hda3". And to remove or alter the old /dev/hda3 and /dev/hda5 entries.

And then I also had to edit the grub menu.lst information to add a new entry for the new root. I actually did that before I booted up with the liveCD. Having a separate /boot partition was helpful that way. The boot line in the grub menu is exactly the same as your original, except that you change the "root=/dev/hda3" to "root=/dev/hda6".

Reboot, pick the new entry, and you're rolling with root on a new partition!

Getting a HP 710C DeskJet to work with CUPS

I acually did get my printer to work for quite a long time without trouble, both under RedHat and Debian, using the pnm2ppa driver which I could just click on in the printtool printer configuration GUI tool. But for some unfathomable reason, my printer just stopped working, even when I changed around the printing system I was using. (CUPS stands for the Common Unix Printer System) (It worked in M$-Windows, but not in Linux.)

I found the following quite helpful: It's oriented towards GenToo Linux, but I ignored the GenToo-specific stuff -- for one thing, all the programs mentioned, I already had them installed -- but I did the other things, and it worked!

X-Windows

Handy Shortcut Keys

  • Ctrl-Alt-F1 gets you to the first virtual console (then Alt-F2 to F6 will get you to the other ones). Alt-F7 will get you back to the X-windows interface.
  • Ctrl-Alt-Backspace kills the X-server
  • Ctrl-Alt-Keypad+ changes the video mode

NOTE: if Ctrl-Alt-Fn doesn't work, see if you have "chvt" installed. This command will change to the given Virtual Terminal. Thus

chvt 1

will change to the first virtual console. Unfortunately... it looks as if, when one is in X (as distinct from actually being on one of the virtual consoles), this command only works when one calls it as root. 8-(

Changing the Title on your Xterm

This is a nifty trick, where you set your shell prompt to affect the title of your Xterm (or your rxvt or other compatible terminal program) so that it does things like show your current directory or whatever. The secret is to use escape sequences which Xterm (and compatibles) understand.

Icon Title = ]1; ^[]1;^G (use ^v in vi) \033]1;\007

Window Title = ]2;

It will depend on what shell you use as to how you set your shell prompt (usually the PS1 environment variable).

Multiple X-Windows Displays

You can actually have multiple X-Windows displays on your Linux box by having X displays like the virtual consoles.

First, create an MIT-MAGIC-COOKIE for your new display.

xauth add your.computer.name:1 `perl -e 'srand; print int(rand(99999999));'`

Then on another virtual console, run

startx -- :1

which will start another X diplay on Alt F8 (the original :0 display is on Alt F7). You need to check what startx does, to make sure that it starts the window manager you want. Gnome and KDE apparently get upset if there are multiple versions of them running.

If startx doesn't do what you want, copy it (it's a script) and alter it the way you want, and use the new script instead. Or can one set the Window Manager in startx by going something like

WINDOW_MANAGER=kde startx -- :1

(You may need to restart original X session of :0)

Of course, the problem with this is that it takes up a lot of memory to run two X-Windows displays at once, so you may find it slows things down too much for you.

Multiple Optional Mice

This is a handy trick when you have a laptop which has a built-in pointing device (like a touchpad) and you also have another pointing device (like a USB trackball in my case) and you want to be able to use both of them, and you want to be able to use either of them, without having to change your X settings and restart X every time you change your mind. This can be useful, say, if you're travelling and you don't have much surface, so you want to use the internal touchpad, without having X be all upset that your external mouse isnt' plugged in.

Note that I doubt that this will work if both mice are plugged in to the same device (for example, the internal touchpad is on the PS/2 port, and so is your mouse). However, if they are on different devices (eg your external mouse is on your serial port or a USB port) then this should work.

This requires grovvelling around in your /etc/X11/XF86Config-4 file.

Depending on your distribution, automatic hardware detection may or may not have detected both pointing devices. If they have both been detected, then there will be an entry for each one as an "InputDevice" which will have things like Identifier "Mouse1" Driver "mouse" Option "Device" "/dev/psaux" Option "Protocol" "ImPS/2" and so on.

If you don't have entries for both devices, you will need entries for both devices -- and figuring this out is beyond the scope of this document. However, generally speaking, the important bits to get right are the Device and the Protocol. And also make sure each one has a different Identifier! Usually, an internal pointer device on a laptop uses the PS/2 port, "/dev/psaux" and uses the plain PS/2 protocol

Option "Protocol" "PS/2"

If you have a Wheel Mouse, it usually uses the "ImPS/2" protocol.

With USB mice it's tricky, because the device used for a USB mouse varies depending on the version of Linux you're using. Some of them use "/dev/usbmouse" and others use "/dev/input/mice". That's where hardware autodetection comes in handy.

Okay, so let's assume you have your two InputDevice entries. Add the following to each one: Option "SendCoreEvents" "true"

This enables both mice to work at once. Well, almost. The next thing you have to do is go down to the "ServerLayout" section and make sure that both mice are there as input devices InputDevice "Mouse1" "CorePointer" InputDevice "Mouse2"

One of them needs to be the "CorePointer" -- make sure it's the one that's always there (eg the internal touchpad).

Then, in order to be able to function with only one of the two mice, add the following:

Section "ServerFlags" Option "AllowMouseOpenFail" "true" EndSection

That should do it.

Internet

Vital Statistics

I find it very helpful to write down the essential information about your ISP before trying to set up your connection. While there are nice automated tools around, you still have to give them the info first, so put it somewhere you won't lose it.

  • ISP dial-up phone
  • Primary DNS (IP address)
  • Secondary DNS
  • http proxy machine.name
  • mail server machine.name
  • news server machine.name

Some ISPs don't give you their DNS information, because they are assuming that your dialer will grab it, and certainly with the current version of wvdial, that is what happens.

SSH

Here are some nifty How-Tos for setting up the Secure SHell.

Website stuff

Updating/Uploading

If you have your website on your ISP or a web-host, it makes sense to create the website on your Linux PC and then copy it up to its final destination when you want to upload it.

There's a few ways to do this. The easiest way is to use rsync, to "sync" the directories containing your website. However if your ISP doesn't offer that, you may have to use ftp. That can be annoying if you have to copy each file by hand; the next best thing would be to use tar to make an archive of your site, just copy the tar file across, and then untar it. But you can probably only untar the file if you have shell (or ssh) access to your web-host.

Moving From RedHat to Debian

There are a few gotchas that might bite one in making the move, things that are missing or done differently.

Checking Packages

"dpkg -l (pattern)" will tell you what packages there are which match the pattern, and whether or not said package is installed.

"dpkg -L (package)" will list all the files in that package. This is very useful to know for two reasons:

  • finding where the documentation for the package is
  • finding where the default config file was installed

A file which can be useful to check, as far as documentation goes, is the "README.Debian" file, which often tells how the package has been customized for Debian, and how to use it. It can sometimes be useful to check the "changelog.Debian.gz" file too, if you want to know how this particular package has changed if you've just updated it.

Even more useful than "dpkg -l" is the "apt-cache" package, which you can use to search for packages you might want to install, and get the info on them.

Updating Packages

apt-get is your friend. A nice front-end to apt-get is aptitude. A nice X-Windows GUI front-end is synaptic.

rp3

I used to use the nifty rp3 GUI program, the RedHat dialler to do my PPP dialups. It isn't on Debian. However, I discovered that rp3 was just a front-end for the wvdial program (which is a command-line program). So I just used wvdial instead. One needs to be root to run it, though.

Printing

Debian has four different printing systems available to install: lpr, gnulpr, lprng and cups. It helps to check all the "suggested" and "reccommended" packages for these, because there may be something which you need for your particular setup, which is not installed by default. For me, for example, I found that the things needed to support my HP-710C printer were optional, so I had to install them myself before my printer worked.

GenToo-Specific

Updating Multiple machines

If you have a small LAN network, you don't want to download everything more than once.

First make an rsync mirror so that your emerge --sync will talk to your own server machine instead of the outside world: http://gentoo-wiki.com/HOWTO_Local_Rsync_Mirror

Second, make a proxy so that your distfiles will be mirrored without downloading them more than once; use http-replicator http://gentoo-wiki.com/HOWTO_Download_Cache_for_LAN-Http-Replicator

Debian-Specific

knoppix

This is a Debian-based distribution which runs off a CD. However, one can actually install it on one's hard drive if one so chooses. tells one how.

apt-get tips

After you have your apt-get set up to do basic stuff, you might want to investigate pinning, which is basically something which enables you to declare that you are following a particular branch (like "stable") but also add in the URLs for the other ones, so that one can use apt-get to download something from, say, unstable, without having to grab the package by hand and install it by hand.

Here are some articles:

One problem I ran into after I set this up, was that I got the following error:

Reading Package Lists... Error! E: Dynamic MMap ran out of room E: Dynamic MMap ran out of room E: Error occured while processing libcgi-fast-perl (NewVersion1) E: Problem with MergeList /var/lib/dpkg/status E: The package lists or status file could not be parsed or opened.

This happened because Debian is so big now, that once I started listing multiple sources, it couldn't cope with them all with its default settings for its Dynamic MMap (which stands for Dynamic Memory Map I think). The way this gets fixed is to add the APT::Cache-Limits parameter to your /etc/apt/apt.conf file, with a size greater than 6MB. The value has to be in bytes. Thus, when I changed mine to 12MB (I thought doubling it might be enough) I put in the following line:

APT::Cache-Limit 12582912;

(12582912 is 12 * 1024 * 1024) See "man apt.conf" for more details. (And "man apt-config" for a command to let you see what your current config is).

If you have a network of machines (even just two!) which are all using Debian, it may be worth looking at the apt-proxy package, where you have one machine set up as an apt "server", which is the one which actually downloads the packages, and the other machines point to that as the source of their apt-getting; this can save downloading things more than once.

Building a custom kernel

Most of the time you don't have to do this: the standard kernel packages are quite fine 95% of the time, and a lot less hassle. However, if you happen to have bought some hardware which has drivers that haven't (yet) made it into Debian, or has Debian drivers but there also exist drivers out there which have enhanced features that you want.

In my case I had to do it for both my laptop and my desktop; the former because my new USB wireless wlan gizmo only had support in the beta versions of the driver which weren't even in Unstable yet, and the latter because I had a wacom graphics tablet and the standard driver didn't support anything but Position. Both these required being able to compile their kernel modules against the kernel source of the kernel that was to be used -- which meant having the kernel source and building a kernel.

I know that there are some modules out there which can be compiled fine if you only have the kernel headers, but it's harder to get this to work, so I haven't bothered.

So, on Debian, one has nice things like kernel-source packages and the make-kpkg package, which help in compiling kernels. The bad news is that the kernel source comes set up with a generic config which is not the same as the config used for compiling the standard Debian kernel images. Which means that if you go with the vanilla config, ten to one, things will stop working, and you will only have a few clues as to why.

Which means that one is reduced to trial and error, many trials and much error.

Here are some tips as to negotiating the minefield.

  • While running your precompiled working kernel, make a copy of the output of "dmesg" and of "cat /proc/modules". You can then have these available to compare against your new kernel to see what modules or options you might have missed.
  • Use both the --revision and --append_to_version options of make-kpkg. I make the revision something like "custom03" where the number is the attempt-number. I make the --append_to_version have the machine name and the date, for example:

--append_to_version=-welkin.20040904

Note the dash before the machine name. This is because some module packages need to be able to parse the kernel version and not having a separator character like a dash messes up their parsing.

  • Save the .config file each time you have a different go, so that you can have something to roll back to if your latest version didn't work.
  • Don't remove your working precompiled kernel until you're really sure that everything is working perfectly. You're going to have to be rebooting into a working kernel while you're doing this trial and error stuff, so leave one around.
  • Don't be really sure that everything is working until you've checked everything. Generally speaking this means checking all your perhipherals and major tasks. (Note that not everyone would do all of these, as some don't apply)
    • look at a floppy disk
    • print something
    • play some music on your CD player
    • play some mp3/ogg files with your sound files player
    • watch a DVD on your DVD player
    • connect to the internet
      • turn on your firewall
      • surf the web
      • run "apt-get update"
      • get and send mail
      • get and send news
    • connect to your network
      • remotely log in to another machine
      • copy files to and fro
    • burn a CD
    • scan a picture
    • mount an external drive Naturally, you may not wish to do all of these at once, which is why it makes sense to keep around a working precompiled kernel anyway.
  • Don't turn off the "experimental" prompts, or you will lose all "experimental" settings. And, unfortunately, Debian uses experimental settings -- if for nothing else, for the nice vesa-framebuffer module, which allows one to have a nicer crisper console. You may also need "experimental" settings to support certain hardware. But unless you know it is okay (such as being used in Debian) generally don't turn on options that are labelled "experimental".
  • A tip for grub users: add the following lines to /etc/kernel-img.conf

postinst_hook=/sbin/update-grub postrm_hook=/sbin/update-grub

This will call the update-grub command whenever a kernel is installed or removed, so you won't have to do it yourself any more.

  • Choose whether or not you're going to try to compile a kernel with initrd or not. I couldn't get initrd to work properly, though the standard debian kernels do use initrd. The advantage of initrd is, I think, that one can compile more things as modules and still have things work. If one doesn't use initrd, then one has to make sure that certain vital things are compiled into the kernel itself, not as modules.
  • On chosing what to compile as modules:
    • if not using initrd, make sure that things to do with your monitor and the disk upon which your root filesystem resides, are in the kernel. For example, if your root filesystem is on an IDE disk (which is standard for PCs) then you need IDE disk support, but can put IDE CDROM support into a module -- that is, assuming that you aren't planning on putting this kernel onto a CDROM. You will also need ext2 filesystem support if your root filesystem is ext2, for example. And for the monitor, you'll need support for your video card, and if you're planning to use those nice small fonts from the vesa-framebuffer support, that will need to be compiled in.
    • otherwise, if in doubt, make it a module, if you might need it. If you definitely know you won't need it, then turn it off. Problem is, following the suggestions of the kernel source writers doesn't always help, because your standard Debian kernel images are set up with things that "most people" don't need, and you might need it even if "you've never heard of it".