Kernel version upgrade required when manually updating discourse

installation
5

It’s beyond end of life. I would spin up a new droplet and start fresh.

2 Likes
6

It’s a good check, but perhaps it could mention the possibility of the OS being out of date? The kernel is what’s wrong, but for most people it comes as part of an OS version.

I suspect, with Discourse having got ever more popular, each time a missing kernel feature becomes critical, the number of people affected will be much much greater.

1 Like
7

Ubuntu wiki says a sudo apt-get -s install --install-recommends linux-generic-hwe-16.04 will give you their latest supported kernel (4.15) after a reboot. I’d backup, download the backup locally and give it a try.

3 Likes
8

You mean it’s standard support is EOL or the actual version? The version check here shows EOL of 2026: Releases - Ubuntu Wiki

9

It’s 2026 if you have a Canonical subscription and 2021 otherwise. But that’s off-topic :smile:

1 Like
10

Thanks for the suggestion. I’ll back up and give this a try.

As a suggestion, maybe we should add your instructions for the check / get latest update of Kernel to the standard update instructions here: Manually update Discourse and Docker image to latest. As you are suggesting, looks like you’re getting a lot of support requests with regards to the Kernel not being up to date.

2 Likes
12

Thanks for the clarification

13

We hit the exact same blocker when trying to update this morning. Identical version numbers were also given in our error.

We’re also running the same Ubuntu 14.04 on Digital Ocean.

I’ll put some time aside in the coming days and power down the server, take a full snapshot as Falco suggests, then try:

I’m wondering how much time this will buy me though, before hitting the next blocker?

Would there be any reason to not just go all out and run a sudo apt-get dist-upgrade ?

Discourse is the only thing installed on my server.

In our case, yes, we are currently 3.1.0.beta1 - Commits · discourse/discourse · GitHub . We update to latest every two weeks.

14

So you are currently on 3.1.0.beta on kernel 4.4 ? If so I will relax the kernel check then.

1 Like
15

A uname -r produces:

4.4.0-210-generic

And confirmed re Discouse 3.1.0.beta :slight_smile:

1 Like
16

I’m still planning on upgrading the underlying Ubuntu tomorrow though :slight_smile:

17

Ubuntu upgrades nearly always work but they’re not quick, and your instance can be down for most of it. The snapshot will give you a means to roll back worst-case, but also adds downtime.

Have you considered just creating a new server on a more recent release and restoring a backup? Providing you’re using DNS with a relatively short TTL the downtime could be fairly brief, it will just come down to database size and whether your uploads are local.

1 Like
18

I personally haven’t (unsure about @AMK ) - only because it would take me longer to do everything that’d be required than it would to type a single update command in to the console :blush:

19

I actually haven’t tried creating a new server.
Like @Richie the only thing I have installed on the server is Discourse. And exactly, I would rather run a command to get the updates than having to do complete move to a new server.

I also checked my install version and looks like my site’s at version 3.0.0.beta16. When I click on upgrade I’m directed to “You are running an old version of the Discourse image” and that’s where I’m running into the Kernel version not supported error when try to do the update.

1 Like
20

@AMK (and anyone else interested!)

I powered down my Digital Ocean droplet and took a full snapshot (which took around 30mins).

I then ran do-release-upgrade and went from Ubuntu “16.04.7 LTS” to “18.04.6 LTS”

After the reboot, I checked Discourse - all ok.

I then did another release upgrade to take me beyond Ubuntu 18. Not sure which version it was going to, v20 maybe?

After that next reboot, my server never came back online :pensive:

I then had to restore my snapshot (which took 15mins), then I went from “16.04.7 LTS” to “18.04.6 LTS” again, then I updated Discourse.

Total time, 1hrs 50mins.

21

That’s why I suggested:

It may be “harder” but you can do it with near zero down time (and zero downtime if you create the new one in the same data center as the old one and use a static IP), and if something goes wrong, you can just switch back to the old server.

Probably, and you really want to be on 2022.04.

22

If you rsync /var/discourse between droplets in the same data center your downtime can be pretty minimal and your fallback is just a DNS reversion.

The new VPS only needs docker and potentially swap.

2 Likes
23

Hi,

I also get this error running Red Hat Enterprise Linux 7, running kernel 3.10.0. RHEL8 doesn’t run much newer.

1 Like
24

Same here, 3.1.0.beta1 running fine on CentOS7 (3.10.0-1160.76.1.el7.x86_64)

Obviously the distro kernels get a ton of backports. Checking the vanilla kernel version like this has been causing grief in other projects too. Is there a way to bypass this check from the command line?

—UPDATE—
I edited the launcher script to bypass the check - several CentOS7 installs updated without a problem.

5 Likes
25

Is this issue going to get more light? The system requirements do not require any kernel versions and Centos 7/RHEL 7 is not in EOL yet. Docker does not require a newer kernel either. I don’t think manually bypassing the check is the proper solution in the long term.

2 Likes