同じデータセンター内のドロップレット間で /var/discourse を rsync すると、ダウンタイムを最小限に抑えることができ、フォールバックは DNS のロールバックだけで済みます。
新しい VPS には Docker と、場合によってはスワップが必要です。
「いいね！」 2
こんにちは。
私もRed Hat Enterprise Linux 7で、カーネル3.10.0を実行していますが、同様のエラーが発生します。RHEL8はそれほど新しいカーネルを実行していません。
「いいね！」 1
私も同様です。CentOS7（3.10.0-1160.76.1.el7.x86_64）で3.1.0.beta1が正常に動作しています。
明らかに、ディストリビューションカーネルには多くのバックポートが含まれています。このようにバニラカーネルのバージョンを確認することは、他のプロジェクトでも問題を引き起こしています。コマンドラインからこのチェックをバイパスする方法はありますか？
—更新—
ランチャースクリプトを編集してチェックをバイパスしました。いくつかのCentOS7のインストールが問題なく更新されました。
「いいね！」 5
この問題はさらに詳しく調査されるのでしょうか？ システム要件にはカーネルバージョンは要求されておらず、CentOS 7/RHEL 7 はまだ EOL (End Of Life) ではありません。Docker もより新しいカーネルを必要としません。長期的に見て、チェックを وإلغاء (バイパス) するのは適切な解決策ではないと思います。
「いいね！」 2
古いフォーラムをアップグレードしようとしたところ、同じエラーが発生しました。CentOS7はまだEOLに達していませんが、Ubuntu 14.04の代替ソリューションを見つけることはできますか？
OSサプライヤーから提供された最新のカーネル（バックポートされた修正を含む）を実行していると思われる場合は、チェックをバイパスすることを検討してください。私ならそうします！これはチェックが追加されたイシューです。./launcherスクリプトのこの段落にあるexitコマンドを削除またはコメントアウトするだけでよいと思います。
# 少なくとも最小バージョン
if compare_version "${kernel_min_version}" "${test}"; then
echo "エラー: カーネルバージョン ${test} はサポートされていません。少なくとも ${kernel_min_version} にアップグレードしてください。"
exit 1
fi
その結果、アップグレードが引き続き失敗する場合は、Discourseを新しいカーネルで実行する方法を見つける必要があります。
（このアドバイスは的外れだと感じられる可能性が高いですが、バージョン番号をチェックするのではなく、機能（urandom）をチェックしているため、誤検知が発生する可能性があると考えています。）
「いいね！」 4
現在この問題に直面しており、フォーラムがダウンしています。ランチャースクリプトを編集してカーネルチェックをコメントアウトするにはどうすればよいですか（少なくともCentos7がこのアップデートを取得するか、フォーラムを別のサーバーに移行するまで）？
更新：
試行錯誤の結果、ランチャーを更新することに成功しました。カーネルをコメントアウトする代わりに、要件として低いバージョンを設定しました。これはうまく機能しました。
これは長期的な解決策ではないかもしれませんが、ホスティング会社からCentos7では4.4カーネルバージョンは提供されないとすでに通知されています…これは実際には何を意味するのか誰か説明してもらえますか？
「いいね！」 1
CentOS 7 は 2024 年半ばまでアップデートが提供されるようです。
いつか - おそらく EOL より前に - 常に進化し続ける Discourse は CentOS 7 にはないものを必要とするようになり、OS をアップグレードするか、適切な OS バージョンの新しいインスタンスに移行する必要が出てきます。現時点では、その時点には達していないようです。
これまでと同様に、Discourse のアップデートを試みる前には、必ずフォーラムのバックアップを取得し、そのバックアップの安全なコピーと app.yml ファイルの安全なコピーを作成してください。
「いいね！」 1
再構築がうまくいったカーネルは何ですか？
もし4.4より低いバージョンで動作しているなら、@falco は要求バージョンを再度下げる必要があるかもしれません。
（ディストリビューションには、後続カーネルの機能や修正のバックポートが含まれるため、カーネルバージョンのチェックは非常に大雑把な手段です。サポート負荷を軽減するという考えは理解できますが、安全チェックが誤検知した場合、逆効果になることもあります。また、Discourseの人気が高まるにつれて、この問題は大きくなります。バージョンをチェックするよりも、機能をチェックする方がはるかに良いでしょう。）
「いいね！」 2
当社のシステムは以下を実行しています。
- CentOS Linux release 7.9.2009 (Core)
- Kernel 3.10.0-1160.88.1.el7.x86_64
「いいね！」 1
これを更新します：
フォーラムは現在機能していますが、このエラーがますます頻繁に表示されます：
おっと
このディスカッションフォーラムを支えるソフトウェアで予期せぬ問題が発生しました。ご迷惑をおかけして申し訳ありません。
エラーに関する詳細情報が記録され、自動通知が生成されました。確認します。
追加のアクションは必要ありません。ただし、エラー状態が続く場合は、サイトのフィードバックカテゴリにディスカッションのトピックを投稿することで、エラーを再現する手順を含む追加の詳細を提供できます。
これは、最小カーネル要件の問題と何らかの関連があるのでしょうか？この「不安定さ」（このように呼びましょう）は、ここ数日/数週間でより顕著になっています。時々発生し、時々発生しないようです。フォーラムが良い時もあれば、そうでない時もあります。
編集：気にする必要はありません。これはPostgreSQLの問題（コンテナなしで画像に関連するプロセスが多すぎる、ランチャーのクリーンアップで解決されたもの）に関連していたようです。
「いいね！」 1
私もそう思います。これは良い考えだと思いますか @Falco？
「いいね！」 1
はい、適切にフィーチャー検出するためのPRを歓迎します。
「いいね！」 2
ファルコ様
Discourse を 3.1.0.beta2 から 3.1.0.beta4 にアップデートしようとした際に、この問題が発生しました。
これはマイナーなアップグレードのように見えましたが、カーネルチェックのため、CentOS7 ではアップデートはかなり複雑になりました。次回は、変更の比較的大きな影響をより適切に反映するために、別のバージョン番号を使用できるかもしれません。
議論を読みましたが、実際にどの機能チェックが必要なのかよくわかりません。もしよろしければ、詳しく説明していただけると、誰かが PR を提出できるかもしれません。
「いいね！」 1
@Ed_S さんの投稿にあります。
Ruby 3.1 では、適切に実装されていないプラットフォームで Random.urandom を呼び出すと RuntimeException が発生します。これには、カーネル 3.13 を使用する Ubuntu 14.04 を実行しているユーザーが含まれます。