FATAL: kernel too old

[csreynolds]

Last build works fine, build from last night wont even start.
My docker host is :

[creynolds@server ~/]$ cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
[creynolds@server ~/]$ uname -a
Linux server 3.10.0-1160.15.2.el7.x86_64 #1 SMP Wed Feb 3 15:06:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[creynolds@server ~/]$ docker run -it binhex/arch-delugevpn:2.0.4.dev38-g23a48dd01-3-02 bash
FATAL: kernel too old
[creynolds@server ~/]$ docker run -it  binhex/arch-delugevpn:2.0.4.dev38_g23a48dd01-3-01 bash
[root@bdca75fee295 /]#
[root@bdca75fee295 /]# exit

arch-base image does the same thing since changes on 20210222

[creynolds@server ~/]$ docker run -it  binhex/arch-base:2021022208 bash
FATAL: kernel too old
[creynolds@server ~/]$ docker run -it binhex/arch-base:2021012904 bash
[root@ebcc69fc87e9 /]#
exit

It runs fine on my fedora33 installation, which is currently kernel 5.10.17-200.fc33

Problem is with archlinux source. They defaulted to zstd compression, only included in kernel 5.9+. Any host machine running below 5.9 will get this error.

news here:
https://archlinux.org/news/moving-to-zstandard-images-by-default-on-mkinitcpio/

Looking at this chart of distribution default kernel versions, its a pretty bold breaking change they made:
https://zonedstorage.io/distributions/linux/

[DamageDoctor]

Same issue here
Synology DS1817+
DSM 6.2.3-25426 Update 3
Docker App 18.09.0-0513

[wojo]

Same here on the latest DSM 6.2.3-25426 Update 3.

[ChrisBaker97]

Same same.

[DamageDoctor]

I ended up just rolling back to previous version like @csreynolds. The joy of :latest ;)

[groot-stuff]

Latest version pushed to dockerhub (2.0.4.dev38-g23a48dd01-3-02) results in the error below in both binhex-radarr and binhex-sonarr dockers on unRaid 6.8.3. When going to http://[IP]:8112/json in the browser an HTTP 405 error is returned.

Unable to communicate with Deluge. The operation has timed out.: 'http://[IP]:8112/json'

Rolling back to 2.0.4.dev38_g23a48dd01-3-01 resolved the issue.

[grayhat917]

Same here... 1517+ Kernel Version 3.10.105

[Ashkaan]

Same here.

[neoKushan]

Had the same issue as others.

[DamageDoctor]

Problem is with archlinux source. They defaulted to zstd compression, only included in kernel 5.9+. Any host machine running below 5.9 will get this error.

news here:
https://archlinux.org/news/moving-to-zstandard-images-by-default-on-mkinitcpio/

Looking at this chart of distribution default kernel versions, its a pretty bold breaking change they made:
https://zonedstorage.io/distributions/linux/

Super aggressive move. Time to turn off a bunch of docker image auto-updates I guess.

[binhex]

Problem is with archlinux source. They defaulted to zstd compression, only included in kernel 5.9+. Any host machine running below 5.9 will get this error.
news here:
https://archlinux.org/news/moving-to-zstandard-images-by-default-on-mkinitcpio/
Looking at this chart of distribution default kernel versions, its a pretty bold breaking change they made:
https://zonedstorage.io/distributions/linux/

Super aggressive move. Time to turn off a bunch of docker image auto-updates I guess.

i dont believe this is the issue, as i am running kernel 4.9.x with no issue, i THINK its probably related to the glibc changes, see link:- https://bugs.archlinux.org/task/69563

extract from the post, note the highlighted section:-

1. whitelisting syscalls in non-Arch packages/software is not our problem
2. running against older kernels is sort-of our problem - I'd still argue that having old packages is not our problem, but it is often out of control of the user.

glibc-2.33-4 in [testing] should fix this. I readded the --enable-kernel which was inexplicably removed from the PKGBUILD four years ago (surprised it has not hit us before). I set the minimum kernel version as 4.4, being the oldest still LTS upstream. Anything older is really not an Arch problem! All those patching glibc should really just have looked at configure options!

[quorn23]

