-   Slackware (
-   -   Kernel Patches for Live DVD? (

ordealbyfire83 08-22-2019 07:52 PM

Kernel Patches for Live DVD?
First please let me confess that I do not currently run Slackware on my main machine, but I do use two Slackware Live DVD's from time to time for testing and other purposes.

Currently I am trying to build a kernel for my BLFS system using the kernel version and config file found on Alien Bob's 20180909 version. I would like to know whether the 4.14.68 kernel on this DVD has been patched as I'm noticing a couple of differences in behavior between how this kernel acts from the DVD and how it does when I build the source myself.

For example, the Slackware kernel seems to obey "elevator=" but when built from source and unmodified config file it does not. etc.

Any thoughts?

upnort 08-22-2019 09:49 PM

I'm no kernel guru but the stock Slackware Current kernel config shows the following:


Perhaps compare the kernel configs.

Alien Bob 08-23-2019 08:55 AM


Originally Posted by ordealbyfire83 (Post 6028421)
... using the kernel version and config file found on Alien Bob's 20180909 version. I would like to know whether the 4.14.68 kernel on this DVD has been patched...

The Slackware Live ISOs all use stock Slackware kernels. No Slackware package gets (re-)built when generating such an ISO image. It's all integrated using a ready Slackware package tree downloaded from an Internet mirror.

ordealbyfire83 08-23-2019 04:09 PM

Thank you both for that information. I'd much rather not be poking around with these I/O schedulers - but if there are no patches then something in the kernel isn't acting as it should.

After reading this it looks like newer kernels first check if a device (or a device plus whatever motherboard circuitry?) supports multi-queue. Unless multi-queue is specifically enabled, then it falls back to NOOP and ignores whatever elevator= specified. So even setting a default scheduler in the config isn't likely to work nowadays. This is unreasonable, because if we do not use multi-queue then we should be able to specify another scheduler. (Reverting this patch didn't help either.)

In my situation I am booting from a LUKS partition on a SSD. Using NOOP causes hangs after doing anything I/O intensive. Deadline gives me the best results, but then again, I can only hibernate / resume daily for 2-3 weeks before it hangs. I preferred elevator=deadline because this gives all devices the same scheduler. Copying large files from one device on NOOP to another on deadline or cfq never seems to end well, and I've even had files utterly vanish.

My conclusion about the Slackware kernel may have been premature. If I unpack the initrd, add a line to print out the scheduler, I do indeed see deadline, but then when I query this from the OS after it is booted, I get NOOP.

bassmadrigal 09-05-2019 12:52 AM

From some previous testing on a thread in this forum, it was determined that any elevator set in the kernel could be overridden with settings in udev. In fact, eudev does have a rule that will set any non-rotational devices (SSDs, NVMe, and maybe USB thumbdrives) to the noop elevator. This eudev rule will override any kernel or bootloader settings for default elevators for non-rotational devices.

If you want it set to your own elevator, you can do it by creating a rule to override the default eudev rule. In my example below, I named it 55-ssd-schedular.rules, and it is placed in /etc/udev/rules.d/ and sets the default schedular for any /dev/sd* devices that don't rotate to deadline.


jbhansen@craven-moorhead:~$ cat /etc/udev/rules.d/55-ssd-schedular.rules
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

All times are GMT -5. The time now is 11:44 AM.