Common Linux-isms that everyone can follow...

[Xayd]

It seems alot of people get stuck with things when trying Linux distros for the first time, so how about a list to categorize common things that will save people some time for the most common distros?

• Config files

These are fairly common amongst distros. You're looking for a folder named etc. In Linux it's gonna be at the root of your main partition (/etc). In FreeBSD it's gonna be under /usr/local (/usr/local/etc). EVERYTHING on your machine should have its config file under one of these directories, unless you specifically put it elsewhere. Read the configs and the comments, they are almost always commented with detailed instructions.

• Startup scripts

Services, for lack of a better word, are handled differently among distros but are still very similar. Most distros handle them in the etc folder as well, but the format may vary a bit, but you're looking for a folder named rc.*

This is where your startup and shutdown scripts are. If you want something done automagically when you startup or shutdown, this is where you put it. If your distro has a rc.local file you can safely put any and all simple startup commands in it at the bottom, rather than creating a new file, if you want. For Slackware and Slackware-type distros, they're all together in /etc/rc.d. Any file in Slackware that's marked executable (chmod +x) in the /etc/rc.d folder gets executed at boot. If you wanna stop it from being executed, simply take away its execute permissions (chmod -x). For FreeBSD, startup scripts are in /usr/local/etc/rc.d and controlled by a file in /etc called rc.conf. If you wanna have something run at boot in FreeBSD, simply put a command script in /usr/local/etc/rc.d (for instance foo.sh) and chmod +x it. Then open /etc/rc.conf and add at the end...

foo_enable="YES"

To disable it, simply edit rc.conf and change foo_enable="NO"

Some distros, such as Debian, separate these scripts a bit by runlevel, but it's still not complicated. In Debian for example you'll see under /etc the same rc.* directories, but they'll be categorized by numbers. The numbers refer to runlevels, which confuse some people but really aren't that complicated. There's a system in place for adding startup/shutdown scripts to make the process of adding and removing them easier in any Debian based distro. Simply make a script that you want to run in /etc/init.d, and use...

update-rc.d foo.sh

...and Debian will automatically populate the different directories specific to each runlevel with an appropriate script to handle your process or service or whatever you wanna call it. See update-rc.d manpage for more specific info on format and options.

There's also a third way to handle network-specific services, which every distro has, which is inetd This works in a similar fasion, but with a twist. inetd is one service, but any network service which is bound to a specific port you can call from inetd, and inetd will automatically start and stop it as connection requests come in. So for network servers you have this option for running them in addition to or instead of the standard practice of starting the service from rc.d and having it run persistently as long as the machine is on. If you simply edit the inetd.conf file in /etc in your preferred editor the format is very easy to understand, and there are instructions and samples within the config file.

• Debugging

When something doesn't work, there's only a few places where evidence of why will be found, this will solve 90% or more of the problems that you have with drivers and startup scripts.

Two commands...

tail /var/log/messages

and...

dmesg

Tail /var/log/messages does just what it implies. It shows you the tail end of the "messages" log, which will contain all system output not designated for any other specific log. If you're looking for some more info on something that has just recently failed to work, check here first, there's probably some output describing the error.

dmesg shows kernel output, so if a driver isn't working or something else the kernel itself was supposed to do failed to work, run this command and look for errors, it'll be in there somewhere. Then simply paste the error output into google and you'll find 3409834098 other people who had the same problem and probably fixed it already.

For logs related to applications, servers, etc. Those should all also be in /var/log unless a package or you put them somewhere else. If you get an internal server error page in apache while trying to run something, check /var/log/apache and look to see what the error log says, for instance. Error logs from stable version'd programs and servers are usually very specific, and if you know where the log is all you need to do is read it to find out what the problem is.

Here's an example...

root@tvbox:~# dmesg

(snip)
uhci.c: USB UHCI at I/O 0xb800, IRQ 5
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
uhci.c: b800: host controller halted. very bad

That's the output of a new kernel I compiled a few days ago with some extra options I wanted, specific to the usb drivers. A quick search for uhci.c host controller halted. very bad turns up tons of stuff on mailing list archives about that specific error. Voila, now I know how to fix it.

• Modules, drivers, etc.

Everything that's not compiled directly into your kernel, driver wise, will be loaded as a module. That is, a separate file which the kernel can load or unload as required for a device to function. Several commands you need to know...

lsmod

This command lists the modules that are currently loaded, just like ls lists the files in a directory, pretty straightforward.

rmmod

This command unloads a module just like the command rm would remove a file. Pretty self explanatory.

lspci

This command lists the devices attached to your PCI bus. If a PCI device isn't working, check lspci first, if the device doesn't show up here then it's not working at all. Every PCI card in your system should be listed when you run this command, as well as your USB controller, on-board sound/nic/video, and any other device on your mobo that works via the PCI bus, including AGP. Not only that, but it will give you a very specific hardware/revision/model ID on each piece of hardware that it finds on the PCI bus, so finding drivers with that information in hand should be infinitely easier.

modprobe

This command both lists and attempts to intelligently install, a module or driver, depending on what you tell it to do. Checking to see if a driver exists with this command is pretty easy, the -l command lists modules that you specify. For instance I've got a couple of 3com network cards in my box, to find 3com drivers...

root@tvbox:~# modprobe -l 3c*