@binhex would that be the arch-delugevpn:test one? If so, could you push the image? The one on docker hub is out of date. (If that's not what you mean with [testing] apologies.)

[binhex]

@binhex would that be the arch-delugevpn:test one? If so, could you push the image? The one on docker hub is out of date. (If that's not what you mean with [testing] apologies.)

i think you misunderstand, the glibc package 2.33-4 is included in both latest and test, therefore both will fail for synology users, sadly i think this could be the end of road for synology support until the kernel gets bumped up to 4.4+

[neoKushan]

What a shame that would be. Hopefully DSM 7 will include a kernel bump (I'd be surprised if it doesn't but none of the literature around it specifies), but that's currently in Beta and some older Synology devices are probably going to be stranded.

For those devices, using the image binhex/arch-delugevpn:2.0.4.dev38_g23a48dd01-3-01 still works a charm for me. Until then, I guess we're waiting. Maybe it's time to kick my home server needs up a notch, my little synology is pushing itself hard as it is.

[c-hri-s]

Not sure this is an issue for all Synology NAS' - maybe an older subset.

I'm running a DS918+ on DSM 6.2.3-25426 Update 3 and I have Linux babynas 4.4.59+ #25426 SMP PREEMPT Mon Dec 14 18:48:50 CST 2020 x86_64 GNU/Linux synology_apollolake_918+

[ChrisBaker97]

@neoKushan it looks like people running the DSM 7 beta are having the same problem. Some brief research suggests that the kernel version is tied to the hardware, not to DSM, and that while Synology back ports features and fixes into the older kernels, there is never a version bump. So it would seem that the only way to address this on the Synology end would be to buy a newer NAS.

That being said, I'm not sure what the downside to freezing this container at 2.0.4.dev38_g23a48dd01-3-01 would be for those of us on older Synology hardware, given that Deluge itself hasn't been updated in almost three years anyway?

[hot22shot]

@ChrisBaker97 as I run DSM 7 on my DS916 I can confirm that, Synology locks down the kernel to a model and barely bump it. FYI I'm running Linux kernel version 3.10.108. That will definitely cause me some issue with docker containers as time fly.

[neoKushan]

Ouch, I run a DS916+ myself but not upgraded to DSM7. Very poor show on Synology's part but I guess you could argue that it's 5 year old hardware.

I am personally outgrowing my DS916+ anyway so will be migrating to something a bit better and more modern in the near future but this does suck for anyone running said hardware. More and more container images are going to migrate away from these old kernel versions as time goes on. As @ChrisBaker97 says, theres probably no real issue freezing on the most latest version of this particular image.

[binhex]

That being said, I'm not sure what the downside to freezing this container at 2.0.4.dev38_g23a48dd01-3-01 would be for those of us on older Synology hardware, given that Deluge itself hasn't been updated in almost three years anyway?

sadly there is this (resolved in 'latest), which leaves you guys between a rock and a hard place:- binhex/arch-qbittorrentvpn#80

[ChrisBaker97]

The more I learn, the more I'm leaning toward steering my Synology into being basically just a file server, while offloading the application and networking services to a separate device. I really don't want the hassle of keeping up my own separate server, but I also never would've imagined that Synology was freezing the kernel on a version that was EOL over three years ago, so I guess I desire to have a little more control over the software environment than I can get from them.

[hot22shot]

Can't argue with you on that, my DSM will also be back to what it was in the beginning : a storage server.
I'll move my software to better supported platform.
And when the time comes to replace it, I'll keep Synology's limitations in mind.

[neoKushan]

That being said, I'm not sure what the downside to freezing this container at 2.0.4.dev38_g23a48dd01-3-01 would be for those of us on older Synology hardware, given that Deluge itself hasn't been updated in almost three years anyway?

sadly there is this (resolved in 'latest), which leaves you guys between a rock and a hard place:- binhex/arch-qbittorrentvpn#80

Well. Poo. That's a humdinger of an issue.

Can't argue with you on that, my DSM will also be back to what it was in the beginning : a storage server.
I'll move my software to better supported platform.
And when the time comes to replace it, I'll keep Synology's limitations in mind.

Thirding this one. I've already been researching and scoping where I go with this next and my current solution would be a custom build running Unraid. The likes of FreeNAS (TrueNAS) can run applications but realistically it's more geared towards storage, whereas Unraid can manage your storage but has first-class support for running any containers you might want while having minimum management overheard. The software is slick, well supported and does basically everything that DSM does (At least for my use-case), as well as some other party pieces. Cobble together some commodity hardware, slap a load of drives in there and you've got something functionally better than a Synology, but just as polished and easy to use. I'd recoup most of that cost from selling the DS916+ as well (which has held its value pretty well over the years).

I used to use a lot more functionality from DSM itself, but since I went down the container route I ended up using less and less of it and instead used a containerised application instead. Much easier to manage, keep updated and no reliance on Synology to fix things when stuff breaks (Which they're notoriously slow to do). It was just a matter of time really.

[binhex]

FWIW, my main support base is unRAID and will be for the foreseeable, i run a medium sized home server and unraid fits my needs well, the community is strong and friendly and Limetech keep making improvements with each version (latest release JUST having dropped), yes you have to pay for it, but ROI for me has been outstanding.

[ChrisBaker97]

At the risk of turning this issue discussion into a forum post...

I was already in the market for a rackmount Synology to replace my DS1815+. Having recently completed a 30-month-long cycle upgrading the capacity of all eight drives, I'm really not in a position to easily switch to another vendor, since I'd have to come up with a way to park a ton of data if I can't just move the drives over directly. I also see value in the Synology Hybrid RAID, which, as far as I know, isn't functionality that you can easily replicate with the alternatives. (It sure was nice to be able to swap 8TB drives in for the old 4TB ones piecemeal as they failed over time, while gaining the additional storage immediately, rather than waiting until they were all upgraded first. It'll be even nicer in DSM7, when it will no longer require a lengthy rebuild if you're just swapping out for a larger drive pre-failure.)

For several years, I've been waiting for Synology to come out with an 8 to 12-bay rackmount unit that had sufficient processing power to do some serious video transcoding. The new RS1221+ comes close, but is still a bit of a disappointment there, as well as with its lack of built-in 10GbE and M.2 NVMe SSD slots (which can both admittedly be added, at additional expense, via an add-on card).

So I guess I begrudgingly feel like Synology adds enough value to justify their price premium, even when only serving as a NAS, and as much as I'd like to punish them for basically making Docker a ticking time bomb here, I think I've known for a while that I really should be running two separate appliances for storage and services anyway. I've definitely been looking at unRAID as an OS, and now I'm just wondering if I can squeeze enough processing power into a 1U shallow box, or if I need to go to 2U for no other reason than to fit an adequate heat sink. Another option I've been meaning to look into is a NUC.

[neoKushan]

I also don't want to turn this into a discussion on the matter (And apologies if this is too off topic) but for whatever it's worth, after thinking about it earlier I've pulled the trigger on ordering the components to build my own unRAID system.

This is roughly what I've gone for: https://uk.pcpartpicker.com/list/pNJgmk

My requirements are fairly typical of a lot of people in terms of media consumption/plex transcoding but I'll be running some hefty VMs/Containers (Like game servers) as well.

I could have saved money here by going with an earlier-generation intel CPU and 6 cores is almost certainly overkill for most. A pentium transcodes just as well well but I have gone for a higher core count here for my other needs.

A Motherboard with 4 memory slots and plenty of SATA ports. I only put in 2x sticks of memory for now, but wanted the 4 in case I need more in future. 32GB of RAM is fine for my needs for now but I can expand easily if I need.

An nvme drive for cache/scratch/performance where needed. 1TB is overkill for sure, a 256GB drive would probably be enough for most (If you need one at all) but this leaves me room for running more VMs/Container images from it.

Finally, a decent, well-regarded case that can hold plenty of 3.5 inch disks. This one holds 8 + space for 2 more (2.5 or 3.5), which is great for my needs. If I had the room I'd have looked at a rackmount, but this is going to live in my office so acoustics are a factor here.

Not listed: SATA cables, an LSI card for more SATA ports and some SATA power splitters for the PSU. YMMV.

In case anyone is thinking of doing a similar thing themselves, you can use that as a base or look at the excellent NAS Killer build guides from serverbuilds for inspiration.

One last thing to add: I am SUPER glad I have my environment configured as a docker-compose script. I know I can't use compose out of the box with unRAID but it's not difficult to do and will make migrating a cinch.

[aprillia99]

At the risk of bringing the intelligent level of this post down. What Synology version is still working?

[ChrisBaker97]

What Synology version is still working?

2.0.4.dev38_g23a48dd01-3-01 is the latest that works with kernels older than 4.4.

[the-lazy-fox]

So what's the end of this thread?
No way to make it retro-compatible?

[ChrisBaker97]

Correct. The version listed above is the last one that will work for Linux kernels < 4.4. (uname -srv In the terminal to see your version and build.)

Note that 4.4 is slated to be EOL in February 2022, and that even the latest Synology devices (2021 models) are shipping with 4.4. The kernel has historically been fixed to each model, and does not increment with DSM updates. I expect this is going to be a real problem for those of us running Docker containers on Synology devices going forward.

[neoKushan]

Isn't 4.4 under some "Super long term support" until 2026 though?

It's still a really old Kernel and it's still poor form on Synology to not ship newer kernel versions as they're going to end up with knock-on effects as more and more things move away from it. This particular base image is just the first, more will follow. Like how long will Docker support this kernel version at all? Who's going to keep up with security patches when they drop support?

As for myself, my unraid box has been working swimmingly. I know that's no help to anyone still using Synology, but beyond using the latest image moving to another platform is your best bet.

[ChrisBaker97]

It is an LTS version with a six-year lifespan, but that started at the beginning of 2016...

https://www.kernel.org/category/releases.html

[neoKushan]

I was going by this: https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance which I found via https://en.wikipedia.org/wiki/Linux_kernel_version_history

16th LTS release, used in Slackware 14.2. [61]Canonical will provide extended support until April 2021.[62] As the first kernel selected for Super Long Term Support (SLTS), the Civil Infrastructure Platform will provide support until at least 2026, possibly until 2036.

I'm not 100% sure of the implications of SLTS, I wouldn't have thought it'd mean anything other than security fixes.

[the-lazy-fox]

Too bad :(
I hope DSM 7 might solve that. Does anyone tested the beta?

[ChrisBaker97]

When looking into this, I saw that people have been posting that the DSM 7 beta doesn't change the kernel version. It's locked to the hardware for some reason. What you get when it's new is what it'll be forever, unless Synology changes their past practice.

[binhex]

OK guys, no real point keeping this open at this time, but i will pin the issue.