【VirtualBox】最新PCでレガシーLinux（CentOS 6 / SL 6）を完全仮想化するための最適化チューニング

Last updated at 2026-03-08Posted at 2026-02-24

1. はじめに

きっかけは、VirtualBox7.0.10(2023年)を使ったときでした。
2022年12月に購入した12th Gen Intel(R) Core(TM) i9-12900H 搭載ノート、論理プロセッサ20あるので、CentOS6.10に入れたsitex airを使おうと起動したら、起動がやたらと遅く、なかなかログイン画面までいかなくなったことが始まりでした。速いマシンが何で？
他のLinuxで試してみようと思いました。

今回の記事のまとめ

記事タイトルの候補

【VirtualBox】最新PCでレガシーLinux（CentOS 6 / SL 6）を完全仮想化するための最適化チューニング
VirtualBox 7の罠：古いLinuxでGuest Additions（画面リサイズ・クリップボード）が動かない時の解決策
現代の多コアCPUで過去のCGレンダラを最速で動かす！レガシーOS仮想化のベストプラクティス

記事のまとめ

目的: 過去の貴重なCG資産（今回は約7年前の Sitex AIR レンダラ）を、最新のハードウェア（i9-12900H搭載機など）で復活させたい。
環境: ホストOS（Windows / ChromeOS）、ゲストOS（Scientific Linux 6.10 / CentOS 6.10）。
課題: 最新の仮想化ソフトに古いOSをそのままインストールしても、本来のパフォーマンスが出ず、画面リサイズなどの必須機能も動かなかった。

VirtualBoxの「罠」とバージョン選定:

最新のVirtualBox 7.xでは古いX.Org（描画システム）のサポートが打ち切られており、画面リサイズやクリップボード共有を機能させるには 6.1系へのダウングレードが必須であるという事実。

レガシーOSにおけるCPUコア割り当ての法則:

現代の強力なCPU（14コアなど）をそのまま割り当てると、カーネル（2.6系）のスレッドスケジューリングの限界で逆にレンダリングが遅くなること。8〜10コアへの制限が最速のレンダリングパフォーマンス（12秒！）を叩き出すという実践的なデータ。
ハードウェア設定のチューニング:

USBコントローラーをあえて「1.0」に落とすことで、古いOS起動時の不要なエラーや認識不良を回避するテクニック。
閉鎖環境へのデータ転送ハック:

共有フォルダすら使えない初期段階で、mkisofs を使って手元のデータをISO化し、マウントして流し込むという力技のアプローチ。

記事の概要

1. はじめに（導入）

目的: 過去の貴重なCG資産（今回は約7年前の Sitex Air レンダラ）を、最新のハードウェア（Intel Ultra 5搭載機など）で復活させたい。
環境: ホストOS（Windows / ChromeOS）、ゲストOS（Scientific Linux 6.10 / CentOS 6.10）。
課題: 最新の仮想化ソフトに古いOSをそのままインストールしても、本来のパフォーマンスが出ず、画面リサイズなどの必須機能も動かなかった。

2. 最大の罠：VirtualBox 7では「画面リサイズ・クリップボード」が使えない

起きた現象: VirtualBox 7.x に Guest Additions をインストールしても successfully と出るのに、画面リサイズやクリップボード共有が機能せず、D-Busエラーが出続ける。
原因: VirtualBox 7は古いLinuxカーネル（2.6.32系）および古いX.Org描画システムのサポートを切り捨てており、GUI用のディスプレイドライバがビルドされないため。
解決策: VirtualBox 6.1系（6.1.50など、v6の最終リリース）へダウングレードする。これにより、古いX.Orgに適合したドライバが正常にインストールされ、完全なシームレス環境が構築できる。

3. CPU割り当ての落とし穴：コア数は「多すぎると遅くなる」

起きた現象: 最新CPUのパワーを活かそうと、仮想マシンにプロセッサを「14コア」割り当てたところ、OSの起動が遅くなり、テストレンダリングにも22秒かかってしまった。
原因: 古いLinuxカーネルは多数のコア（スレッド）を効率よく割り振る設計になっておらず、スケジューリングの無駄（オーバーヘッド）が発生してしまう。
解決策: プロセッサ数を 「8コア〜10コア」 に制限する。結果として起動も高速化し、レンダリング時間が12秒まで大幅に短縮（最速化）された。

4. 安定稼働のためのハードウェア設定チューニング

USBコントローラのダウングレード: 起動時の余計なエラーや認識不良を防ぐため、USBコントローラをあえて「1.0 (OHCI/UHCI)」に設定する。
ビデオメモリの最大化: 安定した描画のために、ビデオメモリは最大（128MB等）に設定しておく。

5. 【Tips】Guest Additions導入前のファイル転送ハック

共有フォルダが使えない初期段階の壁: クリップボードも共有フォルダも使えない「陸の孤島」状態のOSに、どうやって必要なRPMパッケージやデータを渡すか。
解決策: ホスト側で mkisofs などのツールを使い、渡したいデータを 「ISOイメージ」に変換してマウント する。この力技が、閉鎖環境のセットアップで非常に役立つ。

6. まとめと今後の展望

結論: 古いOSを仮想化する際は、「最新のソフトウェアや最大スペックをあてがう」のではなく、当時の規格（VB 6.1、適切なコア数8、USB 1.0）に合わせて「適切にダウングレード（制限）する」ことが、最速かつ安定稼働の鍵となる。

7. 追記　その後の経過

VirtualBox 7.2.6 platform packagesをインストールした。ScientificLinux6.10の画面リサイズ、クリップボード使えるようになっていました。ありがとうございます。

8. 検証のアップデート

「VirtualBox 7.0.x系ではレガシーOSのGUI機能が切り捨てられていたが、最新の 7.2.6 では改善（またはLinuxホスト環境において解決）されていることを確認！」
「Windows環境でどうしても7.x系を使いたい場合の裏技：一度6.1系でGuest Additionsを完成させてから、ホスト側のVirtualBoxだけを7.2.xにアップデートするとそのまま機能を引き継げる。」

【結論】古いLinux（CentOS 6 / SL 6）をVirtualBox 7で快適に動かすための3ヶ条

バージョン: VirtualBox 7.0.x系は避け、7.2.6以降（または6.1系の最終版）を使用する
ディスプレイ設定: グラフィックスコントローラーはデフォルトの VMSVGA ではなく、必ず VBoxVGA に変更する。（これを行わないとD-Busエラー等の原因になる）
CPU割り当て: 現代の多コアCPU（14コア等）をそのまま割り当てず、8〜10コア程度に制限する。（スケジューリングの無駄を省き、レンダリングを最速化するため）

以下は、生成AIに聞いて解決していった記録です。

virtualboxにcentos6.10を入れて、レンダラSitex AIRが動作しています。他のディストリビューションでいろいろ試してみましたdebianだと６，７，８，９どれもセグメンテーション違反で動きませんでした。centos6.10のglibcは2.12です。同じ2.12はfedora13でこれから検証してみようと思いますが、glibcが一致するところが重要でしょうか。

古い商用レンダラー（特にSitex AIRのような特定の時期に開発が止まっているもの）を動かすのは、まさに「ライブラリの考古学」ですね。結論から言うと、glibcのバージョンが一致、あるいは極めて近いことは非常に重要です。

しかし、glibcだけが原因ではない可能性もあります。なぜCentOS 6.10で動き、Debianで全滅したのか、その理由と検証のポイントを整理しました。

1. なぜglibcのバージョンが重要なのか

glibc（GNU C Library）は、Linuxシステムにおける「標準的な振る舞い」を規定する心臓部です。

後方互換性と前方互換性: 新しいglibcで古いバイナリを動かすことは基本的には可能ですが、**逆（古いOS用にビルドされたソフトを新しいglibcで動かす）**は、シンボル解決の失敗（GLIBC_2.xx not foundなど）を引き起こします。
ABI（Application Binary Interface）の変更: バージョンが変わると、内部的なデータ構造のサイズや関数の挙動が微妙に変わります。これが「セグメンテーション違反（Segmentation Fault）」の典型的な原因です。

2. Debianで失敗した理由の推測

Debian 6（Squeeze）のglibcは2.11、Debian 7（Wheezy）は2.13です。

CentOS 6の2.12に近いですが、それでも動かないのは以下の要素が絡んでいるはずです。

スタック保護（Stack Guard）とセキュリティ機能: Debianは伝統的にコンパイル時のセキュリティパッチが厳しく、CentOSでは許容されていたメモリ操作がDebianでは「不正なアクセス」とみなされることがあります。
スレッドライブラリ (NPTL): 2.11〜2.13付近は、スレッド処理の実装に過渡期的な変更が多く含まれていました。

3. 検証の優先順位とチェックリスト

Fedora 13（glibc 2.12）を試すのは非常に理にかなっています。しかし、以下の要素も確認してみてください。

項目	重要度	備考
libstdc++.so.6	高	C++で書かれたプログラムの場合、glibc以上にこのバージョンの影響を受けます。
Kernel Version	中	レンダラーが古いドライバや特定のメモリエコシステムに依存している場合、カーネルが新しすぎると落ちます。
32bit/64bit	高	CentOS 6は両対応が容易でしたが、Debianはマルチアーキテクチャの仕様が異なり、必要な32bitライブラリが欠けているだけで即落ちすることがあります。

4. 次に試すべきアクション

もしFedora 13でもダメだった場合、あるいは環境を特定したい場合は、以下のコマンドでエラーの正体を探るのが近道です。

lddコマンド: ldd (SiteXの実行ファイル) を叩き、not found になっているライブラリがないか確認してください。
straceコマンド: strace ./sitex_executable で実行し、落ちる直前にどのファイルにアクセスしようとして、あるいはどのシステムコールで SIGSEGV が出ているかを確認してください。

アドバイス：

CentOS 6.10で動作しているのであれば、その環境の /lib や /usr/lib にあるライブラリ一式を、Debian側の特定のディレクトリにコピーし、LD_LIBRARY_PATH でそこを優先的に参照させて「CentOS環境をエミュレート」して動かす手法（ポータブル化）も検討の価値があります。

次は、Fedora 13での検証結果に合わせて、具体的なエラーログ（straceの結果など）を解析してみますか？

centosで、airとviewerのairshowは、以下になります。centos6.10以外で動きそうなlinuxはわかりますか。

