Composingが公開されたCentOS Stream 10をのぞいてみた

こんにちは。ソリューションアーキテクトの橋本です。

2024/06/30をもって、Red Hat Enterprise Linux 7(RHEL7)のEnd of Maintenance(Extend Lifecycle Support 通称ELS提供中)、及びCentOS 7がEnd of Lifeを迎えました。 一方で、次のRHELのメジャーリリースであるRHEL10の開発が着々と進行しています。RHEL8以降、RHELは3年に1度メジャーリリースを行うようになりまして、RHEL8は2019年、現在最新のRHEL9は2022年のリリースです。 RHEL10はおそらく、その3年後、つまり来年2025年にリリースされると想定されます。

そうなんです。もう来年はRHEL10の年(予定)なんです。早いですよね。来年の話をするのが早すぎますかね...

CentOS Stream 10

さて、RHELの開発プロセスをよりオープンにするために、CentOS Streamが存在します。RHEL10の開発の状況も、ずいぶん前からCentOS Stream10としてソースコードが公開されています。 例えば、CentOS Stream 10で採用されるべく開発中のkernelのソースコードおよびrpm sources(spec, config, patches)はこちらにあります。

gitlab.com

gitlab.com

で、今日の本題です。先月、CentOSプロジェクトの開発者メーリングリストで、CentOS Stream 10のComposingの公開が始まったというアナウンスがありました。 現時点で、採用される各ソフトウェアおよびそのバージョンが確定しているわけではなく、ここからまだ追加、削除、変更が行われます。つまり、誰でもRHEL10の開発に参加できるチャンスです(キラキラ)

lists.centos.org

ちなみに、このcomposeというのは、リリースそのものではありません。単語としては"docker compose"なんかでよく目にするかもしれません。composeは「まとめる」といった意味で、FedoraやCentOS Stream,RHELの文脈ではたいてい「distroとして構成するものの実体を作成する」ことを指します。 狭義にはいわゆる(kernel+)システムの/以下の実体構成そのものを作成することを指すと言えますが、それを構成するrpmパッケージのビルド、リポジトリの配置、そしてその実体を使用したインストーラーiso, VMやコンテナイメージの作成なども含めて指すこともよくあります。

また、これらのrpmパッケージはまだCentOSプロジェクトとしてのすべてのgatingプロセスをすべて通過しているわけではないようです。これはどんな状態かを想像するために、こちらの資料にある絵を紹介します。

CentOS StreamとRHELのgating

https://archive.fosdem.org/2022/schedule/event/centos_stream_stable_and_continuous/attachments/slides/5182/export/events/attachments/centos_stream_stable_and_continuous/slides/5182/centos_stream_slides.pdf

このような、CentOS Stream自身が持っているプロセスをまだちゃんと通ってないということなのだと思います。まずはいったんdistroとして形を為すための仕組みを整えることが目的で、個々のパッケージの扱いについてはまだまだやわらかい状態だというのがイメージしていただけるんじゃないかと思います。

CentOS Stream 10をダウンロードしてみる

CentOS Stream 10のrpmパッケージやインストーラーiso, VMイメージは以下で公開されています。

composes.stream.centos.org

コンテナイメージはquay.ioで公開中です。(stream10-developmentタグ)

quay.io

たとえば「どんなパッケージが採用されているのかなぁ」とか見てみたければ、podmanなどを使ってコンテナイメージで気軽にサクっと見てみるとよいでしょう。ちなみに、上述のようなGitLabソースコードリポジトリの最新の状態と、実際にcomposeされた内容にはタイムラグ、先程のGatingプロセスなどがあるため、時間差が生じます。

[desktop] podman run --rm quay.io/centos/centos:stream10-development dnf info -q rust
Available Packages
Name         : rust
Version      : 1.77.2
Release      : 3.el10
Architecture : x86_64
Size         : 24 M
Source       : rust-1.77.2-3.el10.src.rpm
Repository   : appstream
Summary      : The Rust Programming Language
URL          : https://www.rust-lang.org
License      : (Apache-2.0 OR MIT) AND (Artistic-2.0 AND BSD-3-Clause AND ISC AND MIT AND MPL-2.0 AND Unicode-DFS-2016)
Description  : Rust is a systems programming language that runs blazingly fast, prevents
             : segfaults, and guarantees thread safety.
             : 
             : This package includes the Rust compiler and documentation generator.

