Umm... Well, I believe that you known that Slackware have an tool to easy make INITRDs... It's called mkinitrd.

So, if we assume that your kernel is 3.8.8-smp, your root partition is an ext4 on /dev/sda2 and your swap partition is on /dev/sda3, then, like I said, an example of generation of an correct initrd is executing:

Voila! :)

Then, you have just to add it to your /etc/lilo.conf.

Just remember when you have two ways to do a task, A and B, it is not always the case that everyone agrees on which is the easier. For example, if the task involved some programming, and A used the C language and B used the Python language, C programmers might find A to be easier and Python programmers might find B to be easier. For me, init scripts are easier because ... I've gone through the process of writing working (and still working on two of my machines) the entire suite of init scripts from scratch (and it's neither BSD nor SYSV style).

But I'll try mkinitrd.

Sure, we'll agree there. BUT, we talk about the (orthodox) Slackware-current, there, right? And I suggested to use just the official method to create INITRDs on Slackware. :)

There you make me curious... And I have to ask something: we talk about a machine which use the Slackware standard init scripts and not running something written in Python, Perl or Make files, right? :)

I wrote my own init script system from scratch ten years ago. I literally started from scratch as in started emacs with empty files and started coding. By the end of the day I had something that would boot up and run. It did have a lot of noisy error messages. But it RAN! It took a few more days to get the bugs and bad messages cleaned up. Eventually I had ALL of my machines using it. Today, 2 machines remain using it. I lost interest in keeping it up to date. But I do plan to re-do something to put together a system that is udev-free.

The design of my init scripts used a scheme where the directory /etc/sys contained a list of script files named with a hybrid sequence number and run level scheme:
There are no symlinks like SYSV has. The run levels for the scripts are handled by renaming them to have the desired run levels in the middle part of the name. If the run level digit is there anywhere between the first and second dot, it will be active for that run level (but will not be run at all if the run level change does not involve a change of what is being run ... so going from 2 to 3 will run the cron script in start mode, but not run the dns script at all).

I find this scheme easier because it's all in one place, and you can see how it is configured with "ls -l". Scripts being started are run in forward order. Scripts being stopped are run in reverse order.

So ... there you have the gist of it. There are some core scripts as well. They were all written from scratch. Soon, these machines will be decomissioned (one will get Slackware 14.1). It's unlikely I will run this scheme again, unless it proves valuable in making a udev-free system. But I do always end up hacking init scripts. And this is one reason I like Slackware is it plays well with people changing stuff.

edit:

Note that host "tesla" and the one next to it "faraday" running this init system have been solid and stable for years ... and have no trouble accepting hot-plugged hard drives on USB or SATA despite there being no udev on either of them. I could understand some people might want what udev does as their tool for exacting control over everything that happens. But that comes at the price of people like me just wanting it to default to the old behavior until explicitly configured otherwise.

It will be a little while before I test mkinitrd. I put 14.0 on in place of -current to test that (it hangs in udev). I need to put -current back on. But I have decided to do a full erase of everything except the /dev/sda9 -> /home partition, then re-install -current. Maybe get to that later tonight.

Are you sure -smp is right?
edit:

I think 64-bit only has SMP (ever heard of a one core 64 bit CPU?), and does not have "-smp" designation.

So I tried it without the "-smp" ...
Turns out the default install was running the huge kernel. I had believed it was not doing so previously but I'm not sure. Anyway, when I run the generic kernel with the initrd, it panics and gives a traceback. With the huge kernel it is fine. It the initrd that specific?

It seems to have no effect. The mouse still does not work. The xhci* modules are not loaded. The following from dmesg suggests something wrong:
FYI, I reconfigured /etc/lilo.conf to have 4 different boot choices.

I went ahead and did the module loading in a script. It seems the "huge" kernel already has SOME of the modules in it. So ordered loading is screwed. And the "generic" kernel is bad in some way and panics before it ever gets to userland/init. I don't know why. Of course this is working with -current which has its ups and downs as the next version is coming together.

So maybe I have to fall way back to kernel building?

edit:

Here's what the two kernels have configured:

So that goes along with your urging to use generic. But generic panics.

Having just done it, I'll make suggestions on your kernel below.

Do you want to solve your problem? What's your ~#@$&! chipset? Post the output of lspci, and let people know what you're trying to set up.

For a kernel, boot the huge kernel, remove the config, switch everything you use on and connect it, and run

make localmodconfig

THEN go through that config. I had to find and add modules for webcam, card reader (under some 'staging drivers' heading) and printer as well. some things that are compiled in you won't need, but it speeds thing up mightily. I would label it 3.8.8-1 - there's a spot for a suffix in the general setup. Just make it -1. Next one becomes -2, etc. Also be aware that the slackware kernel has an intel kms driver as part of it, while the stock kernel does not. If you are using the linus kernel, go figure that first.

See message #10 for motherboard and chipset.

See message #1 for link to lots of info including lspci (it was too much to embed in the initial question).