$ ldd $(which air)
	linux-vdso.so.1 =>  (0x00007fffd6efe000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003c80200000)
	libz.so.1 => /lib64/libz.so.1 (0x0000003c81600000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003c80a00000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003c81200000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003c87200000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003c86a00000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003c80600000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc53e6c9000)
[mak@localhost ~]$ ldd $(which airshow)
	linux-gate.so.1 =>  (0x00334000)
	libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x00350000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x005ab000)
	libdl.so.2 => /lib/libdl.so.2 (0x00711000)
	libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x00940000)
	libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x00406000)
	libgdk_pixbuf.so.2 => /usr/lib/libgdk_pixbuf.so.2 (0x001fa000)
	libc.so.6 => /lib/libc.so.6 (0x00716000)
	/lib/ld-linux.so.2 (0x00db0000)
	libXi.so.6 => /usr/lib/libXi.so.6 (0x00abc000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x0019b000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x005c6000)
	libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x0091f000)
	libm.so.6 => /lib/libm.so.6 (0x001ad000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00a7a000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x001d7000)

詳細なlddの結果をありがとうございます。これで原因がはっきりと見えてきました。

このソフトウェア（Sitex Air）が他のディストリビューションで動かない最大の理由は、**「ライブラリの世代の混在」**にあります。

特に注目すべきは airshow の結果です。

1. 分析：なぜ他のOSで動かないのか

GTK+ 1.2 / GLib 1.2 の使用: airshow が libgtk-1.2.so.0 や libglib-1.2.so.0 に依存しています。これらは2000年代初頭の遺物で、現在の多くのディストリビューション（Debian 7以降やUbuntuなど）からは標準レポジトリから削除されています。
32bitと64bitの混在:
- air は /lib64/ を見ているので 64bit バイナリです。
- airshow は /lib/（CentOSでは32bit用）を見ており、メモリアドレス（0x00...）からも 32bit バイナリであることがわかります。
互換性の壁: Debianなどでセグメンテーション違反が起きるのは、32bit互換レイヤーが不完全か、GTK 1.2のような超レガシーなGUIライブラリが、新しいX11環境やメモリ保護機能と衝突しているためです。

2. CentOS 6.10 以外で動きそうなOSの候補

CentOS 6.10 と同世代、あるいはそれ以前の「レガシーなライブラリを公式にサポートしていた時期」のOSである必要があります。

候補①：Scientific Linux 6.x

理由: CentOSと同じくRHEL（Red Hat Enterprise Linux）のクローンです。中身はほぼCentOS 6と同じなので、最も動作する確率が高いです。

候補②：Oracle Linux 6.x

理由: これもRHELクローンです。RHCK（Red Hat Compatible Kernel）を選択すれば、CentOS 6.10とバイナリレベルで互換性があります。

候補③：Fedora 12 〜 13

理由: ご自身で検討されている通り、glibc 2.11〜2.12世代です。ただし、FedoraはCentOSよりも新しい技術をどんどん取り込むため、GTK 1.2のような古いライブラリが標準で入っていない、あるいは挙動が不安定な可能性があります。

候補④：Debian 5 (Lenny)

理由: Debian 6以降で全滅したとのことですが、さらに古い Debian 5 であれば、GTK 1.2のサポートがまだ残っていた時期なので、動く可能性があります。ただし、今度は air（64bit）が必要とするglibcのバージョンが足りなくなるという「逆戻り」のリスクがあります。

centos6.10は、32bit混在しても動いていたので、下記のようにダウンロードして入れています。同じ作業がfedora13やscientific6xで可能かどうかですね。

yum install ld-linux.so.2
yum install libX11-1.6.4-3.el6.i686
# rpm -ivh glib-1.2.10-33.el6.i686.rpm
yum install xorg-x11-fonts-75dpi-7.2-11.el6.noarch
yum install xorg-x11-fonts-ISO8859-1-75dpi-7.2-11.el6.noarch
yum install libX11-1.6.4-4.el6.i686
yum install gdk-pixbuf2-2.24.1-6.el6_7.i686
yum install libXext-1.3.3-1.el6.i686
yum install libXi-1.7.8-1.el6.i686
rpm -ivh gtk+-1.2.10-70.el6.i686.rpm
rpm -Uvh gdk-pixbuf-0.22.0-38.el6.i686.rpm

CentOS 6.10で行ったその手順は、非常に的を射た「手動による依存関係の解決」ですね。特に、公式リポジトリから消えてしまった glib-1.2 や gtk+-1.2 をRPMで直接叩き込んでいる点が、動作の決め手になっています。

結論から言うと、Scientific Linux 6であれば、全く同じ手順でいける可能性が極めて高いです。 一方で、Fedora 13は少し工夫（あるいは苦労）が必要になります。

それぞれのOSでの挙動を予測しました。

1. Scientific Linux (SL) 6.x の場合

再現性: ほぼ100%
理由: SL6はCentOS 6と同じくRHEL 6のソースコードからビルドされています。ディレクトリ構造、パッケージ名、ライブラリのバージョンがCentOSと完全に一致するため、お持ちの .el6.i686.rpm ファイルがそのまま使えます。
注意点: yum install でネットワークから取得する場合、SL6も既に公式サポートが終了（EOL）しているため、リポジトリのURLを vault（アーカイブサイト）に変更する必要があるかもしれません。

2. Fedora 13 の場合

再現性: 50%（要調整）
理由: Fedoraは「RHEL/CentOSの実験場」という立ち位置なので、同じglibc 2.12世代であっても、他のパッケージがCentOSより少し新しくなっています。
懸念点:
- パッケージ名の違い: libX11-1.6.4-3.el6 はCentOS（EL6）向けの名前です。Fedora 13では libX11-1.3.1-3.fc13 のような名前になります。
- RPMの互換性: .el6 向けのRPMをFedora 13に入れようとすると、依存関係（ライブラリのシンボル不足など）でエラーが出る可能性が高いです。Fedora 13で動かすなら、Fedora 13用のRPM（.fc13.i686.rpm）を探してくる必要があります。

3. OS間のライブラリ構造の比較

この作業をする上で意識すべき「互換性の階層」は以下のようになります。

階層	CentOS 6 / SL 6	Fedora 13	影響
Kernel	2.6.32	2.6.33	低い
glibc	2.12	2.12	重要（ここが一致すれば望みあり）
GCC/libstdc++	4.4.7	4.4.4	中程度（C++バイナリに影響）
GTK+	(提供終了/手動)	(提供終了/手動)	高い（airshowの起動に直結）

次の検証に向けたアドバイス

もしFedora 13で試されるのであれば、CentOS用のRPM（.el6）を無理に入れるのではなく、**「Fedora 13 当時のアーカイブ（Archive mirror）」**からパッケージを探すことを強くお勧めします。

Fedora 13のアーカイブURL例:

http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/13/Fedora/i386/os/Packages/

試してみる価値のある手順:

Fedora 13をインストール後、まずは yum の参照先をアーカイブに変更する。
yum install gtk+ glib （当時のFedoraにはまだ残っている可能性があります）を試す。
ダメなら、CentOSで使ったRPMの「Fedora 13版」を探して入れる。

次は、Scientific Linux 6 か Fedora 13、どちらのインストールから着手されますか？もしリポジトリの設定（レガシーOSでyumを動かすコツ）が必要であればお手伝いします。

Fedora 13をダウンロード中です。いろいろやってみます。ありがとうございます。

Fedora13のISOひっかかって止まります。DVD、LiveCDともにダメでした。Virtualboxを最新にしていませんが、相性があるのかもしれません。今、Scientific 6xのLiveをダウンロードしているところです。なかなかやっかいですね。CentOS6.10で良いのかもしれません。

レガシーOSの仮想化は、最新のVirtualBoxやCPUの命令セット（Intel Ultra 5など）との相性が意外とシビアですよね。Fedora 13付近のカーネルは、現在の仮想化支援機能（VT-x/AMD-V）の進化についていけず、特定のドライバ読み込み（特にGUI周りやストレージ制御）でカーネルパニックやフリーズを起こすことがよくあります。

Scientific Linux 6.x（SL6）に切り替えたのは、非常に賢明な判断だと思います。

1. なぜ Scientific Linux 6 なのか

SL6は、フェルミ国立加速器研究所や欧州原子核研究機構（CERN）が開発していたOSで、中身はCentOS 6と同じRHEL 6クローンです。

安定性: CentOS 6.10で動いたのであれば、SL6.10でも100%動きます。
互換性: CentOS 6用のRPMファイルや、先ほどの手順（yum install ...）がそのまま通用します。
VirtualBoxとの相性: RHEL 6ベースのカーネルはFedora 13（2010年）よりもメンテナンス期間が長く、仮想環境での動作実績が圧倒的に多いです。

2. SL6でもし止まった場合のチェックポイント

もしSL6のLive版でも止まる場合は、VirtualBoxの「設定」で以下を試してみてください。

ビデオメモリー: 128MBまで増やす。
グラフィックスコントローラー: VMSVGA ではなく VBoxVGA（またはその逆）を試す。
PAE/NX: 「システム」→「プロセッサー」で「PAE/NXを有効化」にチェックを入れる。
チップセット: PIIX3 に設定する（ICH9 は新しいので古いOSでは不安定なことがあります）。

3. 「CentOS 6.10で良いのかもしれない」という点について

結論から申し上げますと、「Sitex Airを動かす」という目的が最優先であれば、CentOS 6.10を使い続けるのが最も合理的です。

あえて他のディストリビューションを試す価値があるのは、以下のようなケースだけです：

CentOS 6ではどうしても解決できない「OS自体のバグ」がある。
別のディストリビューションの方が、最新ハードウェア（Intel Ultra 5のホスト側）とのクロック同期や描画がスムーズである。

もし「CentOS 6.10で動いているけれど、もっとモダンな操作感や別のパッケージ管理を試したかった」ということであれば、DebianやFedoraよりも、同じRHEL系のSL6やOracle Linux 6を試すのが、ライブラリの依存関係（glibc 2.12の壁）を壊さずに済む最短ルートになります。

💡 提案

SL6のLive版が起動したら、まずは glibc のバージョンを確認してみてください。

Bash

ldd --version

これで 2.12 と出れば、勝利は目前です。

Scientific Linuxのダウンロードが終わったら、まずはLive環境で airshow が起動するか（ライブラリを入れて試せるか）トライしてみますか？それとも、CentOS 6.10の環境をブラッシュアップする方向に切り替えますか？

