DellのジャンクノートにMageia Linuxを入れる実機作業ログ
目次
ジャンクで転がっていたDellのノートPCに Mageia Linux を入れることにした。
コミュニティ運営の老舗Mandriva系ディストリで、UbuntuでもFedoraでもない選択肢としてどう動くのか、実機で触りながら記録していく。
機材紹介から、USB書き込み、Live起動、AHCI切替、インストール本体、初回起動、Wi-Fiの自動接続トラブルまで、作業全部を順番に記録した。
今回の機材
Dell Latitude 5310 (本体)
アキバのジャンク屋の端っこの箱に転がっていた個体。
めっちゃぼろぼろだったからか、貼ってある値札の金額よりさらに下に値切れて、1万円台で持ち帰った。
天板はDELLロゴのまわりが手アカと擦れでくすんでる。拭いても汚れは落ちない。
角にも軽いへこみ。とはいえ歪みはなく、ヒンジもガタつきなしで開閉できる。
開けると JIS配列のキーボード。キートップのプリントは生きてる。
トラックパッドは独立クリックボタン付きの旧来型。Latitudeらしい質実剛健な見た目。
底面にはっきり「Latitude 5310」と刻印あり。サービスタグもまだ読める。
通気スリットが大きく取られてる典型的な13インチビジネスノート。
店頭で確認した範囲では:
- 起動して BIOS まで到達、メモリと SSD が認識されている
- 画面割れなし（汚れは染みついて落ちない）
- へこみあるが使用には耐える
この状態で動作品扱いなら御の字、ということで持ち帰り決定。
電源アダプタ
ジャンクのおまけで純正 Dell 65W のアダプタが付いてきた。これがあるかないかで運命が変わるので大きい。
出力側はUSB-C（PD給電）。本体のType-Cポートを電源で塞ぐ仕様なので、データ用USBはType-Aを別に用意する必要がある（後述）。
Dell Wired Mouse MS116 (新調)
トラックパッドだけでは作業がしんどい想定で、有線マウスを別途用意。
Bluetoothマウスはペアリングが切れたり認識が遅れたりして信じきれないので、最初から有線で。
別件でも有線マウス＋キーボードが必要だったので、ついでに買いに出た流れ。
純正にこだわりはなかったが、たまたま安くて選んだのがDell純正MS116。
USB-Aの3ボタン+ホイールマウス。
ラベルを見ると Mfg Date Oct.2025 で割と新しめのロット。
中身はマウス本体と、下に保証書が一枚入っているだけのシンプル構成。挿せば動く。
SanDisk Ultra Dual Drive m3.0 32GB (USB書き込み用)
USBの口を確認したら、Latitude 5310はType-CでPD給電しているとCポートが塞がる構造で、USB-Cメモリだと差すところがない。
ということで普通にUSB-Aタイプを店で物色して、安かったのがこれ。買ってから気づいたが、片側がmicroBの「Dual Drive」モデルだった。Androidスマホとの受け渡し用らしい。
書き込み用のUSBメモリはSanDiskのDual Drive 32GB。USB-AとmicroUSBの両ヘッド付き。
スライド式のキャップでUSB-AとmicroUSB-OTGを切り替える構造。
今回はmicroUSB側は使わず、PCのUSB-Aに挿してMageia ISOを書き込むのに使う。
スペック表
| 項目 | 内容 |
|---|---|
| モデル | Dell Latitude 5310 |
| CPU | Intel Core i5-10310U (Comet Lake, 4C/8T, 1.7-4.4GHz) |
| メモリ | 約16GB |
| ストレージ | 内蔵SSDあり(型番はインストール時に確認) |
| 画面 | 13.3インチ |
| Wi-Fi | Qualcomm Atheros QCA6174 802.11ac (Wi-Fi 5, WPA2まで) |
| Ethernet | Intel I219-LM |
| Bluetooth | Qualcomm Atheros |
| 入手経緯 | アキバのジャンク屋、1万円台 |
| 付属 | 純正Dell 65W ACアダプタ |
| 別途用意 | Dell MS116マウス、SanDisk Ultra Dual Drive 32GB |
Mageia Linuxとは
Mageiaは、フランス発のMandriva Linuxからフォークしたコミュニティ運営のディストリビューション。2010年に商用Mandrivaの将来が不透明になったタイミングで、元開発者と有志が「Mageia.Org」という非営利団体を立ち上げて引き継いだ。
主な特徴。
| 項目 | 内容 |
|---|---|
| Mandriva系の系譜 | RPMベース、独自パッケージマネージャ urpmi、Mageia Control Center (旧drakconf) という統合管理GUIが残っている |
| コミュニティ運営 | 商用スポンサーに依存しない。リリースサイクルはゆるめ |
| デスクトップは選べる | Plasma、GNOME、Xfceなど、Live ISOでデスクトップ別に配布 |
| 現行は Mageia 9 | 2023年8月リリース。長期サポートは公式に明示されていないが、9系のメンテナンス更新が続いている |
UbuntuでもFedoraでもないRPM系を触りたいときの選択肢として残っている、という立ち位置。
なぜLinux機を増やすことにしたか
理由は複数ある。
ひとつめは手元の開発環境を整理したいこと。開発でコンテナに切り出している部分を、Mac/Windows上のDocker Desktopではなく純粋なLinuxホストで動かしたい。挙動・パフォーマンスのズレを潰すには、ホストがLinuxである方が都合がいい。
ふたつめはVPSで運用しているテスト環境を手元に引き上げたいこと。検証用途にVPSを借りっぱなしにしているものを、ローカル機に寄せて月次費用を整理する。常時起動でなくていい用途は手元の中古ノートで十分。
みっつめはLinux系セキュリティインシデントを手元で再現したいこと。2026年に入ってからLinuxカーネルのページキャッシュを書き換えて root を取る系のバグが連鎖的に出ている。
Copy Fail (CVE-2026-31431) → Dirty Frag → Fragnesia (CVE-2026-46300) と、暫定緩和を回避する亜種が立て続けに出てくる流れで、コンテナ・CIランナー側への影響も大きい。
さらに Claude Codeで23年もののNFSヒープオーバーフロー のように、AIによる古いカーネルコードの掘り出しも続いている。Mac/WSLでは追いきれない検証を、専用のLinux実機で気兼ねなく試せるようにしたい。
最後はLinuxでWindowsゲームが本当に動くのか試したいこと。以前 NTSYNCがWindowsの待ち合わせをカーネルで処理してLinuxゲームを速くする話 を書いたが、実機で触って確かめたわけではない。Linux 6.14 + Wine 11.0 + Proton 11 beta の組み合わせで、手元のWindowsゲームがどこまで普通に動くか軽く試したい。
つまり「常用機」ではなく「壊してもいい検証ホスト」が欲しい、というのが主目的。
それなら多少ジャンクでも、ちゃんと動いて電源が確保できれば十分という判断になった。
なぜMageiaにしたか
久々にローカル機へ直接Linuxを入れる（Dockerコンテナじゃなくクリーンインストールするやつ）ので、何を入れるかを考え直すところから始まった。
CentOSは事実上死んでから何年も経つし、検証用にわざわざRHELを入れるような話でもない。
Ubuntuが無難なのは分かっていて、それかDebianでまっさらに組むか、というあたりまでは順当に出てくる。ここまでで決め切れず、せっかくなので現状のディストリ事情を眺めてみたら目についたのがMageiaだった。
候補としてZorinOSも見てはいた。こちらはデスクトップ向けに振った印象だが、今回の用途的にはどっちでも良さそうな雰囲気だけ感じた。
最後に背中を押したのは「マギアか、まどマギみたいなもんか」という軽いノリで、特段の根拠はない。
ダメそうだったら普通にUbuntuに切り替える。
ISOを落としてUSBに焼く
ISOの入手
Mageia公式の配布ページ から ISO をダウンロードする。
選択肢は3系統:
- クラシック インストール (DVD): フル機能のテキスト/グラフィカルインストーラー。Mageiaの伝統的なやり方。先にパーティションを切ってからインストールする
- ライブ メディア: ブートして実機の挙動を確認してから、その場でインストーラーを起動できる。デスクトップ環境別(GNOME / Plasma / Xfce)に分かれている
- ネットワーク インストール: 最小ISOで起動してネット越しに本体を取りに行く。Wi-Fiドライバが標準で入ってないと詰むのでジャンクノートには不向き
今回は ライブメディア を選ぶ。動かないハード(Wi-Fi、トラックパッド、画面)が出たら、パーティションを切る前にその場で撤退できるのが大きい。
デスクトップ環境はXfce
ライブメディアを選ぶと、同じページに デスクトップ / アーキテクチャ / ダウンロード方法 の選択肢が縦に展開される。
GNOMEは拡張前提のカスタムもリソースも重いので最初から除外。残るはPlasmaとXfceの2択。
Xfceにした理由は、用途が「検証ホスト＋VPSテスト引き上げ＋コンテナ実行」なので、基本コンソール作業。デスクトップは確認用にあれば十分。
Plasmaは華やかでMandriva系の本命だが、その分リソースとプロセスが乗ってくる。検証中に裏で動いてるものが分かりにくくなる。
ジャンクノートで状態未知なので、軽い方を選んでおけば動かないリスクも下がる。
Mageiaらしさを堪能するならPlasmaが本筋ではあるが、今回は実用優先で見送る。
アーキテクチャは64ビット、ダウンロード方法はBitTorrentが空いてれば速いが、無難にダイレクトリンクでも問題ない。
ISOダウンロード
「ダイレクトリンク」を押すと、ミラーサイトの直リンクとSHA512チェックサムの確認手順が出る。
ハッシュ検証はやっておく。Linux/macOSなら sha512sum -c Mageia-9-LiveDVD-Xfce-x86_64.iso.sha512、Windowsなら PowerShell の Get-FileHash -Algorithm SHA512 で出した値を .sha512 の中身と突き合わせる。
ミラー経由でファイル破損や差し替えがあったときに気づけるので、面倒でも踏んでおく。
USBメモリへの書き込み
書き込みは Windows から Rufus で。balenaEtcher でも dd でも書ける。
ISOを Rufus で開くと、こうなる。
パーティション構成・ターゲットシステム・ファイルシステム・クラスタサイズが全部グレーで触れない。これは Rufus が「このISOは ISOHybrid ではなく純粋なDDイメージ」と判定したため。Mageia の Live ISO は中身を生で書き込むタイプなので、Rufus 側の細かい設定は無視されて DDモード固定になる。
事実上 デバイス選択 → ISO選択 → スタート の3手しかない。
スタートを押すと、USB上の既存データは全部消えるという警告が出るので同意して進める。
そのまま放っておけば書き込みが進む。今回はLive Xfce ISO で経過時間2分台で90%超えてた。Mageia の Live ISO はこのサイズなら 10分かからず終わる。
完了すると状態バーが「準備完了」に戻り、デバイス名が NO_LABEL (D:) から MGAISO-ESP (ディスク1) に、ボリュームラベルも Mageia-9-Live-Xfce-x86_64 に変わる。これで Mageia の起動メディアとして仕上がっている。
書き終わったとき Windows 側で「USBがフォーマットされていません」のダイアログが出るケースがあるが、今回は出なかった。出てきても Linux パーティションを Windows が読めないだけで壊れていないので、絶対に キャンセル を押す。フォーマットしてしまうと書いたばっかりのISOが消える。
ジャンクノート側の準備
書き終わったUSBを Latitude 5310 に挿し、電源アダプタとマウスもつないでから電源ON。Dellロゴが出ているうちに F2 連打で BIOS、F12 連打でワンタイム起動メニューに入れる。
BIOSの構成
Dell の Latitude 系で見慣れたツリー構造の BIOS。General 配下に Boot Sequence があり、Secure Boot は独立した項目として上の方に出てくる。
Boot Sequence
最初に見たとき USBが入っていない ことに気づかず、F12を連打しても出てこなくて焦った。
原因は単純で、書き込んだUSBをまだ挿していなかった。
挿し直して BIOS に入り直すと、Boot Sequence に2エントリ増えていた。
UEFI: SanDisk— USBディスク全体を見に行くエントリUEFI: SanDisk, Partition 2— Mageia が ISO内に持っている EFI システムパーティションを直接指すエントリ
UEFIファームの作法的には Partition 2 (EFIシステムパーティション) を先頭にする方が普通。ただ多くのファームはどちらを選んでも裏で EFI 領域をスキャンするので、まずは動く方優先で問題ない。
右側のリストで USB を先頭に移動して Apply。
これで Exit すれば、再起動時に USB から自動的に起動する。
毎回 USB から起動したくない場合は順位はいじらず、F12 のワンタイム起動メニューから USB を選ぶやり方でもOK。
Secure Boot
Mageia は shim ベースで Microsoft の UEFI 署名を引き受けているため、Secure Boot は ONのまま で起動できる。今回はそのまま触らずに進める。
万一 USB から起動できなかったり、ブート途中で署名エラーが出たら、ここで Secure Boot Enable のチェックを外して再挑戦すればいい。
Expert Key Management は PK/KEK/db/dbx を自分で差し替えたいときに使う領域。今回は触る必要なし。
ブートとインストール
1回目はUSB起動に失敗してDellのリカバリーフローに勝手に飛んだ
F12 のBoot Devicesから UEFI: SanDisk, Partition 2 を選んで Enter。
直後にエラーも何も出ず、画面に Dell SupportAssist のロゴが出てきた。
スキャン結果は Success だが、続いて「machine will restart and download cSOS for recovery」と表示され、自動でリカバリーフローに移行。
Wi-Fi に繋がせて、Dell のサーバから「SupportAssist OS Recovery Image」をダウンロードする気満々で待っている。
これは Dell BIOS の BIOSConnect / SupportAssist OS Recovery 機能で、選択したブートデバイスからOSが起動できないと判定したときに自動で「OS壊れてますね、ネット越しにリカバリしましょうね」フローに入る挙動。
ぱっと見「USB起動成功してそこから何か診断が走った」ように見えるが、実態は USB起動に失敗して別のリカバリ機能に流された だけ。なまじ自動進行するので、選択ミスと勘違いしやすい。
同型機を触る他の人もハマる可能性が高いので失敗側として残しておく。
脱出は Ctrl+Alt+Del で再起動するのが楽。Cancelボタンや電源長押しでも抜けられるが、わざわざ電源切らなくていい。
Secure Boot を切って再挑戦 → そのまま起動
USB起動が静かに失敗する原因の本命は Secure Boot が Mageia の shim を弾いた こと。Mageia 9 はSecure Boot対応のはずだが、Dell側のキーDBやshim署名の検証パスによっては弾かれる。
対処:
- F2 → Secure Boot → Secure Boot Enable のチェックを外す
- Apply → Exit
これだけ。F12でわざわざ選び直す必要もなく、Boot Sequence先頭に置いた UEFI: SanDisk, Partition 2 が普通に効いて、再起動直後にそのままMageiaのブートが走った。
Mageiaの初期セットアップを通過
ブートに成功するとLive環境のセットアップウィザードが順に出てくる。
使用許諾の同意。日本語訳が出るがあくまで参考、法的には英語原文。承諾してOK。
タイムゾーンは Tokyo。
ハードウェアクロックの扱いを選ぶ。Linux単独運用なら本来 UTC が正解(Linuxカーネルのデフォルト挙動と整合)。Windowsとデュアルブートにする予定なら ローカルタイム にしておくとWindows側が時刻ズレで詰まらない。
今回は迷ったらWindows側との時計事故を避ける方向でローカルタイムにしておいた。Mageia単独運用に倒すなら後でUTCに直す。
キーボードは日本語 106。本体に対応した配列なのでそのまま選ぶ。
Xfceデスクトップに到達。「Mageiaへようこそ」ダイアログがタブ構成 (ようこそ / ライブモード / MCC / ソフトウェアのインストール / インストール / 詳細情報) で出る。
右下に「Wi-Fiネットワークは利用可能です」の通知 → Wi-Fiも生きている。
ここまでで:
- 画面表示OK
- Wi-Fi認識OK (ただしWPA3 SSIDに接続するとエラー、WPA2なら接続できる)
- トラックパッド/マウスとも反応OK
- キーボードレイアウト正常
ジャンクノートに必要な最低限のハードは動いた。
Wi-FiのWPA3エラーは最初Live ISOの wpa_supplicant が古いせいかと疑ったが、先ほどのDell BIOSConnect (プリブート環境)からもWPA3 SSIDには繋がらなかった という事実から、Linux側ではなく Wi-Fiカード/ファームウェア側がWPA3 SAE非対応と判断した方が筋がいい。
Latitude 5310 は構成によって Wi-Fi 6 AX201 (WPA3対応) または旧世代のWi-Fi 5カード (WPA2まで) のどちらかが載る。今回の個体は Qualcomm Atheros QCA6174 (802.11ac, WPA2世代) で、Live環境の inxi -F で確認できた(後述)。
対処: 家のルーターをWPA2/WPA3混在モードにするか、別SSIDをWPA2運用にしてそちらに繋ぐ。
内蔵Wi-Fiの換装はLatitude 5310のM.2スロット周りで一筋縄ではいかないので、どうしてもWPA3が必要ならUSB Wi-Fiドングルを足すのが現実的。
Liveモードでハード詳細を取る
Welcomeダイアログを閉じて Xfceのターミナルを開き、inxi -F と lscpu で実装情報を確認した。
inxi -F でわかったこと:
- Audio: PipeWire 0.3.71、PulseAudio 16.1 active
- Ethernet: Intel Ethernet I219-LM (Gigabit)
- Wi-Fi: Qualcomm Atheros QCA6174 802.11ac (driver: ath10k_pci) — WPA3非対応世代
- Bluetooth: Qualcomm Atheros (USB接続、driver: btusb)
- CPU温度: 54.0°C / PCH 51.0°C (Live起動直後、軽負荷)
- Memory: 15.32 GiB (実装16GB)
lscpu でわかったこと:
- CPU: Intel Core i5-10310U (Comet Lake)
- 4コア / 8スレッド
- 1.7GHz ベース / 4.4GHz ターボ
- L1d 128KiB / L1i 128KiB / L2 4MiB / L3 6MiB
- 仮想化: VT-x 有効
- 各種CPU脆弱性緩和も適用済み (Mitigation 表示)
10世代vProモデルのi5、4C8T、16GBメモリ。ジャンク扱いでも検証ホストとしては十分な実力。
IMEは後回し
ターミナルで日本語打とうとして気づいたが、Live環境には日本語IMEが入っていない。
さっき設定したのはあくまでキーボード レイアウト (物理キーマッピング)で、IME (ibus-mozc / fcitx5-mozc 等の日本語入力エンジン)は別物。
半角/全角キーを押しても何も起きないのはそのため。Live中は英語入力で割り切り、インストール後に urpmi ibus-mozc or urpmi fcitx5-mozc で導入する。
Windowsは消して全部Mageia方針
今回のジャンク機は検証ホスト用途で、既存のWindowsを残す必要はないので 全領域Mageia の方針で進める。デュアルブートは事故も増えるし、Windowsで使う場面が出てきたら別途仮想化で動かせばいい。
インストーラの呼び出し方
Welcomeダイアログの「インストール」タブが分かりにくかったので、Whisker Menu の検索ボックスに install と打って探した。
「ハードディスクへインストール」をクリックするとインストーラが立ち上がる。
1回目のインストーラはエラーで止まる
「次へ」を押した直後、Perl由来のエラーで止まる。
Can't call method "first_usable_sector" on unblessed reference.
これはMageiaインストーラ(Perl製)がディスクのパーティション情報を取ろうとして失敗した時に出るエラー。「unblessed reference」 はPerl特有のメッセージで、「期待していたオブジェクトが存在しなかった」という意味になる。
つまり インストール先候補のディスクが見つからない。
原因調査で内蔵SSDが見えていないと判明
ターミナルを開いて lsblk で実装状態を見ると、内蔵SSDがそもそも認識されていないことが判明。
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 3.3G 1 loop /run/mgalive/ovlsize
sda 8:0 1 28.7G 0 disk
├─sda1 8:1 1 3.4G 0 part
└─sda2 8:2 1 4M 0 partUSB(sda)しか出てこない。内蔵SSDは nvme0n1 か sdb で出るはずなのに無い。BIOSではちゃんと認識されていたので、ハード故障ではなく Linux側からアクセスできていない だけ。
ついでに sudo fdisk -l を試したら「sudo: コマンドが見つかりません」と出た。Mageia Live ISOには sudo が標準で入っていないので、root操作は su - で実rootになってから打つ。Live環境のrootパスワードは空(Enterのみ)。
原因はSATAがRAIDモードだったこと
ジャンクのDell機ではよくある罠で、BIOSの SATA Operation が Intel RST(RAID)モード になっていると、Linuxからは内蔵SSDが見えない。Windowsは Intel RST ドライバ経由で読めるが、Linuxは AHCI モードでないと普通に扱えない。
実は最初にBIOSの inxi -F 出力にも Intel Comet Lake RAID Controller と書いてあって、これが伏線だった。
BIOS: SATA Operation を AHCI に切替
F2でBIOS → System Configuration → SATA Operation を AHCI に変更。
警告が出るがYesで確定 → Exit。
Windowsを残す場合はこの変更でブート不能になるが、今回はWin消す前提なので無視。
2回目: ディスク選択
Live再起動 → 「ハードディスクへインストール」再走行。今度は first_usable_sector エラーは出ず、ウィザードが進む。
238GBの内蔵NVMeがやっと見えた。
「ディスク全体を消去して使用」を選んで進む。
Win消す覚悟の確認。次へ。
この時点で1回目のフォーマットが走り、Windowsパーティションは消えて、Linuxの自動分割 (nvme0n1p2 50GB / + nvme0n1p4 183GB /home) がディスクに書き込まれる。
不要パッケージの削除
使われていないハードウェアサポートと言語サポートを削除するか聞かれる。検証用途では入れっぱなしのドライバや言語パックは邪魔なので両方チェックで削除。次へ。
インストール本体
ファイルコピーが走る。mageia.org/contribute の案内が表示される。
ブートローダー設定
GRUB2 (グラフィカル表示) を EFI システムパーティションに書き込む既定構成。タイムアウト10秒、ブートローダーパスワード無し。検証機なのでこのまま。
詳細側。カーネル起動オプションに splash quiet noiswmd resume=UUID=... が入る。audit=0 でauditdログ抑制。他のOSがないか調べるはON(Win消えてるので結果ヒットしない見込み)。/EFI/BOOT にインストール は標準パス強制で、移行系のBIOS問題回避用なのでOFFのまま。
オンライン更新メディアは「はい」で有効化。
GRUB2書き込み中。
ネットワーク設定 — ここでウィザードを閉じてしまう
ここから日本語ローカライズが効かなくなって突然英語UIになる場面が多い(Mageiaあるある)。
接続種別は無線を選んで次へ。
Wi-Fiインタフェース選択。wlp1s0 の Qualcomm Atheros QCA6174 を選ぶ(ndiswrapper側は使わない)。
自宅のWPA2 SSIDを選択。
接続プロトコルは Automatic IP (DHCP)。
IP設定。デフォルトのまま、DNSはDHCPに任せる初期状態。
ここでDNSをCloudflare固定にしておきたかったので、DHCP取得のチェックを外して手動入力に切り替える。
最初は両方Cloudflare (1.1.1.1 + 1.0.0.1)で入れた。
が、CloudflareのDNSは速い反面、2025年末から2026年序盤にかけて短時間の名前解決断が複数回発生していて、一系統に寄せると落ちたとき即詰みになる。別運営の系統を入れておきたいので差し替え。
セカンダリを 8.8.8.8 (Google) に変更。これでCF落ちても名前解決自体は維持できる。
ここでウィザードが閉じる事故が発生: 「上級」を押して上級パネルを開いた後、「閉じる」を押したらウィザード全体が閉じた。
押した「閉じる」は位置と文言から 上級パネルだけを畳むボタン に見えたのだが、実体は ウィザード全体を終了するボタン だった。Mageiaウィザードの「閉じる」「終了」「キャンセル」「完了」あたりのラベルは、押したときのスコープ(上級セクションだけ畳むのか、現在ステップを抜けるのか、ウィザード全体が落ちるのか)が文言と位置から判別しづらい。
ここでウィザード全体が落ちる→やり直しが発生する。
そもそもDNS設定で上級パネルを開く必要は無かった(プライマリ/セカンダリDNSを直接入力すれば十分)ので、普通やらないミスではある。ただ上級パネル自体が画面下部に常設で見えてるとつい押したくなる位置にあって、押した後の「閉じる」の挙動を勘違いしやすいトラップではある、という話。
ウィザード再起動 → 2回目フォーマット確認
再起動したウィザードは、最初の「ディスク全体を消去して使用」(78番) はスキップして、既にディスク上にできていたLinuxパーティション(p2/p4)に対して再度フォーマット指示 を出してきた。
1回目のフォーマット(78-79)でWinはすでに消えていて、ここは Linuxパーティションに対する2回目のフォーマット。
両方チェックのまま次へ。
マウントポイント割り当ても提案通り / と /home。
Wireless接続制御と接続テスト
接続制御。Start the connection at boot だけONで他はデフォルト。「Allow interface to be controlled by Network Manager: いいえ」になっているのは要注目で、これが後でユーザセッションからWi-Fi 設定変更ができなくなる(接続自体は自動で繋がる)遠因になる。
今すぐ接続するか? はい。
ネットワーク完了。
オンライン更新の取り込み
更新メディアのミラー設定。自動 + 既定ダウンローダで進む。
synthesis.hdlist.cz というurpmiのパッケージインデックスを取りに行く。Mandriva系のurpmiが使う形式。
更新を当てるか聞かれる。「はい」。
glibc lib64rpm9 perl-5.36 python3-rpm rpm-4.18.2 系を含む11個・23MBの更新。glibcとrpm一式が入れ替わるサイズ感。OKで進める。
再起動要求が2段階で出る
glibcが入れ替わったので再起動してね、と1回目のダイアログ。OK → 完了 と押すが、実際には自動再起動はかからず、追加の更新ジョブが続いた。
更新が進んだ結果、kernel-desktop と systemd まで入れ替わって、対象パッケージが増えた状態で同じダイアログが再び出てくる。
今度は自分で再起動を実行する。
ここで重要なポイント: 再起動するときに USBメモリを抜く。
さっきBoot Sequenceで UEFI: SanDisk, Partition 2 を先頭にしてあるので、USBを挿したまま再起動するとまたLive ISOから起動してしまう。USBを物理的に抜けばBoot Sequenceは自然に内蔵SSDに落ちるので、起動順をいじり直さなくていい。
再起動後: drakfirst が同じことを聞いてくる
内蔵SSDから初回ブート → Mageiaのスプラッシュが出て、続いて drakfirst という初期セットアップウィザードが立ち上がる。
ここで困惑するのが、Live ISO のインストーラで聞かれたのとほぼ同じ質問が再度出てくる こと。Mageia 9 の設計上、draklive-install と drakfirst が独立して走るのでこうなる。冗長だが仕様。
ネットワークを無線で再設定。
ユーザ作成。root のパスワードとユーザ hide3tu のパスワードを設定。
一般ユーザからはWi-Fiを管理できない、しかも再起動で切れる
再起動するとログイン画面。
普通にユーザ hide3tu でログインしてみたら、デスクトップ右上のネットワーク表示には 「管理されていません」 と出て、一般ユーザからは接続切替や設定変更ができない。最初は「接続は自動で繋がってるが管理ができないだけ」と思ったが、再起動すると接続そのものが切れて自動再接続もしない ことが続けて発覚した。
毎回rootで drakconnect 開いて手で繋ぎ直す運用は流石にきついので、根本から直しにいくことにした。
切り分け: wlp1s0 が NetworkManager から unmanaged 扱い
ターミナルで状態を見ると分かりやすい。
$ nmcli device
DEVICE TYPE STATE CONNECTION
eno1 ethernet 利用不可 --
lo loopback 管理無し --
wlp1s0 wifi 管理無し --wlp1s0 が 「管理無し」(unmanaged) になっていて、nmcliからscanも接続もできない状態。
ip link 側では state UP mode DORMANT で、インタフェース自体は生きてるがAPに association していない。
nmcli device set wlp1s0 managed yes を打っても auditログ上は result="success" なのに状態は変わらない。grep -rn unmanaged /etc/NetworkManager/ /usr/lib/NetworkManager/ を叩いても明示的なunmanaged指定はどこにも無い。
ifcfg-wlp1s0 側を見ると NM_CONTROLLED=yes がちゃんと書いてある。
つまり「設定上はNM管理OKなのに、内部状態は頑なにunmanaged」という詰まり方。
根本原因: ifcfg-rh プラグインが Mageia 固有の ifcfg をパースできない
切り分けた結果、原因は NetworkManager のプラグイン構成だった。
Mageia 9 デフォルトの NetworkManager は plugins=ifcfg-rh,keyfile で動いている。
ifcfg-rh は RHEL系の sysconfig/network-scripts/ifcfg-* を読み書きするプラグインだが、Mageiaの ifcfg には RHEL系には無い独自項目 (WIRELESS_ENC_KEY、WIRELESS_WPA_DRIVER=wext、KEY_MGMT=WPA-PSK、WPA_PSK=...、RESOLV_MODS、PEERYP 等) が並んでいる。ifcfg-rh プラグインはこれを正しくパースできず、結果として NM_CONTROLLED=yes を読み取れずに wlp1s0 を黙って unmanaged 扱いに固定していた。
device set managed yes が success を返すのに無効化されるのも、conf.d/[device-wlp1s0] managed=true が効かないのも、全部この影響。
解決: 全プロファイルを keyfile に migrate して ifcfg-rh を外す
直し方は「ifcfg-rh プラグインを使うのを止めて、keyfile 形式に統一する」こと。NetworkManager 1.40 以降に nmcli connection migrate という移行コマンドが入っていて、既存ifcfg接続をそのままkeyfile形式に書き出してくれる。
手順:
su -
# 既存の全プロファイルをkeyfile形式に変換
nmcli connection migrate
# NetworkManagerのpluginsをkeyfileのみに変更
# /etc/NetworkManager/NetworkManager.conf を編集して:
# plugins=keyfile (ifcfg-rhを外す)
# キャッシュをクリアして再起動
rm /run/NetworkManager/devices/3 # wlp1s0のランタイム状態(空ファイル)
systemctl restart NetworkManagerこれで wlp1s0 が managed 状態に変わり、autoconnect 設定が効いて自動接続される。
変換後のプロファイルは /etc/NetworkManager/system-connections/<接続名>.nmconnection に keyfile 形式(INI風)で保存される(権限600)。ifcfg-wlp1s0 側は ifcfg-rh が外れたことで NM から見られなくなり、.bak として退避しておけば実害なし。
動いた後の状態
$ nmcli device
DEVICE TYPE STATE CONNECTION
wlp1s0 wifi 接続済み aterm-ikeda-a
eno1 ethernet 接続済み System eno1
lo loopback 管理無し --
$ nmcli -f all device show wlp1s0
GENERAL.NM-MANAGED: はい
IP4.ADDRESS[1]: 192.168.11.37/24
IP4.GATEWAY: 192.168.11.1
IP4.DNS[1]: 1.1.1.1
IP4.DNS[2]: 8.8.8.8- 再起動後も自動接続される
- 一般ユーザのデスクトップにもWi-Fi接続が出てくる
- 設定したDNS (Cloudflare + Google) も維持されている
connection.autoconnect-priority=50を立てておくと、複数Wi-Fi環境でこの接続が優先
Mageia固有ifcfgとifcfg-rhのミスマッチについて
Mageia は伝統的に drakx-net (Mandriva由来の独自ネットワーク管理) と NetworkManager の二重構造で、ifcfgも独自フィールドが入る。これがRHEL系前提のifcfg-rhプラグインと噛み合わないのが今回の根本原因。
Mageia 9 の drakconnect でWi-Fi設定を作って NM_CONTROLLED=yes にしても、NetworkManager側はifcfg-rh経由でしか見ないので、Mageia独自項目を含むifcfgはまるごと未対応扱いになる。
対処の方向性は2つ:
- keyfile に寄せる (今回採用): モダンなNetworkManager運用、他のディストリでも通用する知識
- drakx-net に寄せる:
systemctl enable network+wpa_supplicant.serviceの従来構成、Mageia流だがNM側のGUIから触れなくなる
検証ホスト用途で他のLinux知識が流用できる方が良いのでkeyfile派。
作業中に有線(eno1)を挿しておけばWi-Fi切れても作業継続できる。物理ケーブルが手元にあると安心。
日本語IME (Mozc) のデフォルト化
ibus-mozc 自体はMageia 9 の日本語ロケールで最初から入っていた(urpmi ibus-mozc で「既にインストール済み」と返る)。
ただし初期状態ではパネル右上が JA(キーボードレイアウト表示)のままで、ログイン直後にMozcエンジンが選択されておらず、半角/全角を押しても日本語変換にならない問題があった。
ibus list-engine でMozcエンジンの登録状況、ibus engine で現在の有効エンジンを確認した上で、preload-enginesをMozcに固定:
gsettings set org.freedesktop.ibus.general preload-engines "['mozc-jp']"
gsettings set org.freedesktop.ibus.general engines-order "['mozc-jp']"これでログイン直後から自動的にMozcモードになる。
初回の再起動では反映されなかった: 1回目の再起動ではpreload-enginesの変更が効かず、相変わらずJAから手動切替が必要な状態だった。2回目の再起動でようやく反映された。
原因は推測しかできない(~/.cache/ibus/ のキャッシュ残り、ibus-daemonの起動順序とgsettings読込のレース、あたり)が、ibus設定変更後に動作が怪しいときは 再起動を2回試してみる のが手っ取り早い。
gsettings はユーザ単位なので、root側のibus設定は別管理。普段rootでGUI日本語入力する場面は無いので保留したが、必要があれば su - 後に同じコマンドをroot側で打てばOK。
Chromeを入れる: rootでは起動できないのが正しい
ブラウザはChromeを入れたかったので、公式の Fedora/openSUSE 用 google-chrome-stable_current_x86_64.rpm をダウンロード → su - でrootになり urpmi ./google-chrome-stable_current_x86_64.rpm でインストール。これは問題なく通る。
その後 root のままターミナルから google-chrome-stable を叩くと起動しない。LinuxのChromeは設計上、rootからの起動を拒否する(sandbox プロセスがroot権限から特権を落とすモデルで動いていて、最初からrootだと落とす先がないため)。--no-sandbox を付ければ起動はするが、その名前の通りサンドボックス無効で危険な動かし方なので使わない。
一般ユーザ hide3tu でログインして同じコマンドを叩いたら普通に立ち上がった。これが正しい挙動で、Chromeをroot起動する必要は無い。インストール自体だけrootで行い、起動は常用ユーザで、という運用に倒す。
最終的にこいつは起動しっぱなしで外からSSHで叩く運用がメインになる予定で、GUIは初期設定とトラブル時の保険扱い。普段は他のPCからリモートで触る。Claude CodeとCodexも入れたのでそのまま開発機としても使える。検証ホストの当初の目的(コンテナ、VPSテスト引き上げ、Linuxカーネル系セキュリティの再現、Wine/Proton)もこれで土台が揃った。
ジャンクで買ってから気づいたことがあった。
ひとつはBIOSのバッテリーヘルス表示が「Good」だったこと。電源を外しっぱなしにしててもバッテリー残量がほとんど減らない。10世代Latitudeで1万円台、バッテリー生きてるなら出物としては当たり。
もうひとつはキーボードの数字キーの一部だけ反応が怪しいこと。固い面に置くと改善するので接触の問題っぽいが、調子悪いキーが決まっていて、しかも並びに偏りがある。前オーナーが特定のパスワードを延々入力してたとかでそのキーだけ摩耗が進んだのでは…と疑いたくなる。
外観はぼろぼろ、特定キーだけ接触不良、なのにバッテリーは元気。元の人ほんとに使ってたんだろうか、という見た目と中身のチグハグさは残るが、検証ホスト用途には何の問題もない。1万円台でこれだけ動けば文句なし。
今の壁紙。