Kernel requirement

[bmarwell]

Problem description

shellcheck does not mention a minimum kernel.
It does not run on LTS Kernel 3.0.x from SLES12.

For new checks and feature suggestions

• shellcheck.net (i.e. the latest commit) currently gives no useful warnings about this
• I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

Here's a snippet or screenshot that shows the problem:

$ ./shellcheck
FATAL: kernel too old
Aborted

$ uname -or
3.0.101-108.35-default GNU/Linux

Here's what shellcheck currently says:

FATAL: kernel too old

Here's what I wanted or expected to see:

(whatever the default output is)

[koalaman]

Huh, this appears to be due to the version of glibc being linked in. I did not know it had such a restriction.

[kaushalmodi]

I was on shellcheck 0.4.6 and https://shellcheck.storage.googleapis.com/shellcheck-v0.4.6.linux.x86_64.tar.xz worked great for me.

Today I updated to https://shellcheck.storage.googleapis.com/shellcheck-v0.7.0.linux.x86_64.tar.xz and I got this same error on shellcheck -V:

FATAL: kernel too old
Abort (core dumped)

My OS is old (cannot upgrade, because at work): RHEL 6.8, which uses glibc 2.12.

Can you please build all the releases with the same glibc that you used for version 0.4.6 (and 0.4.7)?

I have checked that none of the binaries starting shellcheck v0.5.0 work on my system.

[bmarwell]

@koalaman I tried to compile it on an 2.x kernel but failed. Too bad some Linux LTS versions still use a 3.0 kernel. :(

[kaushalmodi]

@koalaman Is it possible to go back to the same build env you used for shellcheck 0.4.6 release? I am unable to use any of the new releases after that.

[bmarwell]

@koalaman can you please kindly comment on this? Thanks :)
PS: Shellcheck 0.4.6 works for me, too.

[thezoggy]

I went and tried the latest stable and also run into the same issue, when you switched to doing statically linked it breaks oh RHEL due to old glibc/kernel.

% shellcheck -V
FATAL: kernel too old
Abort

while 0.4.6 works fine

% shellcheck -V
ShellCheck - shell script analysis tool
version: 0.4.6
license: GNU General Public License, version 3
website: http://www.shellcheck.net

my work relies on RHEL which sadly limits my ability to work around this issue:

% cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.3 (Santiago)
% uname -or
2.6.32-279.14.1.el6.x86_64 GNU/Linux

[smtdev]

Hey @bmarwell @thezoggy @kaushalmodi, did you find any solution for this? I am in a similar situation. I can't use higher versions than 0.4.7:

% ./shellcheck -V
FATAL: kernel too old
Aborted (core dumped)

% cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.10 (Santiago)

% uname -or
2.6.32-754.41.2.el6.x86_64 GNU/Linux

I have a local $HOME/usr folder structure with some higher GLIBC binaries, as I have no root permissions to perform upgrades and I needed to patch different binaries using patchelf before, but I don't find a way to compile shellcheck pointing out to my $HOME/usr folder structure instead of the static /usr one.

[kaushalmodi]

@smtdev I have since updated to CentOS 7.6. That has a newer glibc library and this issue goes away. I am able to use later versions of shellcheck after that.

[smtdev]

@smtdev I have since updated to CentOS 7.6. That has a newer glibc library and this issue goes away. I am able to use later versions of shellcheck after that.

Lucky man there 😃. I can't update the OS so, sadly, I think that I'll keep on 0.4.7 forever.

[koalaman]

Unfortunately Haskell is not great for forward compatibility, and it's rarely easy to build modern versions of Haskell libraries on particularly old toolchains. I don't upgrade them for fun, so the current version is only there because the previous ones stopped working.

If anyone has a passion for ten year old kernels and the time to experiment, you could try A) using a toolchain not based on glibc, which is where the restriction is, B) using a modern GHC toolchain built on top of an older gcc chain, or C) wrapping the whole thing in qemu which can actually boot and exit in CLI mode in under a second even without kvm or root.

[bmarwell]

Hi @koalaman