It looks like I was booting the huge kernel all along. It looks like the huge kernel is causing drivers to be initialized out of order because that kernel has some, but not all, of the drivers you suggested loading in a particular order. So the problem of out of order initialization is inherint in the huge kernel itself.

I tried the generic kernel, but it has another panic issue somewhere.

It looks like my next step is one of these:
1. Get the panic problem of the generic kernel fixed
2. Put all the drivers mentioned in the huge kernel (maybe it will init in the right order that way)
3. Take all the drivers mentioned out of the huge kernel (so that can be loaded as modules in order)
4. Put together a custom kernel in some way.

Which config should I remove? The one in /boot or elsewhere? Where should the "make localmodconfig" be done? Is there a special Slackware place for that, or do I just do it in the kernel source tree?

And it is still unclear if you are wanting me to do things statically in the kernel or as modules.

What all I can do is still rather limited and slow until I get it working right. Other USB things work sometimes, but sometimes not, so I have to use my SATA attached CF card slot to run my rescue device, instead of USB.

At this point I'm looking at Alien's guide to building a kernel and making a new custom one. That or just test cross-fitting the Xubuntu kernel and module set just to see what it does.

Intel C602 Sandy Bridge chipset. I'm not familiar at all with it, but others will be. Intel's hardware is usually straight down the line.

In your option list, I would do 1. or 4., not 2, or 3. 2 or 3 might be a faster route, but they might never sort it.

Your problem with the generic kernel is simply that you haven't made an initrd to suit. You need modules for filesystem(ext4 or whatever), motherboard chipset, usb [x|e|u]hci_hcd, and anything else you need to get onto the root filesystem. The initrd is mounted on / and the kernel grabs modules from there until your root partition is mounted over it on / and the module tree becomes available.

A problem with the huge kernel is that ohci (which you don't want) is compiled in, whereas uhci is just a module. You get a kernel source (FYI, the slackware 3.8.8 kernel source in current has the intel graphics driver added) cd to top source, and work from there. A good start would be
Then go through it. You won't have 500 webcam modules of which yours is one. You are inclined to have the right module.

As for the lspci, there is a Nvidia card in there as well. the kernel offers some laptop gpu switching option at this stage so maybe we're catching up.

It's very new. Has more USB via 2 controllers. Has PS/2 but I don't know if it's the chipset that is limiting things to one PS/2 port. It has quad channel memory paths (better than triple channel).

I would have hoped the USB driver author(s) would know what they are doing and have it work right if all of the needed drivers are built in statically.

The generic kernel panics before userland. The initrd is userland. It never gets there to have any chance to load modules. I've installed SYSLINUX boot loader, now, and can set this to go to 48 line mode and maybe I'll be able to see the cause of the panic.

My previous Slackware systems don't need or have an initrd and their USB works (there's no XHCI involved, though). I did not pay attention to whether they are statically built in or loaded as modules, but USB does work. I do know how initrd fundamentally works, as well as loading modules. But I have not needed initrd on Slackware before because the basics have always been there in generic and huge ... enough to get to the point where modules fill in the rest.

So does this mean my USB 1.1 devices won't work?

Wikipedia says XHCI supports ALL device speeds. So I guess 1.1 won't be a problem if we can get it to work. So in theory XHCI is all that I need. But the other drivers like OHCI are interfering?

My graphics is working fine so far. The nouveau driver loaded, switch the text screen to frame buffer mode, and Slackware loaded some fonts that gave a 240x75 text display in 1920x1200 pixels. The installer did a larger font that actually looked nice (I'll figure out which it is later).

I don't have a webcam so I won't need this.

I'm plugged into 1 of 2 ports of that NVIDIA card and all looks well in the display department so far.

Actually, OHCI is also a module in the -current huge kernel for a couple of kernel versions now.

Right now (before I have compiled a kernel) I have this:
I believe I definitely need to get UHCI and OHCI out of it, and possibly also EHCI. XHCI is supposed to be able to handle all the speeds in one, whereas the others only handled their respective speeds only. The BIOS on this motherboard does have an option to enabled or disable "EHCI handoff" (whatever that really is). I've tried with that enabled and disabled and so far it seems to have no effect either way. It may have an effect when the only drivers are EHCI and XHCI. But my first goal will be to omit all 3 of UHCI, OHCI, EHCI and just go with XHCI alone.

If that works, it could complicate how to set up kernels. On hosts without XHCI, which run from USB storage devices, a kernel without EHCI could not get to the root device. It would have to be there for all those systems older than a few months or so. I still need to see if that causes problems and if it does, if the BIOS setting above can get around it.

So it looks like I'll go build a couple kernels based on the huge kernel config, tweaked to have in one case just XHCI alone, and in the other have XHCI and EHCI combined, and blacklist OHCI and UHCI for testing them.

I spent today switching to the EXTLINUX boot loader and did not work on the USB issues.

To prevent modules loading you can
1. put them in /etc/modprobe.d/blacklist

They still just might load, so you can also have some usb.conf in /etc/modprobe.d with lines like

The 'install command offers an alternative action when the command to load that module comes along.

Using those two, you should be able to experiment with all the modules one by one.