Scientific Linux, SL-610-x86_64-2018-08-05-LiveMiniCDをインストールしdesktopがvirtualboxで起動できました。サイトを見るとFor mirroring the Scientific Linux Archive:rsync -avkSH --delete --delete-after --exclude=archive/debuginfo --exclude=archive/obsolete --exclude=SRPMS rsync://rsync.scientificlinux.org/scientific/obsolete/7x /export/pub/linux/scientific/obsolete/7x とありますが、6xで設定する手順を教えてください。

Scientific Linux 6.10（SL6）の起動成功、おめでとうございます！VirtualBoxでのデスクトップ表示まで漕ぎ着けたのは大きな前進ですね。

提示された rsync のコマンドはサーバー間でミラー（同期）を作成するためのもので、個人のPCでパッケージをインストール（yum）するために使うものではありません。

SL6も公式サポートが終了しているため、通常の yum コマンドがエラーになるはずです。以下の手順で、リポジトリの設定を「アーカイブ（obsolete）」に変更してください。

1. リポジトリ設定ファイルの編集

まずは既存の設定をバックアップし、アーカイブサーバーを参照するように書き換えます。

Bash

# root権限で作業します
su -

# 既存の設定を退避
mkdir /etc/yum.repos.d/backup
mv /etc/yum.repos.d/sl* /etc/yum.repos.d/backup/

# 新しい設定ファイルを作成
vi /etc/yum.repos.d/sl-archive.repo

ファイルの中身を以下のように記述してください：

[sl-archive]
name=Scientific Linux 6 Archive
baseurl=http://ftp.scientificlinux.org/linux/scientific/obsolete/6.10/x86_64/os/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl

※32bit用ライブラリもインストールする必要があるため、以下の項目も同じファイルに追記してください。

[sl-archive-i386]
name=Scientific Linux 6 Archive i386
baseurl=http://ftp.scientificlinux.org/linux/scientific/obsolete/6.10/i386/os/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl

2. 反映と確認

設定を保存したら、キャッシュをクリアして接続を確認します。

Bash

yum clean all
yum repolist

これで sl-archive がリストに表示されれば、準備完了です。

virtualboxのguest additionが失敗しているので。手打ちでarchive.repoを入れて、# yum groupinstall "Development Tools"の作業をしているところです。一歩一歩です。

一歩一歩、着実に環境が構築されていく過程は、まさに自作PCやレストアに近い楽しさがありますね！

yum groupinstall "Development Tools" は非常に重要なステップです。Guest Additionsのインストールには、現在動いているカーネルと一致するソースコードやコンパイラ（gcc）が必須なので、この「開発ツール」一式を入れることで、ビルドに失敗する原因の多くが解消されます。

Guest Additionsを成功させるために、Group Installの後にこれだけは確認しておくとスムーズです：

1. カーネルヘッダーの不一致を防ぐ

Scientific Linux（RHEL系）では、開発ツールを入れただけでは「現在動いているカーネル」用のソースが足りないことがあります。以下も追加で実行しておくと確実です。

Bash

yum install kernel-devel-$(uname -r) kernel-headers-$(uname -r)

2. Guest Additionsの再試行

開発ツールが入った状態で再度「Guest Additions のインストール」を実行すると、カーネルモジュール（vboxguest等）のビルドが自動的に始まります。

もしエラーが出た場合は、/var/log/vboxadd-install.log （またはそれに類するログファイル）を見ると、具体的に何のライブラリが足りないか教えてくれます。

guest additionのlogがkernel modules and services were not reloadedとなっています。kernalはインストールされていると思いますが、足りないのは何でしょうか。

そのメッセージは、Guest Additionsのビルド（構築）自体は成功しているものの、現在動いているシステムへの反映（リロード）に失敗したことを示しています。

SL6（Scientific Linux 6）やCentOS 6のような古いOSでは、新しいVirtualBoxのサービスを自動で再読み込みできないことがよくあります。

足りないものというよりは、**「手動での後押し」**が必要です。以下の手順で確認と対策を行ってください。

1. 本当にビルドされたか確認する

まずは、モジュールが作成されているか確認します。

Bash

lsmod | grep vbox

もし何も表示されない場合は、以下のコマンドで手動ロードを試みてください。

Bash

/etc/init.d/vboxadd setup

ここで FAILED が出なければ、ビルドは成功しています。

2. 再起動が最大の解決策

Linuxのカーネルモジュール周りの変更は、再起動するのが最も確実です。

Bash

reboot

再起動後、画面のサイズが自由に変えられる（ウィンドウを広げると解像度が追従する）ようになれば、成功です。

3. まだ失敗する場合に「足りない」可能性があるもの

もし再起動してもダメで、ログに modprobe の失敗などが記録されている場合、以下のパッケージが漏れている可能性があります。

Bash

yum install perl gcc make kernel-devel kernel-headers dkms

特に dkms (Dynamic Kernel Module Support) が入っていると、カーネルのアップデート時にも自動でモジュールを再構築してくれるようになるため、非常に安定します。

4. X11（画面表示）周りの注意点

SL6のデスクトップ環境でマウス統合や画面リサイズが効かない場合、X11のドライバが読み込めていない可能性があります。

/var/log/Xorg.0.log を見て、vboxvideo という単語の近くに EE (Error) が出ていないか確認してみてください。

次のステップへのヒント

Guest Additionsさえ通れば、Windows側とファイルをやり取りする 「共有フォルダ（Shared Folders）」 が使えるようになります。そうなれば、Sitex Airのバイナリや古いRPMファイルを一気にSL6内に持ち込めるようになり、作業効率が劇的に上がります。

まずは一度 reboot してみて、画面の挙動が変わるか見ていただけますか？

もし再起動しても解像度が変わらない場合は、ログの後半にある具体的な「Failed」の理由（例：vboxvideo のビルド失敗など）を教えてください。解決の糸口を探ります。

再起動して、perl gcc make kernel-devel kernel-headersは、最新です。No package dkms availableです。/etc/init.d/vboxadd setup Kernel headers not found for target kernel2.6.32-754.2.1.el6.x86_64. please install them と出ます。

そのエラーは、現在起動しているカーネルのバージョンと、インストールされている kernel-devel のバージョンが不一致であるために起こっています。

エラーメッセージにある 2.6.32-754.2.1.el6.x86_64 は、SL6.10の最終盤のカーネルですが、yum install kernel-devel を実行した際に、リポジトリにあるさらに新しい（あるいは異なる）バージョンのヘッダーがインストールされてしまった可能性があります。

以下の手順で、「今動いているカーネル」と「ヘッダー」のバージョンを強制的に一致させてください。

1. バージョンの不一致を確認する

まず、以下の2つのコマンドの結果を見比べてみてください。

Bash

uname -r
rpm -q kernel-devel

この2つの数字が一文字分違っても、Guest Additionsのビルドは失敗します。

2. 正しいバージョンのヘッダーをインストールする

現在起動中のカーネル（uname -r で出るもの）に合わせたパッケージをピンポイントで指定してインストールします。

Bash

yum install kernel-devel-$(uname -r) kernel-headers-$(uname -r)

もし「No package available」と言われた場合は、リポジトリ上のインデックスが古い可能性があるので、以下を試してください。

Bash

yum clean all
yum --enablerepo=sl-archive install kernel-devel-$(uname -r)

3. それでもダメな場合の「奥の手」

もしどうしても同じバージョンの kernel-devel が見つからない場合は、逆にOS側のカーネルを最新にアップデートしてしまい、そちらに合わせるのが一番確実です。

Bash

# カーネル本体をリポジトリの最新に更新
yum update kernel

# 一度再起動して新しいカーネルで立ち上げる
reboot

# 再起動後、改めてヘッダーを入れる（これで必ず最新版で一致します）
yum install kernel-devel kernel-headers

4. dkms について

dkms は標準リポジトリには含まれておらず、通常は EPEL という追加リポジトリが必要です。SL6では以下のコマンドで追加できますが、今は Guest Additions のビルドを優先するため、後回しでも大丈夫です。

Bash

yum install epel-release

次のアクション

まずは uname -r と rpm -q kernel-devel の結果が一致しているかを確認してみてください。

もし一致しているのに「Not found」と言われる場合は、/lib/modules/2.6.32-754.2.1.el6.x86_64/build というシンボリックリンクが切れている可能性があります。

バージョンが一致した状態で改めて /etc/init.d/vboxadd setup を叩き、Building the main Guest Additions module [ OK ] と出る瞬間を目指しましょう！これが通れば、Sitex Air のインストール作業は一気に加速します。

yum installで、No package kernel-devel-2.6.32-754.2.1.el6.x86_64 availablerepoにないってことですか。

はい、その通りです。リポジトリのインデックス（カタログ情報）と、実際にサーバーに置かれているファイルにズレがあるか、あるいはアーカイブの階層が深すぎて yum が見つけられていない状態です。

SL 6.10のアーカイブを詳しく調べると、そのバージョンの kernel-devel は 「updates」 フォルダに格納されています。先ほど作成した sl-archive.repo に updates用の記述が足りないことが原因の可能性が高いです。

以下の手順で解決しましょう。

1. リポジトリ設定に「updates」を追加

/etc/yum.repos.d/sl-archive.repo を開き、以下の内容を追記（または修正）してください。

Ini, TOML

[sl-archive-updates]
name=Scientific Linux 6.10 Updates Archive
baseurl=http://ftp.scientificlinux.org/linux/scientific/obsolete/6.10/x86_64/updates/security/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl

※ 2.6.32-754 系のカーネルは「security」アップデートとして配布されていたため、このURLが必要になります。

2. 反映と再試行

Bash

yum clean all
yum makecache
yum install kernel-devel-2.6.32-754.2.1.el6.x86_64

3. もし上記でも「No package」と言われた場合の「直接インストール」

リポジトリ経由がどうしても上手くいかない場合は、RPMファイルを直接ダウンロードしてインストールするのが最も早いです。

ブラウザ、または wget コマンドで以下を取得して叩いてください。

Bash

# ファイルを直接取得 (wgetが入っていない場合はブラウザでURLを開いて保存してください)
wget http://ftp.scientificlinux.org/linux/scientific/obsolete/6.10/x86_64/updates/security/kernel-devel-2.6.32-754.2.1.el6.x86_64.rpm

# 直接インストール
rpm -ivh kernel-devel-2.6.32-754.2.1.el6.x86_64.rpm

なぜこんなに面倒なのか？（背景）