動かしてみよう

では折角なのでVMを動かしてみようということで、GenericCloudイメージ(qcow2)を使ってどこのおうちにもあるOpenStackでインスタンスを起動してみました...が、起動してきません。ログを見てみました。

[    2.052368] usb 1-1: new full-speed USB device number 2 using uhci_hcd
[    2.068196] Running certificate verification selftests
[    2.069918] Loaded X.509 cert 'Certificate verification self-testing key: f58703bb33ce1b73ee02eccdee5b8817518fe3db'
[    2.076422] Unstable clock detected, switching default tracing clock to "global"
[    2.076422] If you want to keep using the local clock, then add:
[    2.076422]   "trace_clock=local"
[    2.076422] on the kernel command line
[    2.080929] clk: Disabling unused clocks
[    2.083695] Freeing unused decrypted memory: 2028K
[    2.086081] Freeing unused kernel image (initmem) memory: 4212K
[    2.087079] Write protecting the kernel read-only data: 30720k
[    2.088553] Freeing unused kernel image (rodata/data gap) memory: 1432K
[    2.129492] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[    2.130518] x86/mm: Checking user space page tables
[    2.168892] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[    2.169912] Run /init as init process
Fatal glibc error: CPU does not support x86-64-v3
[    2.171799] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
[    2.172677] CPU: 0 PID: 1 Comm: init Not tainted 6.8.0-0.rc3.20240209git1f719a2f3fa6.31.el10.x86_64 #1
[    2.172677] Hardware name: Red Hat OpenStack Compute/RHEL, BIOS 1.15.0-1.el9 04/01/2014
[    2.172677] Call Trace:
[    2.172677]  <TASK>
[    2.172677]  dump_stack_lvl+0x3c/0x50
[    2.172677]  panic+0x329/0x350
[    2.172677]  do_exit+0x4de/0x500
[    2.172677]  do_group_exit+0x2d/0x80
[    2.172677]  __x64_sys_exit_group+0x18/0x20
[    2.172677]  do_syscall_64+0x84/0x160
[    2.172677]  ? do_syscall_64+0x90/0x160
[    2.172677]  ? exc_page_fault+0x6b/0x150
[    2.172677]  ? entry_SYSCALL_64_after_hwframe+0x6e/0x76
[    2.172677]  </TASK>
[    2.172677] Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    2.172677] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 ]---

原因はこれです。

Fatal glibc error: CPU does not support x86-64-v3

既視感のある方もいらっしゃるかもしれません。glibcで策定しているCPUマイクロアーキテクチャレベル(glibc-hwcaps)のお話です。なんじゃそりゃ?という方はこちらの記事をご覧ください。

rheb.hatenablog.com

RHEL9ではx86_64-v2マイクロアーキテクチャが前提ですが、RHEL10ではそれをもう一段進めて、x86_64-v3マイクロアーキテクチャを前提とすることになりました。もちろん、CentOS Stream 10もx86_64-v3マイクロアーキテクチャを前提にビルドされています。詳しくはこちらをご覧ください。2013年ごろ以降発表(IntelならHaswell世代以降)のCPUを採用したマシンであれば、条件を満たします。

developers.redhat.com

もしこのあたりの活動に興味があれば、CentOS ISA SIGを覗いてみてください。

sigs.centos.org

ということで、おうちのOpenStackが動いているマシンがIvy Bridge EP世代で、x86_64-v2マイクロアーキテクチャまでしかサポートしていないため、起動しないのでした。 いやー仕方ないですねー。これはマシンを買いかえる必要がありますねー。仕方ないです。いやーそんなつもりはなかったんだけど仕方ないからなー(検索するキーボードの軽やかな音)

...はいすみません。話を戻します。CentOS Stream 10のイメージはAmazon EC2用も公開されていますので、こちらをAMIとしてインポートして、AWSで動かしてみましょう。 Amazon EC2でのイメージインポート手順は、RHEL8のドキュメントにジェネラルなイメージアップロード、スナップショットからのAMI登録の手順がありますので、参考になると思います。

docs.redhat.com

ちなみに、RHEL9ではcomposer-cli(image-builder)でのイメージビルド/アップロード手順に統一されていますので、RHEL10がリリースされたら、Image Builderでよりシンプルなイメージアップロード手順がドキュメントで出てくるんじゃないかと思います。

