自分のやらかしを共有しておこうと思います。エラーの原因はコレかも…という程度しか判明していないため、１つの事例として聞き流す程度にとどめて下さい
背景
• 学習環境：VirtualBox + AlmaLinux 9.3(イニシエータ)、 Ubuntu 24.04(ターゲット)
• iSCSI で自動マウントするために /etc/fstab を編集
• 再起動したら OS が立ち上がらなくなった
他サーバのストレージを利用するiSCSIの練習で起こりました。接続されたiSCSIディスクにファイルシステムを作成・マウントした後、システム起動時に自動でマウントできるように/etc/fstabにエントリを追加しました。
（/dev/sdbはファイルシステムの作成や自動マウントの練習として別で作成したもので、iSCSIで利用したものは/dev/sdcになります）
修正中の画像しかなかったため貼りましたが、修正前は以下の
/dev/sdb1 /task/sdb1
/dev/sdb2 /task/sdb2
/dev/sdc1 /iscsi-fs
発生した問題
• 再起動（shutdown -r now）：ログイン画面が出ない
• /etc/fstab に書いた /dev/sdb2 のマウントで失敗している模様
/etc/fstabを編集した後、再起動してもiSCSIが利用できるかを確認するために再起動を実施。すると画像の様に/task/sdb2のマウントに失敗したというログが表示されログイン画面が表示されなくなった。
復帰するために試したこと
• GRUBから systemd.unit=rescue.target で入ろうとしたが失敗
• GRUBから init=/bin/bash を追加してみると入れた
• デバイス名をUUID に書き換えて、オプションにnofailを追加して再起動 → 通常起動ができた
初めてエラーに出くわしたためどうすればいいのか途方に暮れていたのですが、ネットで検索したりChatGPTに相談して上記のことを試してみた。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
GRUBから systemd.unit=rescue.target で入ろうとしたが失敗した。ネットで調べたことを試してみたが、なぜか入ることができなかった。
ChatGPTによれば「rescue.target は rootfs + fstab のマウントが必要だからfstabの不整合で動けなくなった」と回答してきた。
また同時に「init=/bin/bash は fstabを無視して直接シェルを起動する」とも回答してきたため、それを実行してみたところ入ることに成功した。
情けない話だが、その後もChatGPTの指示通りのこと行った。
以下はChatGPTの指示の流れ
〇ルートファイルシステムを読み書き可能にする：mount -o remount,rw /
エラーによりルートファイルシステムが読み取り専用でマウントされているため、書き込み可能にするため再マウントする
〇fstabを修正：デバイス名をUUIDに、オプションにnofailを付ける
blkidコマンドでUUIDを調べ、それをfstabに書き込む （blkid /dev/sdb1）
/etc/fstab
UUID /task/sdb1 xfs defaults,nofail 0 0
UUID /task/sdb2 ext3 defaults,nofail 0 0
〇syncコマンドでディスクに反映
〇再起動：exec /sbin/init
再起動を行うとログイン画面が表示された
原因の考察
原因はfstabの編集をミスったからとしか言いようがない。ただ何がミスっていたのかを考えているとこんな記事を発見しました。
この記事によれば「デバイス名のずれ」というものがあるらしい。 /dev以下には認識されたハードディスクのデバイスファイルが作成され、ディスクは/dev/sda、/dev/sdbというように/dev/sd〇と命名される。自分はこのsdb、sdcを/etc/fstabに記載していたが、おそらくこのsd〇としたことが今回のエラーの原因だったのではないかと考えている。
Linuxは起動時にOSがディスクを認識した順番にsda、sdb、sdcと割り振っていくらしく、前回はsdbと割り振られていたディスクが次はsdcに割り振られるということがあるみたい。
自分の場合は/dev/sdbを/taskにマウント、/dev/sdcを/iscsiにマウントとfstabに書いてしまったため、/iscsiをマウントするはずのディスクが/taskをマウントしてしまいエラーとなった、と考えています。
また自分の貧弱な環境のせいで起こった可能性があります。
貧弱なPCスペックと貧弱なネット回線が重なり、他の仮想サーバのiSCSI ディスクが認識される前にsystemdがマウントを実行 → 失敗してブートが停止…
(VirtualBoxで2台の仮想サーバを用意しiSCSIの練習をしていました)
防止策
・UUIDの使用デバイス名のずれを回避するにはUUIDの使用が簡単な対策だと思います。UUIDだと認識された順番ではなく、デバイスそのものを指定するのでズレは起こりません。
・オプションにnofailをつける
iSCSIなどネットを介したものにはオプションでnofailをつける
まとめ
・/etc/fstabにデバイス名で設定するとズレてエラーを起こすことがある・/etc/fstabのデバイスファイル欄にはUUIDを使用するとズレが起こらない
・iSCSIなどネットを介したものにはオプションでnofailをつけておく
間違っている所があれば、是非ご指摘をお願いします！！
記事作成後に少しだけ試してみた
記事の作成後にデバイス名のズレが起こるのかを試してみた
iSCSIは利用せずローカルのディスクのみで行った。
sdbとsdcを追加した。UUIDを使用せず、今回は関係ないと思うがnofailもつけなかった。
30回ほど再起動させたが1度もエラーにならなかった。 デバイス名のズレでエラーになった可能性も十分ありえるが、今回の場合は自分の貧弱な環境のせいでエラーになったのかもしれない…
良いパソコン買わなきゃ
他の可能性があればご指摘をおねがいします！！