The printer is a HP Photosmart C5280
The URL for the driver is: http://hplip.sourceforge.net/downloads.html

From grep I get:
From dmesg (just the USB parts):
I noticed during reboot a message flash past to the effect that CUPS was initialising on parallel port lp0.
Does that signify that CUPS needs reconfiguring to read from USB and if so how do I do that?

The key thing being that one is, in fact, setting their system up correctly. Consider the usual way building a kernel goes; generally something like:
You build the kernel image package and the kernel headers package at the same time. Those two are the ones that have to match. If you're doing kernel (non-userland) development. That's what seems to throw a lot of people.

The thing of it is, a substantial number of things - macros, API calls, and so on - changed between the 2.6.18 kernels and the 2.6.2x kernels. So, if you're using the headers only, and not the full kernel source, to build an out-of-tree module: and a number of modules have started using that approach, it saves an enormous amount of disk space: say, for example, you're building the ATI fglrx driver; that's one example of an out-of-tree kernel module that's adopted this approach - as you're using the kernel headers from the wrong version of the OS, while the driver may build, God only knows what it's going to do when you load it.
While you're correct in your assertion that one could screw up their system by forcing an install of the wrong kernel, there are a number of different ways to end up with a mismatch.

The long and short of it is this: one should use the kernel headers for kernel development, and the headers that came with the glibc you're using for userland / user-space development. A lot of the files have the same names, and the include directory has pretty much the same layout, but the two sets of headers are for completely different purposes. A quote from an email from Linus was referred to earlier; if you read down through it a little more, you'll find a statement from Linus to the effect that:
That's pretty much it. You don't need to update the header files you're using to compile purely user-space apps when you change kernels. However, you absolutely need to use the headers that match the kernel you're running when you're building modules for that kernel.

Hope that helps clear things up some; for what it's worth, until it was explained to me, I was confused as all get-out by it.

- L

My favorite is this one: http://technowizah.com/2005/12/debia...l-compile.html

Thanks for the links guys.
@ Telemachos: I don't understand the following statement which came from a Linux Forums post referred to in your linked item:
How would you know if the file was OK and the modules in the right order? What would be likely to happen if it was wrong? This is a new one to me. Perhaps someone has an explanation?

That statement was in response to someone who was having a very specific problem involving one driver and a specific kernel not compiling. I don't honestly think it's anything you need to worry about. My own knowledge of /etc/modules is pretty limited, but in my experience you very very rarely need to mess with it on current Debian systems. I know that it used to be a bigger deal to make sure all necessary modules were properly loaded, and in that case I can imagine that order might matter (if b depends on a, then a needs to be loaded first), but this seems very well automated at present. Someone else may know better, but I would say don't worry about it.

I've found that one to be very good, too; another good one (in my opinion) is http://www.howtoforge.com/kernel_com...on_debian_etch.

If, assuming that you're using an initial RAM disk when booting, your system makes it all the way through the boot process - particularly past the point where control passes from the script running in your initrd to init on your actual root partition - then your /etc/modules is correct (or, at least, it's "correct enough").
The system will hang at the point that the script in your initrd (linuxrc) tries to mount your real root filesystem and pass control to init.

Assuming that your root filesystem isn't on a device that's "unusual", you're probably fine; halfway modern versions of initrd-tools / mkinitrd are pretty good at guessing what modules need to be incorporated into the RAM disk. For example, I haven't needed to make any changes to /etc/modules in order to use a /root that's on a SATA drive.

Odering is important in that file when you have a module that depends on other modules; you need to load the modules upon which a module depends before you can successfully load that module. Try typing "lsmod" at a command prompt; the module(s) listed under "used by" on the right are dependent upon the module who's name appears all the way to the left.