「apt autoremoveは不要パッケージを消すだけの安全なコマンド」という認識でいたのですが、今回の経験でその認識は完全に改まりました。実行後の再起動でネットワークが消え、RAIDアレイまで停止するという事態に陥りました。
今回はRaspberry Pi (Debian) + OpenMediaVault (OMV) によるNASサーバーで発生したトラブルと、その復旧手順を実録として残しておきます。同じ状況で困っている方の参考になれば幸いです。
何が起きたのか
定期メンテナンスとして以下を実行しました。
sudo apt upgrade
sudo apt autoremove
sudo reboot再起動後、SSHで接続できなくなりました。ネットワークが消えていたのです。
autoremoveで削除されたもの
/var/log/apt/history.logを確認したところ、autoremoveによって以下のような重要パッケージが根こそぎ削除されていました。
netplan.io/libnetplan0— ネットワーク設定管理ツールsalt-minion— OMVの設定管理デーモン（OMVの動作に必須）samba/samba-common-bin— ファイル共有サービスnginx/php-fpm— OMVのWeb UIに必要なWebサーバーmdadm— RAIDアレイ管理ツールcollectd/rrdtool— パフォーマンス監視
OMVに必要なパッケージがほぼ全て消えていました。autoremoveは「不要なパッケージ」を削除するコマンドですが、依存関係の判定が実態と合っていない場合に、動作中のシステムに必要なパッケージまで削除することがある様です。
トラブル1：ネットワークが消えた
原因
ネットワーク管理に関連するパッケージが削除されたことで、インターフェースの命名・設定ルールが壊れました。それまでeth0として認識・設定されていた本体の有線LANが、起動後にend0という見慣れない名前に変わってしまい、接続設定が機能しない状態になりました。
今回のトラブルで初めて、オンボードNICのLinux内部での扱いを意識することになりました。Raspberry Piの本体有線LANは、OS側の命名規則によってeth0やend0など異なる名前が付くことがあります。
応急処置：/etc/network/interfaces をべた書きして復旧
キーボードとモニターをRaspberry Piに直接接続し、ローカルで操作しました。まず現在認識されているインターフェース名を確認します。
ip address showあるいは
ifconfig -aこの時点でインターフェース名がeth0からend0に変わっていることが判明しました。次に/etc/network/interfacesの中身を確認したところ、ほぼ空の状態になっていました。そこで直接設定を書き込みます。
sudo vi /etc/network/interfaces以下の内容を記述して保存します（インターフェース名はip address showで確認したものに合わせてください）。
auto lo
iface lo inet loopback
auto end0
iface end0 inet dhcp保存後、ネットワークを再起動します。
sudo systemctl restart networkingこれでネットワークへの接続が復旧しました。
OMVの再インストールでeth0が復活
応急処置のあと、壊れたOMV環境を修復するためにOMVを再インストールしました。すると、インストール処理の中でOMVが自動的に/etc/systemd/network/10-persistent-eth0.linkというファイルを生成し、オンボードNICがeth0に固定されました。
cat /etc/systemd/network/10-persistent-eth0.link[Match]
MACAddress=xx:xx:xx:xx:xx:xx
[Link]
Name=eth0MACアドレスを指定してインターフェース名を固定する仕組みです。この.linkファイルがあると、udevの自動命名（end0やenx...）よりも優先されてインターフェース名が確定します。これがトラブル前のeth0に戻った理由でした。
補足：USB NICをeth1に固定する方法
同じ仕組みを使えば、USB接続のイーサネットアダプタも好きな名前に固定できます。例えばenx112233445566という名前になっているUSB NICをeth1に固定するには、同様のファイルを作成するだけです。
sudo tee /etc/systemd/network/11-persistent-eth1.link << 'EOF'
[Match]
MACAddress=11:22:33:44:55:66
[Link]
Name=eth1
EOF
再起動後にip link showでeth1として認識されるようになります。
トラブル2：RAIDアレイが停止した
OMVを再インストールして各種サービスは復旧したものの、今度はRAIDのステータスが「Missing」となりデータにアクセスできない状態になりました。
原因
mdadmが削除されていたことでRAIDの管理デーモンが消え、OMV再インストール後もアレイがinactive状態のまま起動するようになっていました。
Step 1: 現状確認
cat /proc/mdstat以下のような表示が出た場合、アレイは認識されているが非アクティブな状態です。
md127 : inactive sdb[1](S) sdd[3](S) sdc[2](S) sda[4](S)
15627545952 blocks super 1.2# アレイ情報のスキャン
sudo mdadm --examine --scanARRAY /dev/md/VolRaid5 metadata=1.2 UUID=xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx name=hostname:VolRaid5UUIDが表示されれば、データ自体は無事な可能性が高いです。
Step 2: 各ディスクのスーパーブロックを確認
sudo mdadm --examine /dev/sda | grep -E "Role|Events|Array State"
sudo mdadm --examine /dev/sdb | grep -E "Role|Events|Array State"
sudo mdadm --examine /dev/sdc | grep -E "Role|Events|Array State"
sudo mdadm --examine /dev/sdd | grep -E "Role|Events|Array State"確認すべきポイントは2つです。
Device RoleがActive device 0〜Active device 3と表示されているか → データが存在している証拠Eventsの数値が全台で揃っているか → ずれている場合は後述の--forceオプションが必要
今回はsdaとsddがEvents: 112338、sdbとsdcがEvents: 112343と数カウントずれており、このズレがアクティブ化を妨げていました。
Step 3: 強制アセンブル
Eventsの値が大きい（より新しい）ディスクを先頭に指定して強制アセンブルします。
# まず既存の不完全なアレイを停止
sudo mdadm --stop /dev/md127
# Eventsが新しいディスク（今回はsdb）を先頭に指定して強制アセンブル
sudo mdadm --assemble --force /dev/md127 \
/dev/sdb /dev/sdc /dev/sda /dev/sdd# 状態確認
cat /proc/mdstat
sudo mdadm --detail /dev/md127State : activeまたはactive, degradedと表示されれば成功です。degradedはRAID5の場合1台欠損状態ですが、データは読めます。
Step 4: マウントとOMVへの反映
# マウントポイントを作成してマウント（パスはOMVの設定に合わせて）
sudo mount /dev/md127 /srv/dev-disk-by-uuid-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
# データが見えることを確認
ls /srv/dev-disk-by-uuid-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/マウントが確認できたら、OMVのWeb UIから Storage → File Systems → Mount を実行し、右上の Apply Changes を適用します。
Step 5: 永続化（再起動後も自動マウントされるよう設定）
# mdadm.confを正しい情報で上書き
sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
# initramfsを更新（これをしないと再起動後に再びinactiveになる）
sudo update-initramfs -u
# 確認
cat /etc/mdadm/mdadm.conf備忘録：OMVはカーネルバージョンを固定している
今回の調査で知ったことですが、OMVは動作対象のカーネルバージョンを固定しています。実際、以前カーネルアップデートを行った後にOMVのWeb UIが起動しない状態になった経験がありましたが、これが原因でした。
OMVのメジャーバージョンは特定のDebianバージョン（＝カーネルバージョン）に対応しており、カーネルを上げると互換性が失われてWeb UIが起動しなくなります。
対処方法としては、新しいカーネルに対応した新しいOMVバージョンが出るのを待ち、OMVのバージョンも合わせてアップグレードするという手順が必要です。カーネルだけ先に上げることは避けましょう。
アップグレードの前に必ずOMVの公式サイトやリリースノートで対応状況を確認することをお勧めします。
今後のために：autoremoveは必ずdry-runで確認してから
今回の教訓として、apt autoremoveを実行する前には必ず--dry-runオプションで削除対象を確認することを強くお勧めします。
# 削除されるパッケージを確認するだけで、実際には何も削除しない
sudo apt autoremove --dry-run出力にsalt-minion、samba、mdadm、nginx、php-fpmなどが含まれている場合は、そのまま実行すると重大な障害につながります。
また、重要なパッケージを自動削除対象から保護するには以下のようにします。
# 重要パッケージを自動削除対象から除外
sudo apt-mark manual mdadm salt-minion samba nginx php8.2-fpmapt-mark manualでマーク済みのパッケージは、autoremoveの対象から外れます。OMVのように独自の依存関係を持つシステムでは、インストール後に一度このコマンドを実行しておくと安心です。
まとめ
今回のトラブルは、apt autoremoveが引き起こした連鎖障害でした。
| 障害 | 原因 | 復旧方法 |
|---|---|---|
| ネットワーク消失（eth0→end0） | netplan等のネットワーク関連パッケージ削除 | /etc/network/interfacesに直接記述でネット復活 → OMV再インストールでeth0復活 |
| RAIDがinactive | mdadm削除 + Eventsのズレ | --forceオプションで強制アセンブル → initramfs更新で永続化 |
| OMV Web UI停止 | salt-minion / nginx / php-fpm削除 | OMV再インストール |
apt autoremoveは便利なコマンドですが、OMVやDockerなど独自の依存関係を持つシステムでは、必ず--dry-runで確認してから実行することを習慣にしてください。また、OMVのカーネル固定の仕様も忘れずに頭に入れておきましょう。
同じようなトラブルに見舞われた方の参考になれば幸いです。
