To be fair, most of the software in 13.1 is working pretty well without fault. Certainly I’m not aware of any specific complaints with the latest KDE SC, but the kernel is another matter. The 2.6.33.4 kernel has some major problems. There’s a bug between the versions of LVM and DRBD that causes massive data corruption. There’s a bug in LVM startup scanning that stops some LVM devices from being properly configured. There’s new ACPI bugs. All of these being major problems for production systems.

In practice this means that all my production stuff is halted at Slackware 13.0 which is pretty rock-solid. I really truly hope that Pat is planning to run a 13.2 in a few months and more than that I hope he doesn’t bow to any pressure to release anything prematurely. To give an indication of what I mean, it took just two weeks for Slackware 13.1 beta1 to go through rc1 and rc2 all the way to full release and in the melee it appears Pat forgot to update the README files in usb-and-pxe-installers.

Also, to clarify my concerns about the kernel, there are a number of features in 2.6.33 that people have been asking for but it is brand-spanking new and will only be supported for 6 months or so. Pat missed a golden opportunity to release 13.1 with the 2.6.32 kernel which is very stable and well tested and will be supported for between 2 and 3 years because it has been designated for long term support.

Could the people who really wanted a 2.6.33 kernel not have upgraded to it on their own without taking the whole stable Slackware release with them?

I can only hope for my own sake that 2.6.34 (or at least 35 or 36) proves itself rock solid so that I will be able to upgrade the servers that matter but still have a kernel I can trust.

/etc/modprobe.d/nouveau.conf

UPDATE: 20100428
A package has been added to slackware-current to do this for you:
x/xf86-video-nouveau-blacklist-noarch-1.txz

They have been submitted to SlackBuilds.Org and are available there. They have been updated for proper Slackware64 compatibility and include notes regarding DRBD entering the Linux Kernel as of kernel 2.6.33.

TAKE NOTE:
Slackware{,64}-current has moved to kernel 2.6.33. DRBD’s kernel code is now part of the Linux kernel. You should not attempt to install drbd-kernel on a system with a 2.6.33 or later kernel. While it is technically possible, version 8.3.7 will not compile externally against 2.6.33. A fix is pending for the next release of DRBD but is nonetheless not required.

Users of Slackware{,64}-13.0 and earlier should use both packages.

DRBD v8.3.7 Kernel Module SlackBuild
DRBD v8.3.7 Userland Tools SlackBuild

I’ve just finished completely eviscerating a powerful server that was running Windows 2003 R2.

It’s now running Slackware64-current and very very beautifully so:

Kernel: 2.6.32.7
Kernel Image Size: 2299 KB
Module Tree Size: 33936 KB

CPU: Intel(R) Xeon(R) CPU E5345 @ 2.33GHz

Total RAM Available: 4054384KB
Total RAM Used (+/- b/c): 42240 KB

/dev/sda: 6x SAS disks
MegaRAID hardware controller
4 disk in RAID10.
2 global hot spares.

hdparm -tT /dev/sda:
/dev/sda:
Timing cached reads: 8206 MB in 2.00 seconds = 4106.44 MB/sec
Timing buffered disk reads: 552 MB in 3.01 seconds = 183.66 MB/sec

It’s name according to the Simpsons naming scheme?

Wolfcastle

WAIT!

Try the Magic SysRq key. All the Slackware default kernel have it compiled-in.

It’s not easy finger-wise, but hold down Alt and the SysRq key and while doing so, type in the following in order:

R E I S U B

Fingers crossed you just rebooted your machine without breaking it.

For more information:
http://en.wikipedia.org/wiki/Magic_SysRq_key

I should make it clear straight away that by no means do I consider the kernel an easy topic for most people to deal with, nor do I think I have a full grasp on every nuance myself; but I do think that the best thing you can ever do for your system is to build your own. Needless to say there are already a million billion kernel compilation guides out there, but they all make such a big deal out of what is an unbelievably simple process, especially in Slackware.

So.. give me five minutes of your time and I will show you the process I follow for each and every Slackware box I administer that gives me a generic kernel, no initrd, and endless options for customisation should I choose to take them. It’s simple, trust me.


Compiling your own kernel in Slackware Linux in 10 easy steps…

I’m currently managing in excess of 15 completely different Slackware installs across lots of different hardware and not one of them is running a “huge” kernel, or an initrd. If a module is absolutely essential to your system’s ability to boot, why in hell haven’t you compiled it into your kernel? It’s like having a your starter-motor in your car disconnected from the battery, but having a relay on its own mini-battery connect it up when you turn the ignition.. why would you do it? What’s the point? The car will not start without it, why is it not hard wired into the system? It’s the same for the kernel. If the system won’t start without it, compile it into the kernel. Don’t play about with an injection system you don’t even need.

Ok, so your root device is inside RAID & LVM on a GPT partition. So, compile in mdadm support for your RAID level, LVM support and GPT partition support; job done.

For the less experienced, it’s also a good way to learn the basics of kernel compilation without needing to do much more than follow a standard process. All you need to do is use the config from the generic kernel you were going to boot anyway, and knowledge of what filesystem your root device is installed with and what storage controller your disk uses. Go into the kernel config, add them in [*], make, make modules_install, move and symlink the new kernel, update lilo, reboot. Once you’ve done it twice, it becomes so routine and easy you’ll wonder why you haven’t been doing it forever.

Then, once you’re more familiar with the process, you can start removing other parts of the kernel you don’t need, especially hardware controllers for hardware you don’t have, with each step making your kernel smaller and your system leaner and faster.

Have kernel, will compile.

Post followed-up by:
Compiling your own Slackware kernel