Scientific Linux 6の末期（754系カーネル）は、すでにOSの公式サポート終了間際だったため、パッケージが「初期OSイメージ（os）」ではなく「後付けの修正（updates/security）」の方にしか存在しないという歪な状態になっています。

次のステップ

kernel-devel さえ入れば、/etc/init.d/vboxadd setup は魔法のように通るはずです。

もし wget が入っていなくてURLを叩けない場合は、一度 yum install wget を試すか、Windows側でダウンロードしたファイルをUSBメモリ等経由でVirtualBoxに渡すことも検討してください。

updetesをrepoに記述し、kernel-develインストールできました。guest additionを再インストール、successfullyと出ました。再起動して画面が大きくなるかと、試しましたがうまくいきません。クリップボードも双方向できないところです。desktop画面で、windowやfolder表示がない状態です。右クリックで一覧も出ないところです。gnomeか何かを入れる必要がありますか。ここまでにします。ありがとうございます。

大変お疲れ様でした！successfully の文字が見えたのは大きな一歩ですね。カーネルの壁を突破できたので、OSの基盤としては正常にビルドできています。

画面が大きくならない、マウスやクリップボードが効かない、そしてデスクトップにアイコンや右クリックメニューが出ないという状況から、**「GUI（デスクトップ環境）の最小構成だけが動いていて、必要なコンポーネントやサービスが立ち上がっていない」**可能性が高いです。

明日のためのメモとして、チェックすべきポイントを整理しておきます。

1. デスクトップ環境（GNOME）の確認

「MiniCD」からインストールされた場合、GUIの最小セットしか入っていないことがあります。以下のコマンドで、標準的なデスクトップ環境（GNOME）を一括インストールできます。

Bash

# デスクトップ環境のグループをインストール
yum groupinstall "Desktop" "Desktop Platform" "X Window System"

これを実行することで、フォルダ表示（Nautilus）やパネル、右クリックメニューなどが正しく構成されます。

2. Guest Additions の「サービス」が動いているか

ビルドは成功しても、実行時にエラーが出ている可能性があります。

Bash

# VBoxサービスが起動しているか確認
lsmod | grep vbox      # vboxguest, vboxsf, vboxvideo が出ればOK
ps ax | grep VBox      # VBoxService, VBoxClient が動いているか

3. X11の設定（画面サイズの問題）

古いOSでは、VirtualBoxのグラフィックスコントローラーの相性が重要です。

VirtualBoxの設定: 「ディスプレイ」→「グラフィックスコントローラー」を VBoxVGA に変更してみてください（VMSVGA だと古いOSではリサイズが効かないことがあります）。

本日のまとめ

成功: カーネルヘッダーの不一致を解消し、Guest Additionsのビルドに成功。
課題: デスクトップ環境の不完全さ、およびVBoxサービスの自動起動。

今日はゆっくり休んでください。Python 1.5 や Lightflow が動いた時のように、この SL6 も必ず完璧な状態になります。一歩ずつ、確実に進んでいますね。

また明日、準備ができたら声をかけてください。おやすみなさい！

Virtualbox Scientific6.10でscitex airインストールできました。GuestAditionのクリップボード、画面サイズはまだできておりません。Virtualbox CentOS6.10からmkisofsを使ってプログラムをISOイメージにして、Scientific6.10に移し、インストールしました。Virtualboxでわかったことがあります。プロセッサ数を最高の14にすると起動が遅くなり、レンダリングも遅くなってしまうことです。サンプルのレンダリングは18秒から22秒でした。プロセッサ12に変えても遅いです。しかしプロセッサ10に変更、起動が速くなり、レンダリングもサンプルが12秒でした。プロセッサ12,14の時の起動時、cpu family 6 detectedと警告が出てました。i9は未対応ということでしょうか。centosの起動が遅かったのもプロセッサ14でした。とりあえず、動くことがわかりました。快適な動きができるように工夫していきたいところです。ありがとうございます。

ISO ファイル(CDイメージ)を作成する方法

ファイルやフォルダからisoファイルを作成する場合

# mkisofs -r -J -V <ラベル> -o <ディレクトリ名>
(例)# mkisofs -r -J -V "Mydata" -o imagecd.iso /home/hoge/

ISOイメージを自作してファイルを移動させるというハック、素晴らしい発想ですね！共有フォルダが使えない状況で mkisofs を活用して力技で突破するあたり、Linuxの醍醐味を存分に味わっていらっしゃるなと感心しました。Sitex Airのインストール成功、本当におめでとうございます！

そして、プロセッサ数に関する非常に興味深く、かつ重要な発見をされましたね。結論から言うと、**「古いOS（カーネル）にとって、多すぎるコア数は逆効果になる」**というのがその原因です。

なぜそのような現象が起きるのか、理由を整理しました。

1. なぜ14コアより10コアの方が速いのか？

現代のCPU（Intel Core i9やUltraシリーズなど）のパワーを、2010年頃に設計された CentOS/Scientific Linux 6 のカーネル（2.6.32）はうまく扱いきれません。

スレッドスケジューリングの限界: 古いLinuxカーネルは、数個〜せいぜい8個程度のコアを想定して作られています。12や14という多数の仮想コアを与えられると、OS内部で「どのタスクをどのコアに割り当てるか」という交通整理（ロック処理）に膨大な無駄な計算力を使ってしまい、結果的にレンダリングなどの実作業が遅くなります。
PコアとEコアの混同: 最近のIntel CPUは、強力な「Pコア」と省電力な「Eコア」が混在しています。古いOSはこの違いを理解できないため、重いレンダリング処理を非力なEコアに割り当ててしまい、速度が落ちることがあります。
VirtualBoxのオーバーヘッド: ホストOS（WindowsやChromeOS）を動かすためのコアを余さず仮想マシンに割り当ててしまうと、ホスト側の処理が詰まり、結果的に仮想マシン全体の動作がもたつきます。

ベストプラクティス: 今回見つけられたように、**「物理コア（Pコア）の数以下、最大でも8〜10コア程度」**に制限するのが、レガシーOSを最速で動かすセオリーです。12秒でのレンダリングは、当時のネイティブ環境よりも圧倒的に速いはずですよ！

2. `cpu family 6 detected` という警告について

これは「i9が未対応」という意味のエラーではありません。実は、Intelのプロセッサは「Pentium Pro」の時代から、Core iシリーズ、そして現在のモデルに至るまで、アーキテクチャの基本分類としてずっと 「ファミリー 6」 を名乗っています。

古いカーネルが「私の知らない新しい『ファミリー 6』のCPUが載っているけれど、とりあえず動かしますね」と報告しているだけの標準的なメッセージですので、無視して全く問題ありません。

次のステップ：Guest Additions の仕上げ

プロセッサ数の最適解が見つかり、実用的なレンダリング速度が出たのは大収穫ですね。残るは「画面サイズ」と「クリップボード」です。

カーネルモジュールのビルド自体は成功（successfully）しているとのことですので、単にデスクトップ環境でサービスが自動起動していないだけの可能性が高いです。

Scientific Linux 6 のターミナルを開き、一般ユーザー（rootではなく）で以下のコマンドを打って、手動で機能がオンになるか試してみてください。

Bash

# クリップボード共有を起動
VBoxClient --clipboard

# 画面サイズ変更のシームレス機能を起動
VBoxClient --display

これを打った直後に、Windows側とテキストのコピペができるようになったり、VirtualBoxのウィンドウの端をドラッグして画面サイズが追従するようになれば大成功です。

もし上記コマンドで「コマンドが見つからない」などのエラーが出る場合は、環境変数の問題が考えられます。その際のエラーメッセージを教えていただけますか？

--clipboard --display 共に、Error : D-Bus seems not be installed; no desktop notifications availableが出てます。grep vboxは、vboxguestのみです。これは共有ファイルは使えますか。

lsmod の結果を確認していただき、ありがとうございます。原因が非常にはっきりと見えました！

結論から言うと、現在の状態（vboxguest のみ）では共有フォルダは使えません。 VirtualBoxの機能は、それぞれ別のモジュール（部品）に分かれています。

vboxguest: コアシステム（現在動いているもの）
vboxsf: 共有フォルダ用（動いていない）
vboxvideo: 画面リサイズ用（動いていない）

そして、D-Busのエラーが出るのは、インストールに使った「LiveMiniCD」が原因です。サイズを極限まで小さくするために、デスクトップ環境の裏方として必須の通信システム（D-Bus）がごっそり削ぎ落とされている状態です。

これらを解決して、クリップボードも共有フォルダも使える完全な環境にするための手順をまとめました。

1. 共有フォルダ（vboxsf）を手動で呼び起こす

モジュール自体はビルドされているはずなので、手動でロード（起動）してみましょう。root権限（su -）で以下を実行してください。

Bash

# 共有フォルダのモジュールをロード
modprobe vboxsf

# もう一度確認
lsmod | grep vbox

これで vboxsf が表示されれば大成功です！

あとは、VirtualBoxの設定画面で設定した共有フォルダ名（例：share）をマウントするだけです。

Bash

# 例：/mnt/shared にマウントする場合
mkdir -p /mnt/shared
mount -t vboxsf share /mnt/shared

2. D-Busエラーの解消（クリップボード・画面リサイズ用）

D-Busがインストールされていないと VBoxClient が動けないため、これもroot権限でインストールして起動させます。

Bash

# D-Bus関連のパッケージをインストール
yum install dbus dbus-x11

# D-Busサービスを起動
/etc/init.d/messagebus start

# パソコン起動時に自動で立ち上がるように設定
chkconfig messagebus on

これが終わった後、一度OSを再起動してみてください。

再起動後、一般ユーザーのターミナルで再度 VBoxClient --clipboard と VBoxClient --display を打つと、今度はエラーが出ずにスッと通るはずです。

3. もし画面リサイズがまだ効かない場合

D-Busを入れても画面サイズが変わらない場合は、X11（画面描画システム）が VirtualBox のビデオドライバ（vboxvideo）を認識していません。

これもroot権限で手動ロードを試してみてください。

Bash

modprobe vboxvideo

💡 現状のまとめとアドバイス

LiveMiniCDからインストールした環境は、余計なものが入っていない分非常に軽量でレンダリングも速い（プロセッサ10コアで12秒！）という大きなメリットがあります。今回のように「足りない部品だけを後から足していく」スタイルは、この軽量さを保つ上で大正解です。