/lib/modules/2.4.26/kernel/drivers/net/3c90x.o
/lib/modules/2.4.26/kernel/drivers/net/3c59x.o
/lib/modules/2.4.26/kernel/drivers/net/3c515.o
/lib/modules/2.4.26/kernel/drivers/net/3c509.o
/lib/modules/2.4.26/kernel/drivers/net/3c507.o
/lib/modules/2.4.26/kernel/drivers/net/3c505.o
/lib/modules/2.4.26/kernel/drivers/net/3c503.o
/lib/modules/2.4.26/kernel/drivers/net/3c501.o
/lib/modules/2.4.26/kernel/drivers/net/pcmcia/3c589_cs.o
/lib/modules/2.4.26/kernel/drivers/net/pcmcia/3c574_cs.o
/lib/modules/2.4.26/kernel/drivers/net/tokenring/3c359.o
/lib/modules/2.4.26/pcmcia/3c589_cs.o
/lib/modules/2.4.26/pcmcia/3c574_cs.o

Those are all modules available which are named 3c(something), or, all of the 3com drivers that I have available. By looking at the path to where the module itself is, you can pretty well determine what it does. pcmcia are obviously modules for pcmcia 3com network cards, tokenring is for anyone running an anicent enough system to still have tokenring networks, etc.

modprobe -l

...without an argument will list ALL modules on your system. This will probably be far too long to scroll through, so you can output it to a file if you for some reason need a listing of every driver and module that's available to you. To do that...

modprobe -l > drivers.txt

There's also a command to force the insertion of a module that doesn't have parameters which modprobe can use to automatically load it, that being...

insmod

Pretty straightforward there too, insmod inserts a module. insmod 3c59x would force the kernel to load the 3COM 59x nic driver, for instance.

How the kernel determines which modules to load and unload varies by distro and how you have it set up, but it's usually gonna be one of a couple of different ways. Many more recent distros use a program called hotplug to detect hardware and load modules automatically, which is configured by the files in /etc/hotplug. If hotplug is trying to load a module that you know you don't need you can add it to the blacklist file in hotplug's config directory.

All distros also have a system in place for passing options to modules that get loaded, and most are in a file named something to do with modules in /etc. In the vast majority of distros, this file will be /etc/modules.conf

Some systems also have an rc file in the startup scripts that list each and every module that the system can load. In Slackware this file is /etc/rc.d/rc.modules. If you wanna stop a module from loading, simply comment it out in the file. If you wanna add another module to be loaded automatically, add...

/sbin/modprobe (module-name)

...to the end of this file, and the system will attempt to load it each time the system starts.

So to summarize, modules.conf is for module settings, rc.modules (or your system's specific module startup script) and/or hotplug are for loading the modules themselves.

• devfs, device nodes, etc.

This is potentially complicated, but to keep it short, here's where you'll find devices that are working on your system, in /dev.

Dealing with major/minor numbers and the advantages/disadvantages of devfs and old-style device nodes is beyond the scope of a single forum post, but basically what you need to know is if it's a hardware device, it'll have an entry in /dev somewhere. /dev is also the location of your drives, so if you need to unmount/remount CD/DVD drives or extra hard drives or any other such device, /dev is where it's gonna be.

You can also cat input devices in /dev to ensure that they're working, which is somewhat useful. For instance...

cat /dev/mouse

...tells the shell to send all output from the /dev/mouse device to the console. So moving your mouse around with that running should output jibberish to your screen. If it didn't, there's no mouse there or the mouse isn't working. You can do the same with sound devices, video devices, etc. ctrl-c to quit (this command is universal, ctrl-c is always the "escape" keyboard command).

• Paths

Unix/Linux distros have path variables just like Windows does. Executing a file or program without typing the full path is no different. Just like everything in Windows is under WINNT\System or WINDOWS\System, everything in Unix/Linux that's executable with a single command will be in /usr/bin or /usr/local/bin, at least for the programs and such that you have installed. If you wanna make a new command, simply make a script in /usr/local/bin or /usr/bin and chmod +x it, and it'll then be a command that you can run.

• Running processes

Also not very different from Windows.

ps aux

...will list every process you have running, and which user is running it. If you wanna kill a command...

killall fooserver

...will kill all instances of the process 'fooserver'. You can also kill processes by process ID, userid, and other such variables as welll, check the manpage for killall for more info.

The above covers basically everything you need to know to get anything to work. You know where the error logs are, you know where the startup scripts are, you know where the device nodes are, you know where the programs are, you know where the modules are and how to find which modules/drivers you need, and you know how to check and see if something is running and if necessary kill/restart it. If you can navigate and edit by command line you should be good to go with the above info. Anything else google knows.

[neouser99]

wow, very nice...how long did that take you

props to this, might be considered for a sticky, as it has many major points to debugging all in one place.

-neo

[Xayd]

Not terribly long, an hour or so I suppose .

Once you know where to look for things, the rest is trivial, really. If you know what to look for, google can answer the questions all you gotta do is type in the solutions. Give that a few weeks and you'll know enough to run things on your own.

It's not rocket science.

[neouser99]

oh but it is...wait...you mean to tell me there are no more .dll's????

I don't have to restart my computer every time i install something...!?!?!

no way, i don't believe it.

-neo

[nocturnx]

nice guide xayd.

I will definatley be refering to this alot. I wish mandrake used rpm's, I have yet figured out how to install cat drivers for my 9800 pro.