The problem is not we like 10yrs old kernels, it is that those are LTS-Kernels, so vendors do not upgrade their LTS distrox to newer kernels. :(

[djmattyg007]

It feels like the enterprises depending on such old operating systems should invest in this effort themselves, rather than expecting FOSS maintainers to pick up the slack for their unwillingness to upgrade.

[bmarwell]

@djmattyg007 that's shortsighted. I would have agreed if you said "unsupported OSes", but vendors like Novell (SuSE/SLES) and RedHat (CentOS/RHEL) use LTS kernels for a reason.

I don't know about Haskell much, but I'm a Java Dev and Java 17 runs just fine on those old systems (09/2021) as well as Java 6 (put of support for 8 years now). And Java 17 can execute programs written for Java 5 or even older (as long as no internal class had been used).

That said, it is much more likely that Haskell is not suited for enterprises who might have specific reasons to not go bleeding edge. Not every company is a start-up.

Sorry to hear this. Sorry for Haskell.

[bmarwell]

Besides: it's two years ago I created this issue. We don't have kernel 3 anymore. Still, I see no indication which kernel is required.

Please set up at least a version requirement. That's all I ask for!

[djmattyg007]

I would have agreed if you said "unsupported OSes", but vendors like Novell (SuSE/SLES) and RedHat (CentOS/RHEL) use LTS kernels for a reason.

Just because a company being paid large amounts of money is supporting some ancient piece of software, doesn't mean others not being paid are beholden to the same support. As I've just implied, these companies being paid (or doing the paying) should be the ones making the necessary contributions.

This isn't short-sighted at all. Most FOSS maintainers (myself included) have very limited time to work on what are ultimately side projects. If companies with actual money to spend are depending on these things, they should cough up the necessary support. They cannot expect the community to do everything for them.

[djmattyg007]

You could claim the same thing about python2. It's still "supported" by RedHat etc, but most FOSS maintainers have completely dropped python2 support in the latest versions of their packages. How long do you expect people working for free to support something that was EOL'd upstream two years ago?

And that's just python2. You are (were?) dealing with a decade-old kernel. What are you expecting?

[bmarwell]

Well, I only expect what I do myself for others. Most Apache projects are still on Java 8, because it's used in a lot of enterprises and there are only few downsides. Feel welcome to look at projects from the Apache Foundation.
And there are enough contributors.
I'm sorry if that doesn't work for you. I would try to dig in if I had the slightest idea of Haskell, but sadly I don't. Sorry for this.

Python is not comparable due to API changes.

Again, the only thing I wish now is the minimum kernel version in the requirements section from your readme file. Is that too much I'm asking for?

[koalaman]

Of course that's less of a "add a line to the readme" issue, and more of a "evaluate legacy kernel compatibility from now on" issue.

However! I tried building ShellCheck on Alpine which uses Musl instead of glibc, and it went remarkably smoothly. Ubuntu 8.04 with Linux 2.6.24 is too old to support github's SSL and can't unpack xz, but once fetched, it is able to run these ShellCheck binaries.

Can you give it a try with the latest build, https://github.com/koalaman/shellcheck/releases/download/latest/shellcheck-latest.linux.x86_64.tar.xz ?

[bmarwell]

However! I tried building ShellCheck on Alpine which uses Musl instead of glibc, and it went remarkably smoothly. Ubuntu 8.04 with Linux 2.6.24 is too old to support github's SSL and can't unpack xz, but once fetched, it is able to run these ShellCheck binaries.

Uhm...

#1602 (comment)

Besides: it's two years ago I created this issue. We don't have kernel 3 anymore. Still, I see no indication which kernel is required.

The current ones are running just fine.

I suggest you put in sth like 4.12.14 or so which is our current kernel as far as I can tell. :-)

[djmattyg007]

I suspect that even attempting to determine what the minimum required kernel for a specific piece of software is beyond the expectations of most FOSS maintainers. How do you even go about determining such a thing? Start booting up oodles of VMs and manually attempting to run all code paths in your software?

[bmarwell]

I suspect that even attempting to determine what the minimum required kernel for a specific piece of software is beyond the expectations of most FOSS maintainers. How do you even go about determining such a thing? Start booting up oodles of VMs and manually attempting to run all code paths in your software?

Ah, I was hoping Haskell provided such information. Please note, I am from a Java world where we only need to watch the language level, which is relatively easy. I didn't mean to add much work for you.

One idea would be to add more oses to you build matrix:
https://github.com/koalaman/shellcheck/blob/master/.github/workflows/build.yml#L48-L51

currently you could also select 18.04 for example (which has some 5.4.x kernel).
https://github.com/actions/virtual-environments

[koalaman]

Native compatibility is definitely a more complex topic than Java compatibility.

GHC mostly only has a say in what you can build on, not what built binaries can run on. Runtime compatibility is in large part up to the back half of the toolchain, and in this case the restriction was in the GNU C runtime library. A C program would have failed the same way, so the crash itself wasn't Haskell related.

There's already an extended test matrix for testing build compatibility on Debian Stable, Ubuntu LTS, and such, but these are only useful for testing the build. Any system that can build ShellCheck is undoubtedly also modern enough to run resulting binaries, and virtual environments run on the host kernel so they wouldn't have shown this issue.

It would be possible to use qemu or similar to test on a variety of kernel versions (or maybe full distros), but the results would be informative more than actionable.