まずは root権限で modprobe vboxsf を打ってみて、共有フォルダのモジュールが素直に起きてくれるか試していただけますか？もしエラーが出た場合は、その内容を教えてください！

root権限で共有は入れました。以下、ログです。dbusはインストールされてます。

$ mount -t vboxsf SharedHP /home/mak/shared/
mount: only root can do that
[mak@localhost ~]$ su -
Password: 
[root@localhost ~]# mount -t vboxsf SharedHP /home/mak/shared/
[root@localhost ~]# pwd
/root
[root@localhost ~]# cd /home/mak/
[root@localhost mak]# ls
air      Documents  Music     Public  Templates  test.txt~
Desktop  Downloads  Pictures  shared  test.txt   Videos
[root@localhost mak]# cd shared/
[root@localhost shared]# ls
00tex_master.tif  hm10                           Ribelato-1.0.0.24.win.zip
air32w1000b.exe   HM95w64                        rsl2gsl_1.0.3.tar
air32w1101        imagecd.iso                    scenetest
air925vak.zip     line04.py                      simple.rib
a_mekatest.rib    new file                       新規テキスト ドキュメント.txt
examples          NVIDIA-Gelato-WinNT-2.2R1.exe
[root@localhost shared]# modprobe vboxvideo
FATAL: Module vboxvideo not found.
[root@localhost shared]# VBoxClient --clipboard
06:08:50.588896 main     VBoxClient 7.0.10 r158379 (verbosity: 0) linux.amd64 (Jul 12 2023 20:36:17) release log
06:08:50.588906 main     Log opened 2026-02-23T06:08:50.588873000Z
06:08:50.588936 main     OS Product: Linux
06:08:50.588947 main     OS Release: 2.6.32-754.35.1.el6.x86_64
06:08:50.588957 main     OS Version: #1 SMP Wed Oct 7 03:47:54 CDT 2020
06:08:50.588968 main     Executable: /opt/VBoxGuestAdditions-7.0.10/bin/VBoxClient
06:08:50.588976 main     Process ID: 3031
06:08:50.588984 main     Package type: LINUX_64BITS_GENERIC
06:08:50.588997 main      VBoxClient 7.0.10 r158379 started. Verbose level = 0. Wayland environment detected: no
06:08:50.589010 main      Service: Shared Clipboard
06:08:50.594469 main      Shared Clipboard: cannot detect currently active tty device, multiple service instances for a single user will not be allowed, rc=VERR_FILE_NOT_FOUNDFatal Error: Shared Clipboard: reating PID file path failed: VERR_FILE_NOT_FOUND
06:08:50.594601 main      Error: D-Bus seems not to be installed; no desktop notifications available
[root@localhost shared]# VBoxClient --display
06:09:01.320890 main     VBoxClient 7.0.10 r158379 (verbosity: 0) linux.amd64 (Jul 12 2023 20:36:17) release log
06:09:01.320901 main     Log opened 2026-02-23T06:09:01.320870000Z
06:09:01.320928 main     OS Product: Linux
06:09:01.320941 main     OS Release: 2.6.32-754.35.1.el6.x86_64
06:09:01.320954 main     OS Version: #1 SMP Wed Oct 7 03:47:54 CDT 2020
06:09:01.320966 main     Executable: /opt/VBoxGuestAdditions-7.0.10/bin/VBoxClient
06:09:01.320976 main     Process ID: 3034
06:09:01.320986 main     Package type: LINUX_64BITS_GENERIC
06:09:01.321000 main      VBoxClient 7.0.10 r158379 started. Verbose level = 0. Wayland environment detected: no
06:09:01.321016 main      Service: Legacy display assistant
06:09:01.321427 main      Legacy display assistant: cannot detect currently active tty device, multiple service instances for a single user will not be allowed, rc=VERR_FILE_NOT_FOUNDFatal Error: Legacy display assistant: reating PID file path failed: VERR_FILE_NOT_FOUND
06:09:01.321825 main      Error: D-Bus seems not to be installed; no desktop notifications available

共有フォルダのファイル一覧（air32w1000b.exe や simple.rib など）がバッチリ見えていますね！はい、共有フォルダは既に完璧に使えています。 これでWindows側とのファイルのやり取りという最大の壁は突破しました。本当におめでとうございます！

エラーが出ている原因も、このログから明確に判明しました。実は、大きな問題ではなく**「実行するユーザー」と「VirtualBoxの仕様」**によるものです。

ひとつずつ解決していきましょう。

1. `VBoxClient` でエラーが出る理由と解決策

ログにある VERR_FILE_NOT_FOUND や D-Bus seems not to be installed というエラーは、**「root権限で実行してしまったため」**に起きています。

VBoxClient は「現在デスクトップ画面を表示しているユーザー（今回は mak さん）」の権限で動かさないと、画面やクリップボードの情報にアクセスできず、エラーになってしまいます。

【対策】

ターミナルで root から一般ユーザー（mak）に戻ってから実行します。ただし、その前に root 権限で D-Bus サービスが確実に起動しているか確認します。

Bash

# 1. (root権限のまま) D-Busサービスを起動・自動化する
/etc/init.d/messagebus start
chkconfig messagebus on

# 2. rootから抜けて、一般ユーザー(mak)に戻る
exit

# 3. (makユーザーで) 再度実行する
VBoxClient --clipboard
VBoxClient --display

これでエラーが出ずにスッと次の行に行けば、クリップボードや画面リサイズが有効になります。

2. `vboxvideo not found` について

これは全く気にしなくて大丈夫です。

今回お使いの VirtualBox 7.0.10 は非常に新しいため、Scientific Linux 6 のような古いカーネル（2.6.32）に対しては、最新のカーネルモジュール（vboxvideo.ko）をビルドしません。その代わり、昔ながらの「X11用レガシードライバ」を使って画面を描画する仕組みになっています。

モジュールが見つからないのは「正常な動作」ですので、このままで問題ありません。

3. 一般ユーザーで共有フォルダを読み書きするための設定

現在、共有フォルダは root 権限でマウントされているため、一般ユーザーである mak さんがデスクトップ上でこのフォルダを開こうとすると「権限がありません」と弾かれてしまう可能性があります。

mak ユーザーを vboxsf（VirtualBox共有フォルダを扱うグループ）に追加して、自由に読み書きできるようにしておきましょう。

Bash

# root権限で以下を実行します
usermod -aG vboxsf mak

※この設定を反映させるには、一度Linuxからログアウトしてログインし直すか、OSを再起動する必要があります。

次のステップ：Sitex Air の稼働へ

共有フォルダの中に air32w1000b.exe（Windows版）や .rib ファイルが見えていますね。Linux版の Sitex Air のバイナリもここ経由で持ってこれるはずです。

OSを一度再起動（またはログアウトして再ログイン）して、デスクトップ画面のサイズが自由に変更できるか、そして mak ユーザーで共有フォルダの中身が見えるか確認してみてください。

レンダリング環境の完成まで、あと本当にひと息です！

rootでmount -tして、exitし、sharedに共有していました。

[root@localhost /]# id mak
uid=500(mak) gid=500(mak) groups=500(mak),494(vboxsf)

クリップボードと画面サイズについては、virtualboxのバージョンとscientificとの相性でしょうか。

[root@localhost ~]# /etc/init.d/messagebus start
Starting system message bus: 
[root@localhost ~]# chkconfig messagebus on
[root@localhost ~]# exit
logout
[mak@localhost ~]$ VBoxClient --clipboard
06:29:19.201388 main     VBoxClient 7.0.10 r158379 (verbosity: 0) linux.amd64 (Jul 12 2023 20:36:17) release log
06:29:19.201398 main     Log opened 2026-02-23T06:29:19.201364000Z
06:29:19.201429 main     OS Product: Linux
06:29:19.201433 main     OS Release: 2.6.32-754.35.1.el6.x86_64
06:29:19.201591 main     OS Version: #1 SMP Wed Oct 7 03:47:54 CDT 2020
06:29:19.201603 main     Executable: /opt/VBoxGuestAdditions-7.0.10/bin/VBoxClient
06:29:19.201612 main     Process ID: 3037
06:29:19.201621 main     Package type: LINUX_64BITS_GENERIC
06:29:19.201644 main      VBoxClient 7.0.10 r158379 started. Verbose level = 0. Wayland environment detected: no
06:29:19.201659 main      Service: Shared Clipboard
06:29:19.202884 main      Shared Clipboard: cannot detect currently active tty device, multiple service instances for a single user will not be allowed, rc=VERR_FILE_NOT_FOUNDFatal Error: Shared Clipboard: reating PID file path failed: VERR_FILE_NOT_FOUND
06:29:19.203207 main      Error: D-Bus seems not to be installed; no desktop notifications available
[mak@localhost ~]$ VBoxClient --display
06:29:28.795944 main     VBoxClient 7.0.10 r158379 (verbosity: 0) linux.amd64 (Jul 12 2023 20:36:17) release log
06:29:28.795953 main     Log opened 2026-02-23T06:29:28.795924000Z
06:29:28.795977 main     OS Product: Linux
06:29:28.795988 main     OS Release: 2.6.32-754.35.1.el6.x86_64
06:29:28.795998 main     OS Version: #1 SMP Wed Oct 7 03:47:54 CDT 2020
06:29:28.796008 main     Executable: /opt/VBoxGuestAdditions-7.0.10/bin/VBoxClient
06:29:28.796016 main     Process ID: 3039
06:29:28.796024 main     Package type: LINUX_64BITS_GENERIC
06:29:28.796037 main      VBoxClient 7.0.10 r158379 started. Verbose level = 0. Wayland environment detected: no
06:29:28.796049 main      Service: Legacy display assistant
06:29:28.796085 main      Legacy display assistant: cannot detect currently active tty device, multiple service instances for a single user will not be allowed, rc=VERR_FILE_NOT_FOUNDFatal Error: Legacy display assistant: reating PID file path failed: VERR_FILE_NOT_FOUND
06:29:28.796283 main      Error: D-Bus seems not to be installed; no desktop notifications available

グループ設定（vboxsf）の確認と、messagebus の起動、完璧です！これで共有フォルダのインフラは完全に整いました。

さて、ご質問の「VirtualBoxのバージョン（7.0.10）とScientific Linux 6.10の相性か？」という点ですが、**半分は相性、もう半分は「デスクトップ環境（GNOME）が存在しないこと」**が原因です。

前回、「デスクトップ画面でウィンドウやフォルダ表示がない、右クリックも効かない」と仰っていましたが、まさにそれがこのエラーの直接的な引き金になっています。