docs.redhat.com

イメージは、ここにある"CentOS-Stream-ec2-10-20240627.0.x86_64.raw.xz"を展開したrawイメージを使用しています。s3へのアップロード前にxzコマンドなどで展開していないと正しく処理できないのでご注意ください。

composes.stream.centos.org

ほぼ上記のドキュメント通りなのでざっくり書くと

  • イメージアップロード用のs3 bucketの準備 (aws s3 mb)
  • 必要なAWS IAMロールとポリシーの追加 (aws iam create-role/aws iam put-role-policy)
  • イメージのs3 bucketへの転送 (aws s3 cp)
  • s3 bucketに保存したイメージからEC2スナップショットへのインポート(aws ec2 import-snapshot)
  • スナップショットからAMIへの登録(aws ec2 register-image)
  • 作成したAMIからEC2インスタンスの起動

という感じです。sshでのログインはRHELと同じくec2-userで行います。

所感もろもろ

もちろんログインして普通のLinuxとして操作できます。パッケージがもりもり新しめのバージョンなので、操作するだけなら普通に新しめのLinuxです。 個人的には、動作環境はkernel 6.8, rust 1.77ですが、ソースコードリポジトリ上はもっとバージョンの高いカーネルで開発が行われているので、kernelのrustサポートとかどうなっていくのかなー、みたいなことを思いました。RHELのカーネルドライバをRustで書きたい、みたいな方がいたら早めに需要をissueにあげてもいいのかも。

ちなみに、Fedora EPEL SIGによるEL10向けの作業はこれからです。興味のある方はこのあたりをウォッチしてみるとおもしろいんじゃないかなと思います。

hackmd.io

定番のシステム情報を出そうと思ったのですが、EPELはこれからだったので、macchinaをCentOS Stream 10で提供されているRust 1.77.2でビルドしてみました。こんな感じです。

また、ちょっと弄っていて、RHEL7の途中から今まで提供されている、私がよく使っているストレージの圧縮と重複排除技術であるVDO(Virtual Data Optimizer)に関係するパッケージが存在しないことに気づきました。VDOはずっとout-of-treeのカーネルドライバだったのですが、kernel 6.9でめでたくLinusのツリーにマージされたので、このへんが変わるだろうなぁ、と気になっていたのです。この変更に伴ってFedoraからout-of-treeのドライバを提供していたパッケージが削除されたけど、CentOS Streamのカーネルモジュールのパッケージ側にはまだ入ってないのでcomposingで漏れる、みたいな、ちぐはぐな状況になっているようです。すでにRHELのVDOのパッケージメンテナは把握していたようなので、そのうち修正されそうです。

CentOS Stream 10/RHEL10の開発に参加してみよう!!

先述した通り、今のCentOS Stream 10の開発フェーズはかなりやわらかい状態です。こういう状態こそ、自分の使っている環境との差異を見つけ、修正するチャンスです。 特に今のうちに注目したほうがいいと個人的に思うのは、ソフトウェアの個々の品質そのものよりも、「RHEL8/9でこのパッケージ使ってたのになくなってる!!」とか「このパッケージの中に含まれてたこのファイルがなくなってる!?」みたいな、パッケージングそのものについてのチェックをして報告してあげたほうが有益かな、と思います。開発者はたくさんのユーザーがどのパッケージをよく使ってるのか、とか、実際の運用を知る術が限られますし、パッケージングの変更で誰も意識していなかったファイルがリストから落ちたりすることもありえます。もちろんソフトウェア自身の問題を早く見つけてパッチを送ってあげたり、よりupstreamで修正されていることを報告してあげると、積極的にrebaseもできるのでとてもナイスです。自分の環境での問題を報告して直せるオープンな場があることはとてもいいことですね!!

あと、先述の通りx86_64-v3マイクロアーキテクチャ対応のマシンが前提になりますので、たとえばお使いの仮想環境が対応した仮想マシンモデルタイプを提供しているか、実際に動作するか、といったチェックも今のうちにできることとしてよいのではないかと思います。

CentOS Projectへのコントリビューションについてはこのドキュメントを見るところから始めましょう。まずはissueを立てるところから。

docs.centos.org

ということで、CentOS Stream 10をガンガンチェックして、ぜひ一緒にRHEL10を作っていきましょう!!

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。