I've just finished building and booting on 5.8.2 - uptime around one hour.

Oh, well...

1 members found this post helpful.

I'm trying to give 14.2 another shot but the kernel is turning to be out of date. For example I migrated to another distro and formated a disk using xfs. Now I can't access that disk in 14.2 without a kernel update.

It would be helpful more generally if we can get a few select LTS kernel updates for Slackware Stable from time to time.

Fine, I tried booting a prebuilt kernel from another distro so that I could bootstrap a minimal system but as luck would have it, it doesn't boot. Presumably because the kernel is only bootstrapped for another system.

Anyone know a source where I can get a prebuilt vanilla huge kernel that I could just plug into 14.2? I'm unable to build locally as I only have access to a single USB memory stick.

1 members found this post helpful.

@slackerz
You can follow these instructions to get the huge -current kernel on your Slackware 14.2 system if you're using lilo. Note that you have to adapt the instructions for the actual kernel versions.
https://www.linuxquestions.org/quest...ml#post6053120

2 members found this post helpful.

Right thanks, I could make that work.

BTW, what's the significance of using LILO? I don't think it should matter as I prefer to use grub.

1 members found this post helpful.

@slackerz

lilo comes as the default boot loader with Slackware 14.2 and the instructions I presented in post #2523 are focusing on lilo. Those instructions also provide you with a failover setup, allowing you to boot both kernels.
Feel free to modify/adapt them for grub.

1 members found this post helpful.

Hello slackerz
How about rolling your own? It really isn't hard at all and just yesterday I rolled a custom 5.4.60 kernel in well under a half hour on an 8 year old system this way. I'm typing this from my Current system on an NVME drive and today I'll repeat it for my 14.2 install that's presently running 5.5.12 since apparently 5.5.x is EOL.

Anyway you really should at least look this over to see if you think you can make it work for you. If you add a new entry in Grub, or actually use OSProber and don't delete your present running kernel you have nothing to lose and considerable options and power to gain.


https://blog.paranoidpenguin.net/201...ackware-linux/


Incidentally Eric (Alien Bob) has what used to be a really excellent tutorial on building kernels but it hasn't been updated since 2.6.x kernels which worked fine until very recently (well into 5x kernels). The "gotcha" in that method now seems to be the .Xauthority merge to get root access to "make xconfig" which I like to see new options that get ignored with the "make olddefconfig".

A "make oldconfig" or the terminal based "make menuconfig" solves that but paranoid penguin's "make olddefconfig" is extremely easy on kernel building newbies because it basically just clones while updating all your existing options so the new kernel will be essentially identical to your running kernel just with new code. All that would be different is you can enable xfs support with a single checkbox before compiling.

Incidentally the reason your "other distro" kernel didn't work is very likely how much it had to be customized to suit almost all automatic dependency resolving distros, not because of bootstrapping. It used to be possible to boot other distros with a few minor losses from a Slackware kernel because Slackware is Vanilla but that is pretty much ruined by Systemd now, hit or miss at best.

1 members found this post helpful.

You trollin' ?.
I've been rolling my own for years. Time for a break considering there's no shortage in builds being rehashed these days. As I was mentioning I had a fledgling system that was booting off a USB stick and without any access to my xfs volume theres no way I could roll my own.

The issue is now resolved so no point in picking this discussion up again.

Dude how would I know you roll your own? How could I be trolling if I was even of that mind, which I am not. It was just a suggestion to try to help out a newcomer to LQN. It is also a valid suggestion at that since you could, as such an expert, build it on your system with any number of versions of the Slackware install media employing the huge.s kernel since it has "CONFIG_XFS_FS=y" built in. Sheesh! No good deed goes unpunished, eh?

6 members found this post helpful.

5.9-rc2

Release Candidate 2, for the 5.9 "mainline" development kernel has been been made available for testing.

The tarball, https://git.kernel.org/torvalds/t/linux-5.9-rc2.tar.gz

Mr. Torvalds' announcement, http://lkml.iu.edu/hypermail/linux/k...8.2/10710.html

1 members found this post helpful.

Year 2020, Round 52.

Another batch of kernel updates has been scheduled for release on Wednesday, 26 August 2020, at approximately 08:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Tuesday (depending on your time zone).

The details:

5.8.4-rc1, with 148 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/00833.html

5.7.18-rc1, with 124 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/00209.html

5.4.61-rc1, with 107 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/00686.html

4.19.142-rc1, with 71 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/00542.html

4.14.195-rc1, with 50 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/00570.html

4.9.234-rc1, with 39 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/00330.html

4.4.234-rc1, with 33 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/00619.html

1 members found this post helpful.

A second round of release candidates:

5.8.4-rc2, with 149 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/01362.html

5.7.18-rc2, with 127 patches,http://lkml.iu.edu/hypermail/linux/k...8.3/01359.html

5.4.61-rc2, with 109 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/01343.html

4.19.142-rc2, with 73 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/01349.html

4.14.195-rc2, with 51 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/01350.html

4.9.234-rc2, with 39 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/01352.html

4.4.234-rc2, with 34 patches, http://lkml.iu.edu/hypermail/linux/k...8.3/01345.html

2 members found this post helpful.

Maybe we'll get 5.9 LTS in 15 after all!
Would be just fine with me!

3 members found this post helpful.

disclaimer: opinion, ymmv.

I used to think that the LTS kernels were in some way "special", but after thinking it through I came to realise that unless compatibility with 3rd party kernel modules is a consideration, they're really little more than just "old kernels".

In theory, it's nice to have a maintained fallback for when a breakage occurs in a newer kernel, but the reality is that, more often than not, the breakage has been backported into the older "stable" branches too.

5.4 doesn't currently cut it, especially for intel gpu users for whom there are known issues, and it would be good to bump the kernel branch used in current, regardless of "LTS" status.

5 members found this post helpful.

I tried this approach with 5.6.x.x last version, sure enough exfat was broken. I reverted back to 5.4. I'll compile the last 5.7 soon and see if it causes any breakage. I don't see the purpose of multiple kernels. They need 2 in my opinion, 1 for newer hardware and 1 for older. Trying to maintain multiple kernels and backporting seems to be a headache.

5.8 would be the biggest bang for the buck with all of the new AMD support added in (not to mention the fixes in i915 in previous kernels)
I can't use 5.4 reliably for any hardware using i915 or AMD in the last 2-3 years... (I have a few such models)

2 members found this post helpful.