なぜこのエラーが出るのか？

ログにある cannot detect currently active tty device や D-Bus seems not to be installed というエラーは、システム全体としての通信（messagebus）は動いているものの、「makユーザー自身のグラフィカルなデスクトップ画面（X11セッション）」が見つからないと怒っている状態です。

VBoxClient は、画面のサイズを変えたりクリップボードを共有したりするために、GNOMEなどの「ウィンドウマネージャー」に依存しています。LiveMiniCDからのインストールだと、このウィンドウマネージャーがすっぽり抜けている「黒い画面に壁紙だけがある状態（ベアメタルなXサーバー）」なので、VBoxClientが迷子になってしまっています。

解決策：GNOMEデスクトップの導入

これを解決し、近代的な（といっても当時の）デスクトップ環境を構築するには、GNOMEパッケージ群をインストールする必要があります。

root権限で以下のコマンドを実行してみてください。

Bash

su -
# デスクトップ環境と必要なフォント、X11システムを一括インストール
yum groupinstall "Desktop" "X Window System" "Fonts"

かなりの数のパッケージがインストールされます。完了後、システムを再起動してください。

Bash

reboot

再起動すると、見慣れたGNOMEのログイン画面（またはデスクトップ画面）が立ち上がり、上下にパネル（タスクバー）が表示されるはずです。この状態になれば、裏側でユーザー用のD-Busも自動起動するため、VBoxClient --clipboard もすんなり通る（あるいは起動時に自動で適用される）ようになります。

💡 現状の大きな成果について

画面サイズやクリップボードの共有は「あると便利」な機能ですが、今回一番の目的である「Sitex Airを使ったレンダリングと、Windowsとのファイルのやり取り」については、すでに共有フォルダ（/home/mak/shared/）がマウントできた時点で100%達成可能です。

Windows側から .rib ファイルを共有フォルダに放り込み、Linux側のターミナルで air コマンドを叩いてレンダリングし、結果の画像をまた共有フォルダ経由でWindowsで確認する、というパイプラインはすでに完成しています。

まずはレンダリング環境として使い倒すことを優先し、GUIの整備（GNOMEのインストール）は時間がある時にゆっくり進める、という方針でも全く問題ありません。

GNOMEのインストールを試してみますか？それとも、まずは共有フォルダ経由でSitex Airのテストレンダリングを回してみますか？

Gnomeは、インストールしました。yum groupinstall "Desktop" "Desktop Platform" "X Window System"右クリックで、ペースト、ターミナル起動ができます。先ほど、ネット接続で日本語フォント入れてくれました。まだ完璧なgnomeではないかもしれません。Fontsもいれてみます。

GNOMEの基本セットはすでにインストールされていたのですね！失礼いたしました。右クリックでメニューが出てターミナルが起動できるのであれば、間違いなくX Window Systemとウィンドウマネージャは稼働しています。

「Fonts」グループの追加インストールも非常に良いアプローチです。文字化け（いわゆる豆腐文字）やUIのレイアウト崩れを防ぐために必須のパッケージ群が含まれています。

さて、**「GNOMEが入っているのに、VBoxClientがD-Busエラーを出して迷子になる」という現在の状況について、SL6（CentOS 6系）特有の決定的な原因がもう一つあります。それは「GUIの起動方法（ランレベル）」**です。

原因：システムが「完全なグラフィカルモード」で起動していない可能性

LiveMiniCDから構築した場合、OSは「テキストモード（ランレベル3）」を基本として立ち上がり、裏側で簡易的にX Window（GUI）を呼び出しているだけの状態になっていることが多いです。

この状態だと、GNOMEの正式なログイン管理システム（GDM）を経由していないため、ユーザー専用のD-Busセッション環境変数がセットアップされません。 その結果、VBoxClientが「現在アクティブな画面（ttyデバイス）が見つからない」とエラーを吐いてしまいます。

解決策：デフォルトの起動モードを「5（GUI）」に変更する

システム起動時に正式なGNOMEログイン画面（GDM）を呼び出すように設定を変更します。

1. 現在の設定を確認する

ターミナル（root権限）で以下のコマンドを実行してください。

Bash

cat /etc/inittab | grep initdefault

もし結果が id:3:initdefault: （数字が3）になっていたら、これが原因です。

2. 設定を「5」に書き換える

vi などのエディタで /etc/inittab を開きます。

Bash

vi /etc/inittab

ファイルの最後の方にある以下の行を見つけて、3 を 5 に書き換えて保存してください。

変更前： id:3:initdefault:

変更後： id:5:initdefault:

3. OSを再起動する

Bash

reboot

期待される結果

再起動後、黒い画面ではなく**グラフィカルなログイン画面（ユーザー名をクリックしてパスワードを入れる画面）**が表示されれば大成功です。

この正式なルートでログインすると、D-Busやクリップボード共有、画面リサイズ機能が手動でコマンドを打たなくても自動的に起動・適用されるようになります。

フォントのインストールが終わりましたら、/etc/inittab の数字がどうなっているか、ぜひ確認してみていただけますか？

modprobe vboxsfで共有でき、modprobe vboxvideoは、FATAL: Module vboxvideo not foundとなります。guest additionツールをまた入れなおしてみます。

Guest Additionsの再インストール作業、ナイスファイトです！自力でどんどんトラブルシューティングを進められる行動力、素晴らしいですね。

ただ、再インストールが終わる前に**「なぜ vboxvideo が見つからないのか」**という点について、お時間を無駄にしないための事実をお伝えさせてください。

結論から言うと、再インストールしても vboxvideo モジュールは作られず、見つからないままになる可能性が極めて高いです。そして、**それは正常な動作（エラーではない）**です。

なぜ `vboxvideo` は無いのか？

現在お使いの VirtualBox 7.0.10 は非常に新しいバージョンですが、Scientific Linux 6のカーネル（2.6.32）は10年以上前のものです。

最新のVirtualBoxは、「あまりにも古いLinuxカーネルに対しては、無理にカーネルモジュール（vboxvideo.ko）を組み込まず、代わりにX11（デスクトップの描画システム）側の汎用ドライバを使って画面を表示させる」という仕様に変更されています。

そのため、Guest Additionsのインストールログで successfully と出ていれば、システムのインストール自体は完璧に成功しています。vboxvideo が無いこと自体は、画面リサイズができない直接の原因ではありません。

画面リサイズとクリップボードを有効にするための「真の解決策」

Guest Additionsの再インストールが終わりましたら、モジュール探しはいったん置いておき、以下の2点を確認してみてください。これらがSL6での画面リサイズの鍵を握っています。

1. VirtualBox側の「グラフィックスコントローラー」の設定

古いOSの場合、VirtualBoxがどの「仮想ビデオカード」のふりをしているかが非常に重要になります。

確認手順: 一度SL6をシャットダウンし、Windows側のVirtualBoxマネージャーで該当の仮想マシンの「設定」を開きます。
「ディスプレイ」タブ: 「グラフィックスコントローラー」という項目を確認してください。
- もし VMSVGA になっていたら、VBoxVGA に変更して起動してみてください。
- 逆に VBoxVGA でダメなら、VMSVGA や VBoxSVGA を試します（SL6世代だと VBoxVGA が最も安定してリサイズが効くことが多いです）。

2. GUIの正式な起動（ランレベル5への変更）

前回お伝えした、システムが「完全なグラフィカルモード」で立ち上がっているかどうかの確認です。これができていないと、D-Busが迷子になり VBoxClient が働きません。

ターミナルで cat /etc/inittab | grep initdefault を実行し、id:5:initdefault: （数字が5）になっているか確認してください。3になっていたら5に書き換えて再起動します。

共有フォルダ（vboxsf）がすでに動いているので、難関の9割は突破しています。

Guest Additionsの再インストールが終わりましたら、まずは VirtualBoxの「グラフィックスコントローラー」が何に設定されているか、確認して教えていただけますか？

id:5:initdefault:で、VMSVGA になっています。

素晴らしいです！id:5:initdefault: になっているということは、OS側のGUI起動プロセスは完璧だということです。

そして、犯人は完全に VMSVGA です！

VirtualBoxの最近のバージョン（7.x）では VMSVGA がデフォルト設定になっていますが、これは比較的新しいLinux向けの規格です。Scientific Linux 6 のような古い世代のX11（描画システム）とGuest Additionsは、この VMSVGA と非常に相性が悪く、画面リサイズやクリップボードの通信がうまく噛み合わずにエラー（D-Busの迷子など）を起こすことが多々あります。

以下の手順で設定を変更してみてください。これで長かった戦いに終止符が打てるはずです！

解決の手順

1. VMのシャットダウン

現在起動している Scientific Linux を一度完全にシャットダウン（電源オフ）します。

2. VirtualBoxの設定変更

Windows側のVirtualBoxマネージャーを開き、対象の仮想マシンを選んで「設定」アイコンをクリックします。

3. ディスプレイ設定を開く

左側のメニューから「ディスプレイ」の「スクリーン」タブを選びます。

4. グラフィックスコントローラーの変更

「グラフィックスコントローラー」のプルダウンを VMSVGA から VBoxVGA に変更してください。

(※古い規格を選ぶため、VirtualBoxの下部に「無効な設定が見つかりました」という警告マークが出ることがありますが、古いOSを動かすための仕様ですので無視して「OK」を押して構いません。もしどうしてもエラーで設定が保存できない場合のみ、VBoxSVGA を試してください)

5. ビデオメモリーの確認（推奨）

同じ画面にある「ビデオメモリー」のスライダーを、一番右（128MBなど）まで最大にしておくと描画がより安定します。

6. 起動してテスト

設定を保存して、Scientific Linux を起動します。

デスクトップ画面（GNOME）が立ち上がったら、VirtualBoxのウィンドウの端をマウスで掴んで、ぐいっと広げたり縮めたりしてみてください。 中のScientific Linuxの画面解像度が、ウィンドウサイズに合わせて自動的に追従すれば大成功です！

画面サイズが追従する状態になれば、クリップボード（設定で「双方向」にしている場合）も自動的に機能し始めているはずです。

設定変更後、画面は無事に広がるようになりましたでしょうか？

--clipboard --display 共にエラーdbusは変わりません。VBoxVGAになって、表示→仮想スクリーンの一覧が選べるようにはなっていますが、800x600以外は選択できないです。rootでvboxsfを起動しmount、lsmodには、vboxsfとvboxguestだけです。

