Kernel version upgrade required when manually updating discourse

Installation
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
26

I was about to upgrade an older forum and got the same error. Centos7 has not reached EOL yet, could you find an alternative solution for Ubuntu 14.04?

27

If you believe you are running the most up to date kernel from your OS supplier (with backported fixes) you might want to try bypassing the check. I know I would! This is the issue where the check was added. I believe could just remove or comment out the exit command in your ./launcher script, in this paragraph:

  # At least minimum version
  if compare_version "${kernel_min_version}" "${test}"; then
    echo "ERROR: Kernel version ${test} not supported, please upgrade to at least ${kernel_min_version}"
    exit 1
  fi

If, as a result, the upgrade still fails, then you will need to find a way to run your Discourse on a newer kernel.

(It’s quite possible this advice will be felt to be off-message, but I think what’s happened is that we have a check for a version number rather than a check for a facility (urandom), and that approach can give false positives.)

4 Likes
28

I’m running into this issue right now and our forum is down because of this. How can I edit the launcher script and comment out the kernel check (at least until Centos7 gets this update or we try to me the forum to another server)?

UPDATE:
I’ve succeeded (by trial and error) to update Launcher and instead of commenting the kernel out I just put a lower version as a requirement. It worked well.

Maybe this isn’t a good long-term solution but our hosting company already informed us that Centos7 won’t be getting the 4.4 kernel version… can someone explain what does this mean in practical terms?

1 Like
29

Looks like Centos 7 will get updates until mid-2024.

At some point - possibly before EOL - the ever-moving-forward Discourse will need something which Centos 7 doesn’t have, and you will need to upgrade your OS (or migrate to a new instance with a suitable OS version.) It looks like that point has not yet been reached.

As ever, before trying to update Discourse, now or in the future, take a backup of your forums and take a safe copy of that backup, as well as a safe copy of your app.yml file.

1 Like
30

What kernel are you running that is working with the rebuild you just did?

If it’s something lower than 4.4 and it’s working then, it sounds like @falco may need to reduce the required version again.

31

(Because distros will have back-ports of features and fixes from later kernels, a kernel version check is a very blunt instrument. I understand the idea of reducing support load, but there’s an opposite effect too when the safety check has a false positive. And as Discourse gets more popular, this problem gets bigger. Much better to check for a feature than for a version.)

2 Likes
32

Our system is running the following:

  • CentOS Linux release 7.9.2009 (Core)
  • Kernel 3.10.0-1160.88.1.el7.x86_64
1 Like
33

Updating this:
Although our forum is working now, we see this error more and more often:

Oops

The software powering this discussion forum encountered an unexpected problem. We apologize for the inconvenience.

Detailed information about the error was logged, and an automatic notification generated. We’ll take a look at it.

No further action is necessary. However, if the error condition persists, you can provide additional detail, including steps to reproduce the error, by posting a discussion topic in the site’s feedback category.

Can this be related somehow to the issue with the min kernel requirements? This “instability” (let’s called it this way) has been more noticeable in the last few days/weeks. It seems to come and go, some times the forum is ok, and some times it isn’t.

EDIT: Nevermind, I think this was related to a postgresql problem (having too many processes ongoing associated with images without a container, something that a launcher cleanup solved).

1 Like
34

I would be inclined to agree with this. Do you think this is a good idea @Falco?

1 Like
35

Yes, PR welcome to feature detect it properly.

2 Likes
36

Hi Falco,

I hit this issue when trying to update discourse from 3.1.0.beta2 to 3.1.0.beta4

This seemed like a minor upgrade but because of the kernel check the update was quite more involved on CentOS7. Maybe next time a different version number can better reflect the relatively high impact of changes.

Reading through the discussion I can’t really tell which feature check is actually necessary, maybe if you can elaborate on that someone is able to submit a PR.

1 Like
37

It’s in the post by @Ed_S:

On Ruby 3.1 there is a RuntimeException when calling Random.urandom on platforms where it’s not properly implemented, which includes people running Ubuntu 14.04 with kernel 3.13.