I track incremental longterm patches, usually -2 from mainline, eg, 4.9, unless there are new hardware/features requiring a stable.

* Its relatively easy to automate sanity checking with 'patch --dry-run'.
* The naming scheme is modified from traditional to better support a incremental patch stream, eg, '/usr/src/linux -> linux-4.9' rather than '/usr/src/linux -> linux-4.9.34', and patches are saved in case they need to be reversed.

No initrd, all unused industrial subtrees are pruned.

Cheers,

In general I use generic. In fact huge is permanently blacklisted in my blacklist file. Actually kernel-... is always blacklisted unless I want to install a new kernel which I use slackpkg to download it and install it manually. I always have two kernels installed the latest and the previous (as a fail safe working kernel).

Why do I use generic? No particular reason other than it's recommend. From CHANGES_AND_HINTS.TXT "Use one of the provided generic kernels for daily use." I create a mkinitrd.conf for each machine to simplify running mkinitrd.

I haven't had my second cup of coffee yet and noticed after voting that it was multiple choice.

I use huge in my virtual machines as these are normally for test or compile purposes and are frequently redone. Plus I be lazy and see no point in going through the extra steps to use generic in this case. I cannot remember the last time I compiled a kernel. I typically only compile a kernel on a as needed basis.

I'm wondering what the 2 people who voted 'other' are running.. HURD?

I used to follow the longterm branches, but I came to the conclusion that in practice they're no more stable than the current stable branch, so now I'll only consider a longterm branch if I run into an issue and need to take a fallback position in order to avoid it.

I use git to keep uptodate rather than use the patch files.

I only use zipslack so I voted for other.

^This. Also, I do have some patches applied to the kernel source for no other reason than that I can. Whether there's any real run-time benefit is purely subjective, but I feel better for knowing that the patches are working their intended function. Also, I have a custom lsmod.txt file to run with 'make localmodconfig', so that only the modules I actually use are compiled; I (or rather, my processor) doesn't have to spend time compiling modules it will never use.

I use the real-time kernel patch and the Slackware generic config file.

I use a slightly modified generic kernel. No initrd.

One example might be FreeSlack, which provides the Linux-libre kernel.

Huge. It works.

HUGE

though in old days used to download kernels weekly or daily and build them. kernel tools havent gotten better.
tried building kernel lately got all sorts of errors.

I threw it in the option in case there was another source of precompiled kernels out there, an alternative-standard. People who used them wouldn't be building their own custom kernels, but neither would they be "generic" or "huge".

I compile a custom kernel of the same version (from kernel.org) as the slackware release kernel (or the lastest patch version) on slackware64 14.2. I use a .config that is based on the generic kernel's config (using make oldconfig). But, I disable almost all device drivers for hardware that I do not have and for other features that I do not plan to use. By custom compiling the kernel, I can choose to build into the kernel the modules for important boot-time hardware such as hard disk and network interface controllers, and drivers for mdraid/luks/lvm. I can choose to compile as modules the drivers for certain other hardwares that are not required for booting and which seem to work better as modules, such as ALSA sound modules and modules for hardware sensors. I also use an initrd because I use an lvm/luks/mdraid6 root disk, which has been working for many years without any problems, and now using the default /init script that is included by mkinitrd. Kernel compile time is less when most of the drivers for other hardware are disabled in config.

Maybe many users do not use a custom kernel, because maybe it seems like a complicated process to compile and install/upgrade a custom kernel. But, the process is something like this:

*) download new kernel source from kernel.org
*) cd /usr/src; tar xvf linux-xxxx.tgz
*) chown -R root:root linux-xxxx
*) cd /usr/src/linux-xxxx;
*) cp -a ../linux-yyyy/.config #(copy old config in)
*) make oldconfig; make -j8 bzImage; make -j8 modules
*) cp -a arch/x86/boot/bzImage /boot/vmlinuz-xxxx
*) cp -a System.map /boot/System.map-xxxx
*) make modules_install
*) cd /lib/modules; rm -r yyyy #(rm old modules of kernels you don't use)
*) cd /boot; rm System.map; ln -s System.map-xxxx System.map
*) rm System.map-yyyy #(rm any old System.map files you don't use)
*) rm vmlinuz-yyyy #(rm any old kernel images you don't use)
*) mkinitrd -F -c -k xxxx -s /boot/initrd-tree-xxxx -o /boot/initrd.gz-xxxx
*) rm -r initrd-tree-yyyy; rm initrd.gz-yyyy #(rm old initrds you won't use)
*) cd /etc; vi lilo.conf #(edit to boot the kernels/initrds you will use)
(always keep a boot entry for the old/previous kernel that you know works)
(don't rm your previous working boot kernel files, but maybe older ones)
*) lilo #(run lilo to write the boot sector)

I use the nvidia driver from NVIDIA.com. I disable in the kernel nearly all modules related to video devices and boot into a plain text console. Before rebooting onto the newly-installed kernel vmlinuz-xxxx, I run the nvidia installer with option --uninstall to uninstall it. I reboot like this

*) sync #(just to be really sure everything is written to disks)
*) reboot

Then, after rebooting onto the new kernel, I re-run the nvidia installer. The files /usr/lib{64}/libEGL.la have to be restored (cp -a) after installing the nvidia driver because, for some reason, it removes them to a backup location.

My root disk configuration is a complicated lvm/luks/mdraid6 disk, but it is a supported root disk configuration in slackware, and upgrading the custom kernel goes smoothly since it does not involve any special settings (per upgrade) about the disk configuration. The /init inside of the initrd, included by mkinitrd, is able to load the supported root disk configuration as / (root) just fine "out of the box" for me. For mkinitrd to work smoothly, you should first have the correctly configured files /etc/mdadm.conf and /etc/mkinitrd.conf so that mkinitrd understands your root disk configuration, to be able to mount it as / and then init the Slackware Linux system on it.

Overall, it is not really that difficult to use a custom-compiled kernel, but it could seem complicated or scary to try at first.

2 members found this post helpful.

Generic - It's what I'm used to.

I just got through building 4.11.8, encountered no errors. What are you encountering, that you say 'kernel tools haven't gotten better?'. Please elucidate. As far as I know, the only 'kernel tool' you need is GCC, and that works just fine here. Thanks!