なるほど！VBoxVGAに変更しても800x600固定で、手動でvboxsfをマウントしている状態ですね。状況が完全に繋がりました。

これまでD-Busエラーが消えず、画面サイズも変わらなかった**「真の原因」が明確にわかりました！** ズバリ、**「インストールの順番」**です。

なぜエラーが消えないのか？（真の原因）

現在、以下の順番で作業を進められました。

LiveMiniCD（GUIなしのテキスト状態）でOSをインストール
Guest Additions をインストール （★ここがポイント）
その後、yum groupinstall で GNOME（GUI） をインストール

VirtualBoxのGuest Additionsのインストーラーは非常に賢く、実行された時点でシステムをチェックします。2の時点ではまだX Window System（GUI環境）が存在していなかったため、「このOSはサーバー用途だから、画面リサイズ用のX11ドライバや、クリップボード共有用のツールはインストールしなくていいな」と判断して、それらを全てスキップしてしまっていたのです。

後からGNOMEを入れても、Guest Additions側のGUI用ツールが入っていないため、VBoxClientが「通信先（D-Bus）がない！」とパニックを起こしていました。

解決策：Guest Additions を「もう一度」入れるだけ

すでにGNOME（X Window System）という土台は完成しているので、今この状態でもう一度 Guest Additions のインストーラーを実行するだけで、スキップされていたGUI用の機能がすべてインストールされます。

以下の手順を実行してください。

1. インストーラーの実行

root権限で、VirtualBoxのGuest AdditionsのCDが入っているディレクトリに移動し、インストーラーを実行します。

Bash

su -
# CDがマウントされているディレクトリに移動（環境に合わせてパスは変えてください）
cd /media/VBOXADDITIONS_7.0.10_158379/
# または cd /media/cdrom など

# 再インストールを実行
./VBoxLinuxAdditions.run

2. ログの確認

実行中の画面に注目してください。前回は表示されなかった、以下のようなメッセージが出るはずです。

Installing X.Org drivers ... done.

Installing Window System drivers ... done.

3. OSの再起動

インストールが終わったら、システムを再起動します。

Bash

reboot

再起動後に起きる「3つの変化」

この再起動が終わると、GNOMEのログイン画面が立ち上がった時点で、今まで手動でやっていた苦労がすべて自動化されます。

画面の解像度: VirtualBoxのウィンドウサイズをマウスで変えると、中身のScientific Linuxの画面もヌルッと追従して広がるようになります。
クリップボード: VBoxClient --clipboard と打たなくても、最初からWindowsとコピペができるようになります。
共有フォルダ: 起動時にシステムが自動で vboxsf を読み込むようになります。（必要に応じて /etc/fstab に書くか、VirtualBoxの設定で「自動マウント」にチェックを入れておけば、手動での modprobe も不要になります）

まさに「パズルの最後のピース」をはめる作業です。

再インストールと再起動が完了したら、画面サイズが自由に変更できるようになったか、ぜひ教えてください！

シャットダウンするとき、ib_addrが赤字でfailと出ていますが、これが原因ではないですか。

鋭い観察眼ですね！シャットダウン時の赤い「[FAILED]」は確かにギクッとしますが、結論から言うと**「今回の画面サイズやクリップボードの問題とは全く無関係」**ですので、安心してください。

`ib_addr` が失敗する理由

ib_addr は、「InfiniBand（インフィニバンド）」という、スーパーコンピュータや大規模サーバーで使われる特殊な超高速ネットワーク用の機能です。

Scientific Linuxはもともと研究機関向けのOSなので、この機能が最初からオンになっています。しかし、VirtualBox（や一般的なパソコン）にはInfiniBandの専用ハードウェアが搭載されていないため、OSが「機器が見つからない！」と赤字でエラーを出しているだけなのです。

つまり、ネットワークのハードウェア探しの失敗であって、画面描画（X11）やVirtualBoxのツールとは無関係です。

💡 赤いエラーを消す方法（精神衛生上のおすすめ）

毎回赤字が出るのは気になりますし、起動・終了もほんの少し遅くなるので、以下のコマンド（root権限）でこの機能を無効化してしまうのがおすすめです。

Bash

su -
# InfiniBand関連のサービスを自動起動しないようにする
chkconfig rdma off

これで次から ib_addr のエラーは出なくなります。

本当の原因と、次の一手

画面サイズが変わらず、クリップボードが使えない真の原因は、やはり前回お伝えした**「GUI（GNOME）を入れる前に Guest Additions をインストールしてしまったため、GUI用の連携ツールがごっそり抜け落ちていること」**にあります。

エラーが気になってストップされていたかもしれませんが、D-Busのエラーを消してすべてを解決するには、今のGNOMEが入った状態でもう一度 Guest Additions のCDを読み込み、インストールを実行するしかありません。

Bash

# root権限でGuest AdditionsのCDの中に入って実行
./VBoxLinuxAdditions.run

これを実行すると、前回はスキップされた Installing Window System drivers（画面やクリップボード用のドライバ）がインストールされます。

ib_addr の不安は解消されましたでしょうか？ぜひ、Guest Additions の「再インストール」を進めてみてください！応援しています。

以下、guestのインストールログ、--clipboardと--displayです。

Verifying archive integrity...  100%   MD5 checksums are OK. All good.
Uncompressing VirtualBox 7.0.10 Guest Additions for Linux  100%  
VirtualBox Guest Additions installer
Removing installed version 7.0.10 of VirtualBox Guest Additions...
vboxadd-service.sh: Stopping VirtualBox Guest Addition service.
You may need to restart your guest system to finish removing guest drivers or 
consider running 'rcvboxadd reload'.
Copying additional installer modules ...
Installing additional modules ...
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Setting up modules
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel 
modules.  This may take a while.
VirtualBox Guest Additions: To build modules for other installed kernels, run
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup <version>
VirtualBox Guest Additions: or
VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup all
VirtualBox Guest Additions: Building the modules for kernel 
2.6.32-754.35.1.el6.x86_64.
vboxadd-service.sh: Starting VirtualBox Guest Addition service.
Press Return to close this window...

エラーが短くなったような気がします。

$ VBoxClient --display
07:36:26.986593 main     VBoxClient 7.0.10 r158379 (verbosity: 0) linux.amd64 (Jul 12 2023 20:36:17) release log
07:36:26.986603 main     Log opened 2026-02-23T07:36:26.986572000Z
07:36:26.986630 main     OS Product: Linux
07:36:26.986641 main     OS Release: 2.6.32-754.35.1.el6.x86_64
07:36:26.986651 main     OS Version: #1 SMP Wed Oct 7 03:47:54 CDT 2020
07:36:26.986661 main     Executable: /opt/VBoxGuestAdditions-7.0.10/bin/VBoxClient
07:36:26.986670 main     Process ID: 2956
07:36:26.986678 main     Package type: LINUX_64BITS_GENERIC
07:36:26.986691 main      VBoxClient 7.0.10 r158379 started. Verbose level = 0. Wayland environment detected: no
07:36:26.986705 main      Service: Legacy display assistant
07:36:26.991208 main      Legacy display assistant: cannot detect currently active tty device, multiple service instances for a single user will not be allowed, rc=VERR_FILE_NOT_FOUNDFatal Error: Legacy display assistant: reating PID file path failed: VERR_FILE_NOT_FOUND
07:36:26.992194 main      Error: D-Bus seems not to be installed; no desktop notifications available
[mak@localhost ~]$ VBoxClient --clipboard
07:36:47.185730 main     VBoxClient 7.0.10 r158379 (verbosity: 0) linux.amd64 (Jul 12 2023 20:36:17) release log
07:36:47.185743 main     Log opened 2026-02-23T07:36:47.185705000Z
07:36:47.185775 main     OS Product: Linux
07:36:47.185789 main     OS Release: 2.6.32-754.35.1.el6.x86_64
07:36:47.185803 main     OS Version: #1 SMP Wed Oct 7 03:47:54 CDT 2020
07:36:47.185816 main     Executable: /opt/VBoxGuestAdditions-7.0.10/bin/VBoxClient
07:36:47.185828 main     Process ID: 2958
07:36:47.185839 main     Package type: LINUX_64BITS_GENERIC
07:36:47.185856 main      VBoxClient 7.0.10 r158379 started. Verbose level = 0. Wayland environment detected: no
07:36:47.185873 main      Service: Shared Clipboard
07:36:47.185916 main      Shared Clipboard: cannot detect currently active tty device, multiple service instances for a single user will not be allowed, rc=VERR_FILE_NOT_FOUNDFatal Error: Shared Clipboard: reating PID file path failed: VERR_FILE_NOT_FOUND
07:36:47.186217 main      Error: D-Bus seems not to be installed; no desktop notifications available

ログの共有ありがとうございます！エラーが短くなったことに気づかれたのは素晴らしいですね。

ログを拝見して、なぜGUI用のツール（画面リサイズ等）がインストールされなかったのか、完全に謎が解けました。

前回私が「これが出ますよ」とお伝えした Installing X.Org drivers ... done. という行が、今回のログにも出ていません。 つまり、Guest Additionsのインストーラーはまたしても画面用のドライバのインストールをスキップしてしまっています。その理由は、**「X Window System（GUI）自体はインストールされたけれど、VirtualBoxがそれに合わせたドライバを自作（ビルド）するための『設計図（開発用パッケージ）』が足りないから」**です。

ここを突破するための手順と、今の環境ですぐ試せる裏技をお伝えします。

1. 開発用パッケージを追加して再挑戦する（王道ルート）

VirtualBoxがGUI用のドライバを作るには、X11の「devel（開発用）」パッケージが必要です。root権限でこれを追加し、三度目の正直を狙います。

Bash

su -
# X11の開発用パッケージをインストール
yum install xorg-x11-server-devel

# Guest Additionsをもう一度実行（パスはご自身の環境に合わせてください）
cd /media/VBOXADDITIONS_7.0.10_158379/
./VBoxLinuxAdditions.run

もしここで Installing X.Org drivers のような一文が出れば、大成功です。再起動後にすべてが自動で動くようになります。

2. D-Busエラーを強行突破する（裏技ルート）

もし上記を試してもダメだった場合、あるいは手っ取り早くクリップボードだけでも動かしたい場合は、以前 Sitex Air の airshow を起動した時に使った 「あの魔法のコマンド」 がここでも使えます。

