Raspberry Pi のじろ君が突然立ち上がらなくなってしまいました。ブート SD Card を他の PC に挿して色んな検査ツールで調べてみても特に異常は出てこないのですが、じろ君に使うとどうもブート中の fsck 実行中に戻ってこなくなるらしい。メディアを焼き直してもう一度やり直しても良いんですが、後学のためにも何があったかもう少し知りたいところ、そこで USB メディアを使ってそこから「新生・じろ」を立ち上げつつ、もとのブートディスクを二番目のディスクとしてつないで調べてみようという算段を立てました。
ということで、さっそく近所の電気屋さんから一番安い USB メモリを買ってきました。1000円なり。
USB から Raspberry Pi を起動するやり方を色々なサイトで調べてみましたが紹介されている方法はどれも煩雑！Raspberry Pi Imager という強力アプリがあるのにそんなことある？このアプリからブートイメージを書き込んでそれを使うだけで OK なのでは？と、ダメ元でやってみたらできました。よかった
そして、ブートをかけてみたところ、動きがどうにもおかしいです。メディアを認識したりしなかったり、立ち上がったりいきなり落ちたり。不安定でとても使えません。USB メモリは駄目なのかこのメディアがとりたてて性能が悪いのか。まあとにかく、駄目です。
仕方なくもう一回電気屋さんに行ってきました。選手交代です。色々と試したいこともあるし、今度は贅沢に SSD で行きます。これで性能の心配だけはありますまい。
今度も Raspberry Pi Imager が無事に使えました。優秀なアプリだと思います。
じろ君に挿して、今度は何の問題も起こさず無事に起動しました「新生じろ」。SSH でも繋がります。次に、USB/SSD と SD Card 両方を挿して使いたいのですが、Raspberry Pi のデフォルトのブート順序は SD が先、次に USB です。これは不都合なので raspi-config コマンドで設定を変えます。
はいこれで解決、と思いきや、USB SSD と SD Card 両方を挿して立ち上げてみたところ、
またディスクを認識したところで固まりました。ええこれ、たちの悪い。でもこれきっと fsck をかけて固まったのでしょう。SD Card を刺さずに立ち上げ、その後に挿してみたところ、デバイスが無事に認識されやっと先に進めます。
naoki@jiro:/var/log $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 232.9G 0 disk
├─sda1 8:1 0 512M 0 part /boot/firmware
└─sda2 8:2 0 232.4G 0 part /
mmcblk0 179:0 0 119.1G 0 disk
├─mmcblk0p1 179:1 0 512M 0 part
└─mmcblk0p2 179:2 0 118.6G 0 part
naoki@jiro:/var/log $ ls /dev/mmcblk0
/dev/mmcblk0まずはメディア自体が壊れていないかチェックしてみます。メディアが壊れるほどには酷使してませんし、ないだろうとは思うんですが可能性は一個一個潰してゆくということで。ディスクの検査なんて普段やりませんから方法がわかりません。が、良い記事が見つかりました。
https://www.baeldung.com/linux/storage-device-check-health
多くの資料が「smartctl を使え」と書いているんですが、この記事には USB ドライブや SD Card などは対応していないと説明があって助かりました。でも、「そんな場合にはそもそも USB メモリの類をストレージとして使うのは不適切だということをまず考えるべき」と太字で書かれてます。ええ百も承知。でもそうくぎを刺しつつ、「その場合は badblocks コマンドを使いなさい」と書いてありました。フランチェスコさん親切な人。では早速、でも念のため badblocks の man ページを読んでみたら、
Important note: If the output of badblocks is going to be fed to the e2fsck or mke2fs programs, it is important that the block size is properly specified, since the block numbers which are generated are very dependent on the block size in use by the file system. For this reason, it is strongly recom‐ mended that users not run badblocks directly, but rather use the -c option of the e2fsck and mke2fs programs.
badblocks は直接実行せずに e2fsck から -c オプションで呼んだ方が良いよ、と。-c オプションとは、ファイルシステムチェックの最初の段階で badblocks を呼んで物理的な故障がないかのチェックを加えること。今度こそオーケー、いきますよ
naoki@jiro:/var/log $ sudo fdisk /dev/mmcblk0 -l
Disk /dev/mmcblk0: 119.08 GiB, 127865454592 bytes, 249737216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x7a05c20a
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 1056767 1048576 512M c W95 FAT32 (LBA)
/dev/mmcblk0p2 1056768 249737215 248680448 118.6G 83 Linux
# ブートストラップは無事にかかっているので FAT32 のパーティションは壊れていないとして...
naoki@jiro:/var/log $ sudo e2fsck -c -C 0 -v /dev/mmcblk0p2
e2fsck 1.47.0 (5-Feb-2023)
rootfs: recovering journal
Checking for bad blocks (read-only test): 6.93% done, 3:35 elapsed. (0/0/0 errors)これはむちゃくちゃ時間がかかりそうです。風呂行ってきます。
風呂から戻ったらプロンプトが来てました。適当に返答しつつ、fsck が終わりました。
naoki@jiro:/var/log $ sudo e2fsck -c -C 0 -v /dev/mmcblk0p2
e2fsck 1.47.0 (5-Feb-2023)
rootfs: recovering journal
Checking for bad blocks (read-only test): done
rootfs: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Inode 615 extent tree (at level 2) could be narrower. Optimize<y>? no
Inode 1407 extent tree (at level 2) could be narrower. Optimize<y>? no
Inode 59113 extent tree (at level 2) could be narrower. Optimize<y>? no
Inode 59617 extent tree (at level 1) could be narrower. Optimize<y>? no
Inode 61867 extent tree (at level 2) could be narrower. Optimize<y>? no
Inode 61868 extent tree (at level 2) could be narrower. Optimize<y>? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (28621775, counted=28619727).
Fix<y>? yes
Free inodes count wrong (7183251, counted=7183250).
Fix<y>? yes
rootfs: ***** FILE SYSTEM WAS MODIFIED *****
211358 inodes used (2.86%, out of 7394608)
520 non-contiguous files (0.2%)
129 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 203936/57/5
2465329 blocks used (7.93%, out of 31085056)
0 bad blocks
1 large file
190844 regular files
13050 directories
8 character device files
0 block device files
0 fifos
418 links
7447 symbolic links (7344 fast symbolic links)
0 sockets
------------
211767 filesメディアの不良はない模様。ファイルシステムに壊れが見つかって修正をかけました。これで直ったのかな？SD Card をブートディスクにして再起動です。
結果：またハングしてしまう
心が折れそうです。まあでも気を取り直してもう一度ファイルシステムチェックにかけてみましょう
naoki@jiro:~ $ sudo e2fsck -fp -C 0 -v /dev/mmcblk0p2
rootfs: Inode 615 extent tree (at level 2) could be narrower. IGNORED.
rootfs: Inode 1407 extent tree (at level 2) could be narrower. IGNORED.
Inode 59113 extent tree (at level 2) could be narrower. IGNORED.
rootfs: Inode 59617 extent tree (at level 1) could be narrower. IGNORED.
rootfs: Inode 61867 extent tree (at level 2) could be narrower. IGNORED.
rootfs: Inode 61868 extent tree (at level 2) could be narrower. IGNORED.
211359 inodes used (2.86%, out of 7394608)
521 non-contiguous files (0.2%)
129 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 203937/57/5
2467377 blocks used (7.94%, out of 31085056)
0 bad blocks
1 large file
190845 regular files
13050 directories
8 character device files
0 block device files
0 fifos
418 links
7447 symbolic links (7344 fast symbolic links)
0 sockets
------------
211768 filesファイルシステムに矛盾はもはやないようです。前回の修復の時に何かのファイルが壊れたのかもしれません。というかきっとそうでしょう。iノードの数が合わないと言われたのだから。何のファイルが壊れたか突き止めるのは至難ですのでもうあきらめモードですが、念のためメディアをマウントしてブート時のログに何か残っていないか見てみます。
naoki@jiro:~ $ sudo mkdir -p /mnt/secondary
naoki@jiro:~ $ sudo mount /dev/mmcblk0p2 /mnt/secondary
mount: (hint) your fstab has been modified, but systemd still uses
the old version; use 'systemctl daemon-reload' to reload.
naoki@jiro:~ $ ls /mnt/secondary
naoki@jiro:~ $ sudo su -
root@jiro:~# cd /mnt/secondary/var/log
root@jiro:/mnt/secondary/var/log# ls -lat
total 108
-rw-rw-r-- 1 root utmp 51200 Aug 13 20:04 wtmp
-rw-rw-r-- 1 root utmp 296296 Aug 13 20:04 lastlog
-rw-r--r-- 1 root root 19069 Aug 12 12:35 dpkg.log
drwxr-xr-x 2 root root 4096 Aug 12 12:35 apt
-rw-r--r-- 1 root root 282 Aug 12 12:33 alternatives.log
drwxr-xr-x 11 root root 4096 Jul 4 00:14 ..
-rw-rw---- 1 root utmp 0 Jul 4 00:14 btmp
-rw-r--r-- 1 root root 0 Jul 4 00:14 faillog
-rw-r--r-- 1 root root 0 Jul 4 00:14 bootstrap.log
drwxr-sr-x+ 3 root systemd-journal 4096 Jul 4 00:14 journal
drwxr-xr-x 3 root root 4096 Jul 4 00:06 runit
drwxr-xr-x 6 root root 4096 Jul 4 00:06 .
drwx------ 2 root root 4096 Jul 4 00:04 private
lrwxrwxrwx 1 root root 39 Jul 4 00:04 README -> ../../usr/share/doc/systemd/README.logs
root@jiro:/mnt/secondary/var/log# date
Thu 15 Aug 15:25:54 UTC 2024syslog がない。どうしたのか？調べたら情報ありました。
https://forums.raspberrypi.com/viewtopic.php?t=358028
Its a change from Debian. The syslog files were removed as it used to redundantly log to both the systemd journal and the files. Use journalctl to review the journal. If you want the syslog files back then install rsyslog.
まじか。詰んだ？いやいや。データがどこかに残ってるだろ。
naoki@jiro:~ $ sudo journalctl --root=/mnt/secondary | tail
Aug 13 20:05:01 jiro kernel: vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
Aug 13 20:05:01 jiro kernel: bcm2835_vc_sm_cma_probe: Videocore shared memory driver
Aug 13 20:05:01 jiro kernel: [vc_sm_connected_init]: start
Aug 13 20:05:01 jiro kernel: [vc_sm_connected_init]: installed successfully
Aug 13 20:05:01 jiro kernel: v3d fec00000.v3d: Failed to allocate page tables. Please ensure you have DMA enabled.
Aug 13 20:05:01 jiro kernel: snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
Aug 13 20:05:01 jiro kernel: v3d: probe of fec00000.v3d failed with error -12
Aug 13 20:05:01 jiro kernel: bcm2835_audio bcm2835_audio: card created with 8 channels
Aug 13 20:05:01 jiro kernel: Unable to handle kernel write to read-only memory at virtual address ffffffed258e603c
Aug 13 20:05:01 jiro kernel: Mem abort info:
naoki@jiro:~ $ date
Thu 15 Aug 15:41:02 UTC 2024起動ログがない．．．いやまて。最後のメッセージはシステムクラッシュの痕跡では？なにかメモリ周りの問題？Hugetable サポートを加えて何かが起きた？二日前というのはちょうどじろ君が立ち上がらなくなった頃です。メディアの不良じゃなくてカーネルの設定を変えたせいで何かのバグを踏んだ？ファイルシステムの壊れは原因じゃなくて結果だったりして？
これはわからない。わかりませんが保留しつつしばらくちょっと別の話題に行こうかと思います。この SD Card はとりあえずまだ保管、もっと調べるとまだ何か出てくるかもしれません
