Slackware-currentのtestingに入ったkernel 7.0.xを導入する（ELILO編）
2026年6月14日
著者: 竹洞 陽一郎
2026年6月のslackware64-currentのChangeLogで、testing/packages/linux-7.0.x/以下にLinux kernel 7.0系が追加されました。
本体ツリー（a/、d/、k/）の標準カーネルが6.18.35である一方、testingでは一足先に7.0系を試せるようになっており、本稿執筆時点での最新は7.0.12です。
今回は、このtestingのkernel 7.0.12を、ELILOを使うUEFI環境へ、既存カーネルを残したまま並行導入する手順をご紹介します。
testingはあくまで「試せるが本番ではない」位置づけです。
本番環境をいきなり置き換えるのではなく、現行カーネルのブートエントリを残したまま新カーネルを追加し、起動を確認してから常用へ切り替える、という進め方が安全です。
本稿もその方針で、いつでも元のカーネルに戻れる状態を保ちながら進めます。
testingに追加されたパッケージ
testingのlinux-7.0.xディレクトリに用意されているのは、次の3本だけです。
kernel-generic-7.0.12-x86_64-1.txz kernel-headers-7.0.12-x86-1.txz kernel-source-7.0.12-noarch-1.txz
ここで注目すべきは、kernel-hugeも、独立したkernel-modulesも無いことです。
かつてのSlackwareは、多数のドライバを組み込んだhugeカーネル（initrd不要）と、モジュール構成のgenericカーネル（initrd前提）、そして別パッケージのkernel-modules、という構成でした。
しかし現在の-currentでは、本体ツリーの6.18.35も含めてhugeが廃止され、kernel-genericにモジュールが同梱される形へ一本化されています。
実際、kernel-generic-7.0.12が76MBほどあるのは、モジュールを内包しているためです。
（安定版の15.0はまだhuge/modulesが分かれているので、検索などで情報を集める際は混同しないよう注意して下さい。）
ただし、「generic一本になった＝必ずinitrdが要る」というわけではありません。
ルートファイルシステムへ到達するためのドライバがカーネルに組み込まれていれば、かつてのhugeと同じようにinitrd無しでも起動できます。
要るか要らないかは構成しだいなので、後述の手順で見極めます。
事前準備
本稿は、ブートローダにELILOを使うUEFI環境を前提とします。
説明を具体的にするため、ルートファイルシステムを/dev/nvme0n1p3（ext4）、EFIシステムパーティション（ESP）を/dev/nvme0n1p1（/boot/efiにvfatでマウント）とした構成を例に進めますが、デバイス名やファイルシステムはお使いの環境に読み替えて下さい。
方針として、現行カーネルのブートエントリは消さずに残します。
万一7.0.12で不具合が出ても、ブートメニューから従来カーネルを選べば確実に戻れるようにしておくためです。
パッケージの取得とインストール
国内ミラーのmirror.slackware.jpから、testingのlinux-7.0.x一式を取得します。
mkdir -p ~/linux-7.0.x && cd ~/linux-7.0.x BASE=https://mirror.slackware.jp/slackware/slackware64-current/testing/packages/linux-7.0.x wget $BASE/kernel-generic-7.0.12-x86_64-1.txz wget $BASE/kernel-headers-7.0.12-x86-1.txz wget $BASE/kernel-source-7.0.12-noarch-1.txz
インストールします。
genericは既存カーネルと共存させたいのでinstallpkgで追加し、headersとsourceは現行を置き換えてよいのでupgradepkgを使います。
installpkg kernel-generic-7.0.12-x86_64-1.txz upgradepkg --install-new kernel-headers-7.0.12-x86-1.txz upgradepkg --install-new kernel-source-7.0.12-noarch-1.txz
インストールすると、カーネル本体が/boot/vmlinuz-7.0.12として置かれ、/boot/vmlinuz-genericのシンボリックリンクがそこへ張り替えられます。
後述のブートエントリでは、この汎用リンクではなくバージョン付きの実体パスを指すようにします。汎用リンクを参照していると、次のカーネル導入時にリンクの指す先が変わり、意図せず別のカーネルを起動してしまうためです。
initrdは必要か、まず見極める
かつてのhugeカーネルがinitrd無しで起動できたのは、ルートファイルシステムへ到達するために必要なドライバ（ストレージのコントローラと、ルートのファイルシステム）がすべてカーネル本体に組み込まれていたからです。
裏を返せば、initrdが必要になるのは、それらがモジュールになっている場合に限られます。
モジュールならルートをマウントする前にinitrdの中で読み込んでおく必要がありますが、組み込みであればカーネル単体でルートに到達できるため、initrdは要りません。
まずはSlackware付属のジェネレータで、推奨されるmkinitrdコマンドを見てみます。
/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 7.0.12
例として、ルートがext4のNVMe（/dev/nvme0n1p3）という環境では、次のようなコマンドが提案されました。
mkinitrd -c -k 7.0.12 -f ext4 -r /dev/nvme0n1p3 \ -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:ext4 \ -u -o /boot/initrd.gz
よく見ると、ルートがNVMe上にあるにもかかわらず、-mのモジュール一覧にnvmeが含まれていません。
このスクリプトは「現在動いているカーネル」の組み込み／モジュールの構成を見て提案を作るため、ストレージドライバが（カスタムカーネルなどで）組み込みになっていると、「モジュールではない＝initrdに入れる必要なし」と判断します。
そこで、導入先の7.0.12 generic自身で、ルートのストレージとファイルシステムがモジュールなのか組み込みなのかを直接確認します。
モジュールならファイルが存在し、組み込みなら存在しません（以下はNVMe + ext4の例です。お使いの構成に合わせてパスを読み替えて下さい）。
ls /lib/modules/7.0.12/kernel/drivers/nvme/host/ ls /lib/modules/7.0.12/kernel/fs/ext4/ /lib/modules/7.0.12/kernel/fs/jbd2/
このNVMe + ext4の例では、nvme/host/にあったのはnvme-fabrics、nvme-fc、nvme-rdma、nvme-tcpといったNVMe over Fabrics（ネットワーク越しのNVMe）用のモジュールだけで、ローカルのPCIe NVMeドライバ本体であるnvme.koはありませんでした。
またext4とjbd2のディレクトリも空（存在しない）でした。
つまり、PCIe NVMeもext4も、generic 7.0.12には組み込み済みだったわけです。
このように必要なドライバがすべて組み込みであれば、initrdは不要です。
ELILOからvmlinuz-7.0.12を直接起動し、root=を渡すだけで、カーネル本体がそのままルートをマウントできます。
hugeが廃止された今でも、genericがルートに必要なドライバを組み込んでいれば、かつてのhugeと同じようにinitrd無しで起動できる、というわけです。
NVMe + ext4のような一般的なルート構成では、このパターンに当てはまることが多いはずです。
ルートがモジュール構成の場合（initrdが要るケース）
一方、ルートをLVM・LUKS暗号化・btrfs・mdadm RAIDなどの上に置いている場合や、ストレージコントローラやルートのファイルシステムがモジュールになっている場合は、それらを先に読み込むためのinitrdが必要です。
その場合は前述のジェネレータの提案をベースにしますが、提案はあくまで「現在のカーネル」基準である点に注意し、導入先のgenericで本当に必要なモジュールが-mに含まれているかを確認します。
ルートのファイルシステムやストレージドライバが導入先でモジュールなら、-mへ明示的に加えます（必要なドライバを先頭に足す、-fでファイルシステムを指定する、など）。
mkinitrd -c -k 7.0.12 -f ext4 -r /dev/nvme0n1p3 -m nvme:...:ext4 -o /boot/initrd-7.0.12.gz
作成後は、意図したモジュールが入っているかをcpioで確認しておくと安心です。
zcat /boot/initrd-7.0.12.gz | cpio -t 2>/dev/null | grep '\.ko'
ここにルートのマウントに必要なモジュールが含まれていれば、起動時に正しくルートへ到達できます。
以降のELILO設定では、このinitrdをESPへコピーし、スタンザにinitrd=の行を加えることになります。
ELILOへのエントリ追加
UEFI環境のELILOで注意すべきは、ローダ（elilo.efi）がカーネル（と、使う場合はinitrd）をEFIシステムパーティション（FAT）から読み込む点です。
ext4などのルート上にある/boot/vmlinuz-7.0.12はそのままではELILOから見えないので、ESP（例では/boot/efi/EFI/Slackware/）へコピーします。
initrdを使わない構成では、コピーするのはカーネル本体だけです。
将来のカーネル更新で上書きされないよう、バージョンを含む別名にします。
cp /boot/vmlinuz-7.0.12 /boot/efi/EFI/Slackware/vmlinuz-7.0.12
スタンザを追加する
elilo.confで、1つの起動エントリを表すまとまった設定ブロックを「スタンザ」と呼びます。
image=から始まり、それにぶら下がるlabel、append、read-onlyなどの行までが、1つのスタンザです。
冒頭のpromptやtimeoutなどは特定のカーネルに属さない全体共通の設定なので、スタンザの外、ファイルの先頭にまとめて置きます。
既存のスタンザ（従来カーネル）を残したまま、7.0.12用のスタンザを追加します。
initrdが不要な構成では、新しいスタンザにinitrd=の行を書きません。
編集後のelilo.confは次のようになります（root=はお使いの環境に合わせて下さい）。
prompt
chooser=simple
delay=30
timeout=100
default=vmlinuz
#
image=vmlinuz
label=vmlinuz
initrd=initrd.gz
read-only
append="root=/dev/nvme0n1p3"
#
image=vmlinuz-7.0.12
label=7012
read-only
append="root=/dev/nvme0n1p3"
（前章のようにinitrdを作った構成では、initrd-7.0.12.gzも同じESPへコピーし、7.0.12のスタンザにinitrd=initrd-7.0.12.gzの行を加えます。）
promptを忘れない
ここで重要なのが、先頭のpromptです。
ELILOはpromptが無いと選択画面を出さず、delayの経過後にそのままdefaultを起動します。
timeoutは「プロンプトが表示されている時の待ち時間」なので、promptが無ければtimeoutを長くしても意味がありません。
筆者は最初これを忘れ、せっかくスタンザを追加したのに起動時に何も出ず、従来カーネルが起動してしまいました。
promptを加えれば、起動時にELILO boot:が表示されます。
ここでTABキーを押すとラベル一覧（vmlinuzと7012）が表示されるので、7012と入力してEnterすれば、7.0.12 genericで起動します。
無入力のままtimeout（この例では10秒）が経過すると、defaultに指定した従来カーネルへ落ちるので、選択を誤っても安全です。
なお、EFI版のELILOは起動時にelilo.confを読み込みます。
LILOと違い、編集後にeliloコマンドを再実行する必要はなく、保存して再起動するだけで反映されます。
起動と動作確認
再起動し、ELILOのプロンプトで7012を選択して起動したら、まずカーネルのバージョンを確認します。
uname -r
7.0.12と表示されれば、新カーネルで起動できています。
続いて、新しいカーネルでGPUなどの主要なデバイスのドライバが正しくロードされているかを確認しておきます。
（dmesgが一般ユーザーで読めない場合は、kernel.dmesg_restrictが有効なのでsudoを付けます。）
たとえばAMD Radeon（amdgpu）環境なら、次のように確認します。
sudo dmesg | grep -i amdgpu | head
GPUが認識され、各IPブロックを検出してmodesettingを初期化している様子が見えれば正常です。
新しめのカードでは、PCI IDや世代（たとえばRDNA4世代のNavi 48なら0x1002:0x7550、gmc_v12やpsp_v14といったgfx12世代のIPブロック）が表示されます。
Intel GPUならi915またはxe、NVIDIAのオープンソースドライバならnouveauを、それぞれgrepのキーワードに置き換えて確認して下さい。
ファームウェアまわりにエラーが無いかも、念のため絞り込んで見ておきます。
sudo dmesg | grep -iE 'amdgpu|i915|xe|nouveau|\[drm\]' | grep -iE 'fail|error|timeout|firmware' ls -l /dev/dri/
fail、error、timeoutが出ず、ファームウェアが正常にロードされた旨の情報メッセージだけが見え、/dev/dri/にcard0とrenderD128が揃っていれば、カーネル／DRMレベルではGPUが完全に初期化できています。
なお、テキストコンソールやssh越しのシェルでglxinfoを実行するとunable to open displayと出ますが、これはGPUの問題ではありません。
そのシェルにX/WaylandのDISPLAYが無いためで、glxinfoはXサーバへ接続できないと描画情報を出せないだけです。
OpenGLのレンダラを確認したい場合は、グラフィカルセッションの中の端末から実行するか、Xを立てずに見たいならeglinfoを使います。
# グラフィカルセッション内で glxinfo | grep -i renderer # あるいはXなしで（mesa-demos同梱のeglinfo） eglinfo 2>/dev/null | grep -iE 'renderer|vendor' | head
ここでお使いのGPU名（AMD Radeon ...やMesa Intel ...など）が表示されれば、ユーザー空間のハードウェアアクセラレーションも効いています。
常用への切り替えとフォールバック
数日使ってみて、GPUまわりや普段の作業で問題が出ないことを確認できたら、elilo.confのdefaultを切り替えて常用カーネルにします。
# elilo.conf default=7012
これで無選択時も7.0.12で起動するようになります。
その際も、image=vmlinuz（従来カーネル）のスタンザは残しておきます。
testingのカーネルはバージョンが上がっていくので、次に7.0.13などへ更新する際も、「installpkg → ESPへvmlinuzを別名コピー → スタンザ追加」という同じ手順を踏めば、常に安全に並行運用できます。
（ルートがモジュール構成でinitrdを使っている場合は、ここにmkinitrdとinitrdのコピーが加わります。）
おわりに
testingにkernel 7.0系が入ったことで、Slackwareでもいち早く7.0系を実機で試せるようになりました。
今回の最大のポイントは、「generic＝必ずinitrd」と思い込まないことです。
hugeが廃止された今でも、ルートへ到達するためのストレージドライバとファイルシステムがカーネルに組み込まれていれば、initrdを作らずにgenericを直接起動できます。
NVMe + ext4のような一般的なルート構成では組み込み済みのことが多く、その場合はELILOからvmlinuz-7.0.12を指すだけのシンプルなスタンザで起動できます。
まずは導入先カーネルの構成を確認してinitrdが要るのか要らないのかを見極めること、そしてELILOではpromptを忘れないこと。
この2点を押さえれば、testingのカーネルも安全に並行導入できます。ぜひ一度7.0系の感触を確かめてみて下さい。