treedown’s Report

システム管理者に巻き起こる様々な事象を読者の貴方へ報告するブログです。会社でも家庭でも"システム"に携わるすべての方の共感を目指しています。

※https化しました。その影響でしばらくリンク切れなどがあるかもしれませんが徐々に修正していきます。 リンク切れなどのお気づきの点がございましたらコメントなどでご指摘いただけますと助かります。

Raspberry Piで問題発生?

ある日、Raspberry Piで動作するlogwatchで見慣れないエラーを発見し、対処する必要が出てきましたのでご報告です。

見慣れないエラー

ある日のlogwatch発行
--------------------- Kernel Begin ------------------------

WARNING: Kernel Errors Present
INFO: recovery required on readonly filesyste ...: 1 Time(s)

---------------------- Kernel End -------------------------

Kernel Errors で readonly filesyste という表記。

接続ができない状態になってしまいました。うーん。

確認のため手元に送ってもらう

このRaspberry Piは遠方に設置されているため、現地に連絡し送ってもらう。
そのときに
「最近、何度かオフィスの電気が落ちているので、そのせいかも…。」
なんて話も小耳に挟んだ。

どうも、停電?メンテナンス(計画停電?)、ブレーカーが落ちた?という要因でなんどか(二度か三度)オフィス内の電源が落ちているらしい。それで、意図せず電源ON/OFFが繰り返された結果、ファイルシステムに問題発生、と、なんかありそうな流れです。

まず、起動前に、「dd for Windows」を使って、Windows機でデータをバックアップしておきます。
バックアップ取得後、さっそく、Raspberry Piにモニタとキーボードを接続、OS起動して確認(普段はヘッドレス運用していても、やはりこういうときはコンソールからの確認がいちばんやりやすい)を開始します。

実機を確認

dmesgで確認
-----------------------------------------------------------------------------------------
$ dmesg | grep read-only
[ 0.932968] mmc0: host does not support reading read-only switch, assuming write-enable
-----------------------------------------------------------------------------------------
こんな感じで、問題の「recovery required on readonly filesyste」を探してみました。

f:id:treedown:20210202005843p:plain
実際のメッセージ
-----------------------------------------------------------------------------------------
[ 0.932968] mmc0: host does not support reading read-only switch, assuming write-enable
[ 0.964530] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[ 2.532276] EXT4-fs (mmcblk0p2): orphan cleanup on readonly fs
[ 2.785968] VFS: Mounted root (ext4 filesystem) read
-----------------------------------------------------------------------------------------
「EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem」の記載が「情報:読み取り専用ファイルシステムでリカバリが必要です」という行と、「EXT4-fs (mmcblk0p2): orphan cleanup on readonly fs」の記載に「読み取り専用fs(たぶんファイルシステム)での孤立したクリーンアップ」という記載から、どうやらファイルシステムに問題が発生していると考えられました。
ファイルシステムがreadonly(読み取り専用)になってしまっているため、ログの保存も出来ずプロセスの起動にも影響しており使いたい機能が使えなくなっている、ということじゃないかと仮説。

こういうときは、まずはfsckコマンドでファイルシステムの確認と修復を試みるのが定番なのですが、fsckはマウントしているボリュームを対象としてファイルシステムチェックを実施することが出来ません。
PCサーバだとHDDを取り外して別のPCの2ndHDDになるよう取り付けてfsckを実行するという復旧方法を実施したこともあるのですが、今回はRaspberry Pi、microSD、うーん、どうしよう。
ということで、起動時にfsckが実行されるように設定し、OSを再起動してみることにしました。
「/boot」に「cmdline.txt」というファイルがあり、起動時に実行するコマンドが記載されています。
--------------------------------------------------------------
$ cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=00000000-00 rootfstype=ext4 elevator=deadline fsck.repair=yes rootdelay=10 rootwait
--------------------------------------------------------------
これに、fsckコマンドを追記。
--------------------------------------------------------------
$ cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=00000000-00 rootfstype=ext4 elevator=deadline fsck.repair=yes rootdelay=10 rootwait
fsck.mode=force
--------------------------------------------------------------
Debianだと<https://wiki.debian.org/Ext4>にあるように「/etc/default/grub」に「fsck.mode=force」を書き込んでねという記述があります。
Raspberry Piだと、Windowsで読み書き可能な/bootのパーティションにあるcmdline.txtをテキストエディタで開いて上記のように追記すればいいだけでした。

さっそく再起動

「/boot/cmdline.txt」にfsckの実行を記述すると、OS起動時にfsckが実行されます。
再起動後、同様のdmesg確認では

f:id:treedown:20210202005928p:plain
-------------------------------------------------------------
[ 0.933012] mmc0: host does not support reading read-only switch, assuming write-enable
[ 0.973993] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
--------------------------------------------------------------
「EXT4-fs (mmcblk0p2)」で始まっていた行が表示されなくなり、症状は治ったような気が…
試しにmmcblk0p2をgrepしてみると、
--------------------------------------------------------------
$ dmesg | grep mmcblk0p2
[ 0.973933] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 3.575032] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
--------------------------------------------------------------
「orderedなデータモードでマウントされたファイルシステム」とか、「再マウント」とか表示が出てきましたが、問題となった「read-only」は表示されなくなりました。
どうも修復できたような気がするのでfsckをgrepで抽出し確認してみると、
--------------------------------------------------------------
$ dmesg | grep fsck
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=PARTUUID=140e2d5e-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
--------------------------------------------------------------

…うーん、なんだかよく分らなかった…。

でも、read-onlyが含まれたメッセージが記録されていないし、保存できないファイルなどもなく、ファイルシステムは無事使える状態に戻ったよう。

続きます。

何とか稼働するようになったのは良いのですが、ファイルシステムがread-onlyになっていたせいか、内部時計が障害発生時の日時のままになってしまっていました。
これを元に戻す必要があったので、別途実施。