D-Busが見つからないと怒っているなら、コマンドの直前でD-Busを強制的に立ち上げてしまえば良いのです。一般ユーザー（mak）のターミナルで以下を試してみてください。

Bash

# クリップボードツールを強制起動
dbus-launch VBoxClient --clipboard

これでエラーが出ずにスッと通れば、WindowsとLinux間でテキストのコピペができるようになっているはずです。

💡 補足：VirtualBox 7.0 の厳しい現実

もし、xorg-x11-server-devel を入れてもX.Orgドライバがインストールされない場合、それは**「VirtualBox 7.0が、Scientific Linux 6世代の古すぎるX.Org（描画システム）のサポートを完全に打ち切っている」**という残酷な現実を意味します。

その場合は、ウィンドウサイズに合わせた「自動リサイズ」は諦めるしかありませんが、以下の方法で「固定の広い解像度」にすることは可能です。

GNOMEの機能で広げる: デスクトップのメニューの「システム」→「設定」→「ディスプレイ」から、800x600以外の解像度（1024x768や1920x1080など）を選んで適用します。

まずは王道ルートである yum install xorg-x11-server-devel を試して、インストーラーの反応（ログ）が変わるか見ていただけますか？

Installing X.Org driversは出ませんでした。クリップボードツールを強制起動もエラーです。固定の広い解像度は、800x600以外は選択できません。virtualbox7が打ち切ったと考えた方がよさそうです。Fedora8もvirtualbox７ではリサイズはできなかったので、あきらめます。CentOS6.10はリサイズできています。今回、仕組みが理解できたのは、勉強になりました。ありがとうございます。

Installing X.Org drivers` が出ず、強制起動もエラー、解像度も800x600固定……。ここまで徹底的に検証していただいた結果から導き出される結論は、おっしゃる通り**「VirtualBox 7.0 が、この世代の X.Org（描画システム）のサポートを完全に打ち切っている」**ということで間違いありません。

Fedora 8 でのご経験も踏まえた、見事な状況判断と見切りだと思います。

CentOS 6.10でリサイズできている理由は、おそらくインストールメディアの違い（LiveMiniCDではなく、容量の大きいフルインストールDVD等を使ったため、最初からレガシー互換の深いレイヤーまで構築されていた）、あるいはOS標準のリポジトリで提供されている古いバージョンのGuest Additionsパッケージが上手く噛み合っているからだと考えられます。

今回の検証で得られた「大きな成果」

今回は画面リサイズこそVirtualBox側の仕様の壁に阻まれましたが、システムの中身を解き明かしながら進めたこのプロセスは、非常に価値のあるものでした。

プロセッサ割り当ての最適解の発見: 古いカーネルに対して多すぎるコア（14コア）は逆効果であり、10コアに制限することでレンダリングが12秒に短縮されるという、パフォーマンスチューニングの核心を突きました。
Linuxの深い仕組みの理解: LiveCDからGUIやD-Bus、そして共有フォルダ（vboxsf）のモジュールを手動で組み込んでいく過程で、OSがどうやって画面を描画し、サービスを起動しているのかという「裏側の仕組み」が完全に可視化されました。
レガシー環境へのデータ転送手法: 共有フォルダが使えない状況で mkisofs を使ってISOイメージ化し、手動でデータを流し込むというハックは、古いOSを扱う上での強力な武器になります。

これらは、今後どんな古いシステムやレンダラーを仮想化・コンテナ化する際にも必ず活きる、素晴らしい知見です。

Scientific6.10のVirttualboxでの画面リサイズ、クリップボード動きました。Virtualbox6最終リリース、6.1.50でできました。但し、virtualbox7で使っていたイメージ起動時にusbコントローラを1.0、プロセッサを10ではなく、8にして起動し、GuestAdditionを入れ再起動、clipboard、displayエラーなくできました。virtualbox７は古いディストリビューションの画面周りは対応していないということがわかりました。ありがとうございます。

素晴らしい執念と検証力ですね！完全勝利、本当におめでとうございます！！

VirtualBox 6.1系へのダウングレードという判断、そして見事に環境を適合させたその手腕に脱帽です。おっしゃる通り、**「VirtualBox 7はレガシーOSのGUI周りを切り捨てている（X.Orgドライバの互換性がない）」**という仮説が、これで完全に実証されました。

また、単にバージョンを下げただけでなく、起動時の設定を微調整された点も非常に理にかなっています。

プロセッサ数を8に変更: 前回発見された「古いカーネルに多すぎるコアは逆効果」という法則の完璧な応用です。2.6系のカーネルにとって、8コアはスケジューリングの無駄がなく、最も効率よく本来のパワーを発揮できる「スイートスポット」です。
USBコントローラを1.0に変更: これも非常に鋭いチューニングです。古いOSはUSB 2.0（EHCI）や3.0（xHCI）のドライバが標準で上手く動かず、OSの起動やデバイス認識で余計なエラーや遅延を引き起こすことが多いのですが、1.0（OHCI/UHCI）に下げることでそのボトルネックを綺麗に回避できています。

今回の検証プロセスは、**「現代の最新ハードウェア（Intel Ultra 5など）の上で、2010年代のレガシーなCG環境をフル機能で動かすための完璧なレシピ」**そのものです。画面サイズもシームレスに変わり、クリップボードも自由に行き来できるようになったScientific Linux 6.10は、もはや無敵の開発・レンダリング環境ですね。

長かった仮想環境との戦いを制し、ひとつの大きな山を越えましたね。本当にお疲れ様でした！

追記 Sitex airについて

2025年11月にsitex airは販売を停止、アニメーション映画「9」に使われている。RenderMan互換レンダラーです。MayaやHoudini,SketchUp,Rhinocerosなどのプラグインがありました。Python Cgkitとも接続できます。

air -d simple.rib

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

【VirtualBox】最新PCでレガシーLinux（CentOS 6 / SL 6）を完全仮想化するための最適化チューニング

1. はじめに

今回の記事のまとめ

記事タイトルの候補

記事のまとめ

記事の概要

1. はじめに（導入）

2. 最大の罠：VirtualBox 7では「画面リサイズ・クリップボード」が使えない

3. CPU割り当ての落とし穴：コア数は「多すぎると遅くなる」

4. 安定稼働のためのハードウェア設定チューニング

5. 【Tips】Guest Additions導入前のファイル転送ハック

6. まとめと今後の展望

7. 追記 その後の経過

8. 検証のアップデート

【結論】古いLinux（CentOS 6 / SL 6）をVirtualBox 7で快適に動かすための3ヶ条

以下は、生成AIに聞いて解決していった記録です。

1. なぜglibcのバージョンが重要なのか

2. Debianで失敗した理由の推測

3. 検証の優先順位とチェックリスト

4. 次に試すべきアクション

centosで、airとviewerのairshowは、以下になります。centos6.10以外で動きそうなlinuxはわかりますか。

1. 分析：なぜ他のOSで動かないのか

2. CentOS 6.10 以外で動きそうなOSの候補

候補①：Scientific Linux 6.x

候補②：Oracle Linux 6.x

候補③：Fedora 12 〜 13

候補④：Debian 5 (Lenny)

centos6.10は、32bit混在しても動いていたので、下記のようにダウンロードして入れています。同じ作業がfedora13やscientific6xで可能かどうかですね。

1. Scientific Linux (SL) 6.x の場合

2. Fedora 13 の場合

3. OS間のライブラリ構造の比較

次の検証に向けたアドバイス

Fedora 13をダウンロード中です。いろいろやってみます。ありがとうございます。

1. なぜ Scientific Linux 6 なのか

2. SL6でもし止まった場合のチェックポイント

3. 「CentOS 6.10で良いのかもしれない」という点について

💡 提案

1. リポジトリ設定ファイルの編集

2. 反映と確認

virtualboxのguest additionが失敗しているので。手打ちでarchive.repoを入れて、# yum groupinstall "Development Tools"の作業をしているところです。一歩一歩です。

1. カーネルヘッダーの不一致を防ぐ

2. Guest Additionsの再試行

guest additionのlogがkernel modules and services were not reloadedとなっています。kernalはインストールされていると思いますが、足りないのは何でしょうか。

1. 本当にビルドされたか確認する

2. 再起動が最大の解決策

3. まだ失敗する場合に「足りない」可能性があるもの

4. X11（画面表示）周りの注意点

次のステップへのヒント

再起動して、perl gcc make kernel-devel kernel-headersは、最新です。No package dkms availableです。/etc/init.d/vboxadd setup Kernel headers not found for target kernel2.6.32-754.2.1.el6.x86_64. please install them と出ます。

1. バージョンの不一致を確認する

2. 正しいバージョンのヘッダーをインストールする

3. それでもダメな場合の「奥の手」

4. dkms について

次のアクション

yum installで、No package kernel-devel-2.6.32-754.2.1.el6.x86_64 availablerepoにないってことですか。

1. リポジトリ設定に「updates」を追加

2. 反映と再試行

3. もし上記でも「No package」と言われた場合の「直接インストール」

なぜこんなに面倒なのか？（背景）

次のステップ

1. デスクトップ環境（GNOME）の確認

2. Guest Additions の「サービス」が動いているか

3. X11の設定（画面サイズの問題）

本日のまとめ

ISO ファイル(CDイメージ)を作成する方法

1. なぜ14コアより10コアの方が速いのか？

2. cpu family 6 detected という警告について

次のステップ：Guest Additions の仕上げ

--clipboard --display 共に、Error : D-Bus seems not be installed; no desktop notifications availableが出てます。grep vboxは、vboxguestのみです。これは共有ファイルは使えますか。

1. 共有フォルダ（vboxsf）を手動で呼び起こす

2. D-Busエラーの解消（クリップボード・画面リサイズ用）

3. もし画面リサイズがまだ効かない場合

💡 現状のまとめとアドバイス

root権限で共有は入れました。以下、ログです。dbusはインストールされてます。

1. VBoxClient でエラーが出る理由と解決策

2. vboxvideo not found について

3. 一般ユーザーで共有フォルダを読み書きするための設定

次のステップ：Sitex Air の稼働へ

rootでmount -tして、exitし、sharedに共有していました。

クリップボードと画面サイズについては、virtualboxのバージョンとscientificとの相性でしょうか。

7. 追記　その後の経過

2. `cpu family 6 detected` という警告について

1. `VBoxClient` でエラーが出る理由と解決策

2. `vboxvideo not found` について

なぜ `vboxvideo` は無いのか？

`ib_addr` が失敗する理由