Raspberry PiのシステムSDカードのディスクイメージを収めた圧縮ファイルを gzip で解凍しようとするも、「 unexpected end of file 」エラーで異常終了する現象に遭遇。なんとか復元して中身を取り出せないか試してみました。
img.gz解凍時の「unexpected end of file」エラー
以前取得した、Raspberry Pi のシステムSDバックアップイメージの中身を確認する必要があったので、Ubuntuのアーカイブマネージャから展開しようとするも、途中でエラーとなり解凍できません。
GUIではエラーの内容すらわからないので、コマンドラインから解凍しようとして、返ってくるエラー内容がこの unexpected end of file です。
1 2 |
$ gzip -d ./piaware1.img.gz gzip: ./piaware1.img.gz: unexpected end of file |
zcatで取り出す
圧縮ファイルの内容を表示する zcat コマンドを使って、次の要領で中身のイメージファイルを取り出してみます。
1 2 3 4 5 6 7 8 9 |
$ zcat piaware1.img.gz > piaware1.img gzip: piaware1.img.gz: unexpected end of file $ ls -l -rw-rw-r-- 1 user user 7139057996 Feb 8 22:38 piaware1.img -rw-r--r-- 1 user user 1276805120 Feb 8 20:25 piaware1.img.gz $ sudo partx -s piaware1.img NR START END SECTORS SIZE NAME UUID 1 8192 230413 222222 108.5M 62f06e5f-01 2 237568 31387647 31150080 14.9G 62f06e5f-02 |
partx で確認すると、確かに2つのパーティションが存在していました。
gzrecoverによる修復
また、 gzrecover というコマンドを使うと修復可能とのことですが、こちらは標準では入っていないのでインストールから(公式サイトはこちら)。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
$ gzrecover Command 'gzrecover' not found, but can be installed with: sudo apt install gzrt $ sudo apt install gzrt パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています 状態情報を読み取っています... 完了 以下のパッケージが新たにインストールされます: gzrt アップグレード: 0 個、新規インストール: 1 個、削除: 0 個、保留: 2 個。 9,510 B のアーカイブを取得する必要があります。 この操作後に追加で 57.3 kB のディスク容量が消費されます。 取得:1 http://archive.ubuntu.com/ubuntu bionic/universe amd64 gzrt amd64 0.8-1 [9,510 B] 9,510 B を 1秒 で取得しました (19.0 kB/s) 以前に未選択のパッケージ gzrt を選択しています。 (データベースを読み込んでいます ... 現在 764108 個のファイルとディレクトリがインストールされています。) .../archives/gzrt_0.8-1_amd64.deb を展開する準備をしています ... gzrt (0.8-1) を展開しています... gzrt (0.8-1) を設定しています ... man-db (2.8.3-2ubuntu0.1) のトリガを処理しています ... |
早速実行してみると戻り値は無いものの、圧縮ファイルの中身であるイメージファイルが、修復されたファイルとして生成されていました。
1 2 3 4 5 6 7 8 9 |
$ gzrecover piaware1.img.gz $ ls -l -rw-r--r-- 1 user user 1276805120 Feb 8 20:25 piaware1.img.gz -rw------- 1 user user 7139057996 Feb 8 21:36 piaware1.img.recovered -rw------- 1 user user 0 Feb 8 21:34 stdin.recovered $ sudo partx -s piaware1.img.recovered NR START END SECTORS SIZE NAME UUID 1 8192 230413 222222 108.5M 62f06e5f-01 2 237568 31387647 31150080 14.9G 62f06e5f-02 |
zcat で取り出したイメージファイルと微妙にファイルサイズが異なりますが、 partx で見るパーティション情報は同じものでした。
取り出したイメージをマウントして確認
以前のこちらの記事に沿って、取り出したイメージをループデバイスに登録して検証してみるのですが、結果的には上述どちらのイメージを使っても同じでした。まず、 partx でループデバイスに登録してパーティションチェック。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
$ sudo partx -v -a ./piaware1.zcat.img パーティション: none, ディスク: ./piaware1.zcat.img, 下限: 0, 上限: 0 ループバックデバイスとして '/dev/loop19' を使用しようとしています /dev/loop19: パーティション情報のタイプ 'dos' を検出しました range recount: max partno=2, lower=0, upper=0 /dev/loop19: パーティション #1 を追加しました /dev/loop19: パーティション #2 を追加しました $ sudo fdisk -lu /dev/loop19 ディスク /dev/loop19: 6.7 GiB, 7139057664 バイト, 13943472 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスクラベルのタイプ: dos ディスク識別子: 0x62f06e5f デバイス 起動 開始位置 最後から セクタ サイズ Id タイプ /dev/loop19p1 8192 230413 222222 108.5M c W95 FAT32 (LBA) /dev/loop19p2 237568 31387647 31150080 14.9G 83 Linux $ losetup -l loop19 NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop19 0 0 0 0 piaware1.zcat.img 0 512 |
その後の fsck では、システムルートの収められた2つ目のパーティションで大量の修復不能エラーに見舞われます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
$ sudo fsck -fy /dev/loop19p1 fsck from util-linux 2.31.1 fsck.fat 4.1 (2017-01-24) /dev/loop19p1: 211 files, 45714/218770 clusters $ sudo fsck -fy -t ext4 /dev/loop19p2 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking iノードs, blocks, and sizes Error reading block 2097184 (入力/出力エラーです) while getting next inode from scan. Ignore error? yes Force rewrite? yes --- 略 --- Error reading block 3673592 (入力/出力エラーです) while getting next inode from scan. Ignore error? yes Force rewrite? yes Pass 2: Checking ディレクトリ structure Pass 3: Checking ディレクトリ connectivity Pass 4: Checking reference counts Pass 5: Checking グループ summary information Error reading block 2097152 (入力/出力エラーです) while reading inode and block bitmaps. Ignore error? yes Force rewrite? yes --- 略 --- Error reading block 3670029 (入力/出力エラーです) while reading inode and block bitmaps. Ignore error? yes Force rewrite? yes Block ビットマップ differences: +(2097152--2105327) +(2621440--2629615) +(2654208--2654320) +(3145728--3153903) +(3670016--3673592) 修正? yes Error writing file system info: 入力/出力エラーです rootfs: ***** ファイルシステムは変更されました ***** |
それでも正常にマウントして、(おそらく破損箇所に当たらなければ)中身を読み出すことが出来ました。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
$ sudo mount -t ext4 /dev/loop19p2 /mnt/part $ ls -l /mnt/part drwxr-xr-x 2 root root 4096 Sep 20 2019 bin drwxr-xr-x 2 root root 4096 Sep 20 2019 boot drwxr-xr-x 3 root root 4096 Sep 20 2019 build drwxr-xr-x 4 root root 4096 Sep 20 2019 dev drwxr-xr-x 93 root root 4096 Nov 6 2019 etc drwxr-xr-x 3 root root 4096 Sep 20 2019 home drwxr-xr-x 16 root root 4096 Sep 20 2019 lib drwx------ 2 root root 16384 Sep 20 2019 lost+found drwxr-xr-x 2 root root 4096 Sep 20 2019 media drwxr-xr-x 2 root root 4096 Sep 20 2019 mnt drwxr-xr-x 3 root root 4096 Sep 20 2019 opt drwxr-xr-x 2 root root 4096 Sep 10 2019 proc drwx------ 3 root root 4096 Nov 5 2019 root drwxr-xr-x 5 root root 4096 Sep 20 2019 run drwxr-xr-x 2 root root 4096 Nov 5 2019 sbin drwxr-xr-x 2 root root 4096 Sep 20 2019 srv drwxr-xr-x 2 root root 4096 Sep 10 2019 sys drwxrwxrwt 7 root root 4096 Nov 7 2019 tmp drwxr-xr-x 10 root root 4096 Sep 20 2019 usr drwxr-xr-x 12 root root 4096 Sep 20 2019 var $ sudo umount /mnt/part $ sudo partx -v -d /dev/loop19 パーティション: none, ディスク: /dev/loop19, 下限: 0, 上限: 0 /dev/loop19: パーティション #1 を削除しました /dev/loop19: パーティション #2 を削除しました $ sudo losetup -d /dev/loop19 $ sudo losetup -f /dev/loop19 |
後日生成された別のイメージでは問題なし
このような現象ではSDカードの破損を疑うものですが、たまたまこれより後に生成されたバックアップイメージがあったので、同様に検証してみました。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 |
$ ls -l -rwxr--r-- 1 user user 697949030 Feb 8 23:05 piAware_20210114.7z -rw-rw-r-- 1 user user 16070475776 Feb 9 20:06 piAware_20210114.img $ sudo partx -v -a ./piAware_20210114.img パーティション: none, ディスク: ./piAware_20210114.img, 下限: 0, 上限: 0 ループバックデバイスとして '/dev/loop19' を使用しようとしています /dev/loop19: パーティション情報のタイプ 'dos' を検出しました range recount: max partno=2, lower=0, upper=0 /dev/loop19: パーティション #1 を追加しました /dev/loop19: パーティション #2 を追加しました $ losetup -l /dev/loop19 NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop19 0 0 0 0 piAware_20210114.img 0 512 $ sudo partx -s ./piAware_20210114.img NR START END SECTORS SIZE NAME UUID 1 8192 230413 222222 108.5M 62f06e5f-01 2 237568 31387647 31150080 14.9G 62f06e5f-02 $ sudo fdisk -lu /dev/loop19 ディスク /dev/loop19: 15 GiB, 16070475776 バイト, 31387648 セクタ 単位: セクタ (1 * 512 = 512 バイト) セクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト ディスクラベルのタイプ: dos ディスク識別子: 0x62f06e5f デバイス 起動 開始位置 最後から セクタ サイズ Id タイプ /dev/loop19p1 8192 230413 222222 108.5M c W95 FAT32 (LBA) /dev/loop19p2 237568 31387647 31150080 14.9G 83 Linux $ sudo fsck -fy /dev/loop19p1 fsck from util-linux 2.31.1 fsck.fat 4.1 (2017-01-24) 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Automatically removing dirty bit. Free cluster summary wrong (173055 vs. really 173052) Auto-correcting. Performing changes. /dev/loop19p1: 214 files, 45718/218770 clusters $ sudo fsck -fy -t ext4 /dev/loop19p2 fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) Pass 1: Checking iノードs, blocks, and sizes Pass 2: Checking ディレクトリ structure Pass 3: Checking ディレクトリ connectivity Pass 4: Checking reference counts Pass 5: Checking グループ summary information rootfs: 54229/969136 files (0.3% non-contiguous), 434172/3893760 blocks $ sudo mount -t ext4 /dev/loop19p2 /mnt/part $ ls -l /mnt/part drwxr-xr-x 2 root root 4096 Sep 20 2019 bin drwxr-xr-x 2 root root 4096 Sep 20 2019 boot drwxr-xr-x 3 root root 4096 Nov 8 2019 boot.bak drwxr-xr-x 3 root root 4096 Sep 20 2019 build drwxr-xr-x 4 root root 4096 Sep 20 2019 dev drwxr-xr-x 93 root root 4096 Oct 31 2020 etc drwxr-xr-x 3 root root 4096 Sep 20 2019 home drwxr-xr-x 16 root root 4096 Sep 20 2019 lib drwx------ 2 root root 16384 Sep 20 2019 lost+found drwxr-xr-x 2 root root 4096 Sep 20 2019 media drwxr-xr-x 2 root root 4096 Sep 20 2019 mnt drwxr-xr-x 3 root root 4096 Sep 20 2019 opt drwxr-xr-x 2 root root 4096 Sep 10 2019 proc drwx------ 4 root root 4096 Nov 8 2019 root drwxr-xr-x 5 root root 4096 Sep 20 2019 run drwxr-xr-x 2 root root 4096 Nov 5 2019 sbin drwxr-xr-x 2 root root 4096 Sep 20 2019 srv drwxr-xr-x 2 root root 4096 Sep 10 2019 sys drwxr-xr-x 2 root root 4096 Nov 15 2019 tmp drwxr-xr-x 10 root root 4096 Sep 20 2019 usr drwxr-xr-x 12 root root 4096 Nov 15 2019 var $ sudo umount /mnt/part $ sudo partx -v -d /dev/loop19 パーティション: none, ディスク: /dev/loop19, 下限: 0, 上限: 0 /dev/loop19: パーティション #1 を削除しました /dev/loop19: パーティション #2 を削除しました $ sudo losetup -d /dev/loop19 $ sudo losetup -f /dev/loop19 |
時系列的に後から生成したこのイメージでの fsck が大したエラーもなく完走したことから、SDカードメディア破損ではなさそうで一安心。