SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
That was my main question. I should have worded it as "Will Pat become the maintainer of the 3.10.x kernel for Slackware 14.1?" essentially was what I was concerned with because of how one of Slackware's goals/philosophies I think is to remain as upstream/vanilla as possible and so that COULD mean Pat wouldn't touch the 3.10.x kernel. Having confirmation from Pat or someone from the team would be helpful though. Consdering that 3.10.17 is still in use since 14.1 was released, http://www.slackware.com/announce/14.1.php I am guessing he will not be touching/maintaining the kernel? Wow, looking here https://www.kernel.org/pub/linux/ker...ngeLog-3.10.87 the 3.10 kernel goes as high as as 3.10.87? Thats a lot....so any of the bugs that have been fixed in 3.10.87 are prevent in Slackware's 3.10.17?
Again, huh? You're falling back to that Pat won't deviate from upstream and needs to put out the latest kernel versions (i.e. whatever is currently maintained at kernel.org) for Slackware 14.1. That's not how things work, OK?
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,154
Rep:
Quote:
Originally Posted by Altiris
Hmm I see, what bothers me is not that just because it's EOL it's no longer secure , but it's an issue arises like security or bug, will "we" who are on 14.1 receive a fix for it? As you say there have been backports in 3.10 but from the kernel developers, which exactly my point...this time around these patches would have to be done by Pat. If so, great. If not, I may need to move distros.
AFAIK, previous versions of Slackware are supported for 5 years, sometimes longer, so any security problems will be fixed during that period.
Pat will only upgrade the kernel in case of a serious security breach, not just for bug fixes.
Generally speaking bugs in the kernel affect only a few percentage of the user base, so there would be no point in upgrading the kernel every time there is a new release.
Would you call stable a distribution that upgrade the kernel to 3.10.17, 3.10,18, 3.10.19 etc.?
This would be just a big waste of time for Pat as well as for the Slackware users.
Last edited by Didier Spaier; 09-09-2015 at 05:48 PM.
Reason: Typo fix.
Would you call stable a distribution that upgrade the kernel to 3.10.17, 3.10,18, 3.10.19 etc.?
In one of those "what would you like to see in slackware" threads I suggested including exactly this as an *optional* feature so you could track newer kernel releases as they came out. Everyone told me I was silly.
I might have a shot at writing some script/tool to download the patches between the running kernel and the latest kernel release in the same branch and spit out a slackware package but all the kernel building tutorials I've read never actually produce slackware packages.
Again, huh? You're falling back to that Pat won't deviate from upstream and needs to put out the latest kernel versions (i.e. whatever is currently maintained at kernel.org) for Slackware 14.1. That's not how things work, OK?
I WAS unsure about whether that part was actually true. If what you say is true then fine, "OK" and I believe you.
Quote:
Originally Posted by Didier Spaier
Pat will only upgrade the kernel in case of a serious security breach, not just for bug fixes.
Generally speaking bugs in the kernel affect only a few percentage of the user base, so there would be no point in upgrading the kernel every time there is a new release.
Would you call stable a distribution that upgrade the kernel to 3.10.17, 3.10,18, 3.10.19 etc.?
This would be just a big waste of time for Pat as well as for the Slackware users.
I mean, if 3.10.x shouldn't change too much as the person supporting it is only making changes for bug fixes which include security fixes (I dont believe new features are being added in) so it still could remain stable if it is tested enough and nothing seems to break. I personally value security, so the fact that Slackwre is versions behind an LTS release bothers me and doesn't make much sense for me security wise, for other people if its fine then fine for them but I am just saying about myself. Other bugfixes that I am looking at in 3.10.x (3.10.78 to be exact) is an ext4 corruption bug which Slackware is now missing.
I don't know, it just doesn't make sense to me that literally every other package in slackware 14.1 gets updates for bug fixes (security) except for the kernel which is LTS and def. shouldn't suffer anything breaking. Other distros like CentOS and Debian provide kernel updates (again they are still the main kernel, just bugfixes) and there is no more or less stability on the system.
Thats just my opinion though. Thanks for clearing things up though!
Honestly what I am mainly concerned with is why Slackware 14.1 is still using 3.10.17 and not 3.10.87
Looking at here, http://www.linuxquestions.org/questi...-a-4175530903/ Pat does seem to backport serioud fixes so I guess that is fine with me. Great for me actually, I was thinking of moving off Slackware (the only thing bothering me at this point was exactly the old kernel and possible vulnerabilities).
Other bugfixes that I am looking at in 3.10.x (3.10.78 to be exact) is an ext4 corruption bug which Slackware is now missing.
I assume that you are speaking about commit 5a7d1e16a425786d8f6f5d4f707bb4dc879499d1 "ext4: fix data corruption caused by unwritten and delayed extents".
Well, if you are worried you can either build and upgrade yourself a newer kernel or use another distribution: the choice is yours.
Anyhow, I confirm again that Pat ships vanilla kernels as much as possible. So if he considers that a bug fix needs to be included, he will probably ship a newer kernel instead of patching it locally. In other words he doesn't ship so called "distribution" kernels. I can be wrong, but I doubt that this will change anytime soon, although there could be exceptions
Last edited by Didier Spaier; 09-10-2015 at 09:21 AM.
...
so it still could remain stable if it is tested enough and nothing seems to break. I personally value security, so the fact that Slackwre is versions behind an LTS release bothers me and doesn't make much sense for me security wise, for other people if its fine then fine for them but I am just saying about myself. Other bugfixes that I am looking at in 3.10.x (3.10.78 to be exact) is an ext4 corruption bug which Slackware is now missing.
I don't know, it just doesn't make sense to me that literally every other package in slackware 14.1 gets updates for bug fixes (security) except for the kernel which is LTS and def. shouldn't suffer anything breaking.
LTS stands for Long Term Support. Not Long Term Secure. Not even Long Term Stable.
Quote:
Other distros like CentOS and Debian provide kernel updates (again they are still the main kernel, just bugfixes) and there is no more or less stability on the system.
I don't know how fast they move, but as I said before, an LTS does not ensure that you get security or stability, but just that you get support from kernel devs. If you look at history, you can see that it's has not been guaranteed. So just because a distro follows a stable branch does not mean much to me.
Altiris, I think there is some misunderstanding going on here. If there are serious security issues, Pat will address them. So far, Pat did provide a patch for the kernel included in 14.1, but it still stayed on the same version.
Quote:
patches/packages/linux-3.10.17-2/*:
These are new kernels that fix CVE-2014-0038, a bug that can allow local
users to gain a root shell.
Be sure to reinstall LILO (run "lilo" as root) after upgrading the kernel
packages, or on UEFI systems, copy the appropriate kernel to
/boot/efi/EFI/Slackware/vmlinuz).
For more information, see: http://cve.mitre.org/cgi-bin/cvename...=CVE-2014-0038
(* Security fix *)
Pat has to gauge every patch he puts out on a stable release with what that patch can do to a stable system. In your mind, upgrading the kernel to a newer release may not be a big deal, but for someone maintaining a server, kernel upgrades are a much bigger issue. Everytime I upgrade my kernel, I have to rebuild various modules, and I've had long periods of downtime with my VMs as a result of running into unforeseen issues. If you're running a production server that hosts VMs, having those go out due to an issue with a security update doesn't speak well to a stable platform. Pat and team aims for stable. This is why many packages, even in -current, are not at the latest version. Newer builds can introduce instability. Newer kernels, even in the same series can introduce bugs. They try and find something that is new enough but still is stable. As has always been the Slackware tradition, they put you in charge of maintaining your systems. Yes, Pat does offer security patches, but he doesn't release them for every CVE that has been issued. Again, he has to weigh the possibility of introducing instability in a system vs having all the security holes plugged.
Just because a product is no longer supported by the developers doesn't mean that it will automatically be upgraded in a stable release of Slackware.
Also, think about Pat trying to maintain each kernel release with every version of Slackware that is currently receiving security updates. Currently, Slackware will provide security updates for 13.0, 13.1, 13.37, 14.0, and 14.1, plus keeping on top of -current. All of the 13.x kernels are in the 2.6 series, and are all EOL now. Trying to keep those updated to a non-EOL kernel could prove to be futile since many programs had difficulty when the kernel moved from the 2.x series to the 3.x series. He'd have to upgrade a lot of programs, which again, could introduce stability.
Long story short, most of the time you can expect that programs that are in a stable Slackware release won't have their versions changed unless absolutely necessary, and I don't think I've ever seen a kernel version change once the stable version is released.
Long story short, most of the time you can expect that programs that are in a stable Slackware release won't have their versions changed unless absolutely necessary, and I don't think I've ever seen a kernel version change once the stable version is released.
I have done that before, most recently a couple of years ago in Slackware 14.0. The upgrade to the latest stable, same series, LTS kernel broke Intel graphics and the kernel packages had to be patched and reissued twice before things worked well again.
Altiris, I think there is some misunderstanding going on here. If there are serious security issues, Pat will address them. So far, Pat did provide a patch for the kernel included in 14.1, but it still stayed on the same version.
Pat has to gauge every patch he puts out on a stable release with what that patch can do to a stable system. In your mind, upgrading the kernel to a newer release may not be a big deal, but for someone maintaining a server, kernel upgrades are a much bigger issue. Everytime I upgrade my kernel, I have to rebuild various modules, and I've had long periods of downtime with my VMs as a result of running into unforeseen issues. If you're running a production server that hosts VMs, having those go out due to an issue with a security update doesn't speak well to a stable platform. Pat and team aims for stable. This is why many packages, even in -current, are not at the latest version. Newer builds can introduce instability. Newer kernels, even in the same series can introduce bugs. They try and find something that is new enough but still is stable. As has always been the Slackware tradition, they put you in charge of maintaining your systems. Yes, Pat does offer security patches, but he doesn't release them for every CVE that has been issued. Again, he has to weigh the possibility of introducing instability in a system vs having all the security holes plugged.
Just because a product is no longer supported by the developers doesn't mean that it will automatically be upgraded in a stable release of Slackware.
Also, think about Pat trying to maintain each kernel release with every version of Slackware that is currently receiving security updates. Currently, Slackware will provide security updates for 13.0, 13.1, 13.37, 14.0, and 14.1, plus keeping on top of -current. All of the 13.x kernels are in the 2.6 series, and are all EOL now. Trying to keep those updated to a non-EOL kernel could prove to be futile since many programs had difficulty when the kernel moved from the 2.x series to the 3.x series. He'd have to upgrade a lot of programs, which again, could introduce stability. I thought that updating the kernel wouldn't be an issue because of how it was still in the 3.10 series but by what you and Pat have said below me (I saw the actual thread where someone said the same thing about intel drivers breaking from a 3.2.X or 3.4.X kernel update, I forget which exactly) and that makes sense. I too am maintaining a server, it has one Vista VM in it but really its just a personal server that I use for myself but it is open to the internet
Long story short, most of the time you can expect that programs that are in a stable Slackware release won't have their versions changed unless absolutely necessary, and I don't think I've ever seen a kernel version change once the stable version is released.
All I wanted was clarification in that if there is some serious bug (security, filesystem corruption etc) it would get introduced into the kernel via backporting or at the time I wrote OP, an updated kernel as I thought that editing the kernel would be against Pat's wishes for Slack with the vanilla packages thing, so I assumed it would have to be updated, but I see that isnt always the case.
I actually have a question for you though, with when you said "Everytime I upgrade my kernel, I have to rebuild various modules, and I've had long periods of downtime with my VMs as a result of running into unforeseen issues." is this a Slackware only thing? I used to have a VM on CentOS 6 (QEMU/KVM + libvirt and I used virt-manager to manage) and I would update the kernel whenever there was an update (granted the releases were something like 2.6.32-500 or whatever) and I never had problems with the VM, would this be because yum automatically re-builds things whereas in Slackware this is left to the user?
I actually have a question for you though, with when you said "Everytime I upgrade my kernel, I have to rebuild various modules, and I've had long periods of downtime with my VMs as a result of running into unforeseen issues." is this a Slackware only thing? I used to have a VM on CentOS 6 (QEMU/KVM + libvirt and I used virt-manager to manage) and I would update the kernel whenever there was an update (granted the releases were something like 2.6.32-500 or whatever) and I never had problems with the VM, would this be because yum automatically re-builds things whereas in Slackware this is left to the user?
This would possibly vary on the VM and how the package manager of the distro handles things. I use VirtualBox, which requires a few modules for my needs. With VirtualBox, it needs to recompile the modules for newer kernels. There is a SlackBuild that normally accomplishes this (if you use SBo), however, mine still prevented network access due to module issues once I recompiled when I moved to the 3.18 kernel (unfortunately, I don't remember how I fixed it).
It is possible your VM didn't require additional modules (possibly included in the kernel) or that they were provided in the package. I'm not really sure. But with Slackware, if you have a program that creates modules, most of the time, you'll need to recompile those modules against newer kernels. You see this most commonly with proprietary graphics drivers.
I actually have a question for you though, with when you said "Everytime I upgrade my kernel, I have to rebuild various modules, and I've had long periods of downtime with my VMs as a result of running into unforeseen issues." is this a Slackware only thing? I used to have a VM on CentOS 6 (QEMU/KVM + libvirt and I used virt-manager to manage) and I would update the kernel whenever there was an update (granted the releases were something like 2.6.32-500 or whatever) and I never had problems with the VM, would this be because yum automatically re-builds things whereas in Slackware this is left to the user?
It all depends.
For example, if you're using QEMU/KVM you shouldn't have any problems when upgrading the kernel (unless the kernel has introduced bug/big change itself). If you're using VirtualBox, you have to re-build the VirtualBox's kernel modules yourself. The point is, KVM is in the mainline kernel, whereas VirtualBox isn't.
The same applies for example for Nvidia proprietary driver versus the mainline kernel's driver. It basically boils to the point that Slackware does not rebuild third party modules, just like it does not track/resolve packages' dependencies
All this being said, I happily run 4.1.6 on both Slackware 14.0 and 14.1.
If your focus is security, or you're of the paranoid persuasion you'll probably want the minor fixes as well as the major ones, so you'll be wanting all those local privilege escalations, information disclosures and denial of service fixes that have been applied upstream post 3.10.17 and which Pat doesn't deem worthy of a kernel update. If that sounds like you, you should already be building your own kernels periodically because of this and the end of life for 3.10.y shouldn't change anything for you, other than you'll want to switch to a newer branch if you haven't already left 3.10.y behind.
I just updated this old dinosaur from 3.10.17 -> 3.10.87 after a fresh install. It took 3h45m to compile the generic-smp kernel (P4 2.66 Ghz 1GB RAM). I'd forgotten how much faster modern kit is!
@D1ver, I have a kernel build script that will spit out a package if you need it. I posted about it once a long while ago, but nobody took much interest, most likely because it deviates from the official approach to packaging kernels by combining both kernel image and modules into a single package. It's designed to build as non-root from a pristine read-only kernel source tree. I've been using it for a couple of years now, and it makes kernel updates pretty painless.
As for pulling down the patches as they're released, using git is a nice easy way of doing that if you can spare half a gig or so of diskspace for the git object store.
If your focus is security, or you're of the paranoid persuasion you'll probably want the minor fixes as well as the major ones, so you'll be wanting all those local privilege escalations, information disclosures and denial of service fixes that have been applied upstream post 3.10.17 and which Pat doesn't deem worthy of a kernel update. If that sounds like you, you should already be building your own kernels periodically because of this and the end of life for 3.10.y shouldn't change anything for you, other than you'll want to switch to a newer branch if you haven't already left 3.10.y behind.
I just updated this old dinosaur from 3.10.17 -> 3.10.87 after a fresh install. It took 3h45m to compile the generic-smp kernel (P4 2.66 Ghz 1GB RAM). I'd forgotten how much faster modern kit is!
@D1ver, I have a kernel build script that will spit out a package if you need it. I posted about it once a long while ago, but nobody took much interest, most likely because it deviates from the official approach to packaging kernels by combining both kernel image and modules into a single package. It's designed to build as non-root from a pristine read-only kernel source tree. I've been using it for a couple of years now, and it makes kernel updates pretty painless.
As for pulling down the patches as they're released, using git is a nice easy way of doing that if you can spare half a gig or so of diskspace for the git object store.
Ehh I like having things as much secure as possible/allowed at the very moment, although there will always be bugs no matter what and there will never be a chance a system is 100 secure so im not really THAT paranoid. I'd only be paranoid if a very clear and big security issue arose with whatever kernel I am on and there is a patch for it but the maintainer of the distro is not issuing a patch (sure I could do it myself but idk how). I don't want to compile my own kernel as I don't know how to do it nor do I have the time/am interested really (maybe in the future) but I guess I will stick to 3.10.17 ....I am debating if I should switch distros (other option for me personally is Debian but idk I like Slackware a lot) any "switching" will only happen during the holidays though as that is when I will have time. Thanks for the info!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
