web-dev-qa-db-ja.com

ジオメトリが正しくありません：ブロック数967424がデバイスのサイズ（415232ブロック）を超えています

次のmountコマンドで何が悪かったのかを理解しようとしています。

ここから次のファイルを取得します。

ここ からimgファイルをダウンロードするだけです。

次に、アップストリームページごとにmd5sumが正しいことを確認しました。

$ md5sum nand_2016_06_02.img
3ad5e53c7ee89322ff8132f800dc5ad3  nand_2016_06_02.img

fileのコメントは次のとおりです。

$ file nand_2016_06_02.img 
nand_2016_06_02.img: x86 boot sector; partition 1: ID=0x83, starthead 68, startsector 4096, 3321856 sectors, extended partition table (last)\011, code offset 0x0

それでは、このイメージの最初のパーティションの開始を確認しましょう。

$ /sbin/fdisk -l nand_2016_06_02.img

Disk nand_2016_06_02.img: 1.6 GiB, 1702887424 bytes, 3325952 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: 0x0212268d

Device               Boot Start     End Sectors  Size Id Type
nand_2016_06_02.img1       4096 3325951 3321856  1.6G 83 Linux

私の場合、Unitssizeは512、およびStartは4096であり、これはオフセットがバイト2097152にあることを意味します。その場合、以下は正常に機能するはずですが、機能しません。

$ mkdir /tmp/img
$ Sudo mount -o loop,offset=2097152 nand_2016_06_02.img /tmp/img/
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

そして、dmesgは次のことを明らかにします。

$ dmesg | tail
[ 1632.732163] loop: module loaded
[ 1854.815436] EXT4-fs (loop0): mounting ext2 file system using the ext4 subsystem
[ 1854.815452] EXT4-fs (loop0): bad geometry: block count 967424 exceeds size of device (415232 blocks)

リストされている解決策のどれも ここ 私のために働いた：

  • resize2fsまたは、
  • sfdisk

私は何を逃しましたか？

私が試した他のいくつかの実験：

$ dd bs=2097152 skip=1 if=nand_2016_06_02.img of=trunc.img

これは次のことにつながります：

$ file trunc.img 
trunc.img: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=960b67cf-ee8f-4f0d-b6b0-2ffac7b91c1a (large files)

同じことが同じ話になります：

$ Sudo mount -o loop trunc.img /tmp/img/
mount: wrong fs type, bad option, bad superblock on /dev/loop2,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

最初にresize2fsを実行する必要があるため、e2fsckを使用できません。

$ /sbin/e2fsck -f trunc.img 
e2fsck 1.42.9 (28-Dec-2013)
The filesystem size (according to the superblock) is 967424 blocks
The physical size of the device is 415232 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes
mountext4disk-imageresize2fssfdisk
2
malat

関心のあるファイルシステムを（ddを使用して）抽出したら、ファイルサイズを調整するだけです（967424 * 4096 = 3962568704）。

$ truncate -s 3962568704 trunc.img

そして、単に：

$ Sudo mount -o loop trunc.img /tmp/img/
$ Sudo find /tmp/img/
/tmp/img/
/tmp/img/u-boot-spl.bin
/tmp/img/u-boot.img
/tmp/img/root.ubifs.9
/tmp/img/root.ubifs.4
/tmp/img/root.ubifs.5
/tmp/img/root.ubifs.7
/tmp/img/root.ubifs.2
/tmp/img/root.ubifs.6
/tmp/img/lost+found
/tmp/img/root.ubifs.3
/tmp/img/boot.ubifs
/tmp/img/root.ubifs.0
/tmp/img/root.ubifs.1
/tmp/img/root.ubifs.8

もう1つの簡単な解決策は、元のimgファイルを直接切り捨てることです。

$ truncate -s 3964665856 nand_2016_06_02.img
$ Sudo mount -o loop,offset=2097152 nand_2016_06_02.img /tmp/img/

ここで3962568704+ 2097152 = 3964665856

0
malat

この回答 のtruncateは問題を解決しなかったので、もう少し実験しました。 どこか でresize2fsを使用して画像を修正する提案を見つけました（resize2fs <image> <size>、たとえば上記のデータを前提としてresize2fs nand_2016_06_02.img 3779M）、それはうまくいきませんでした私にとっても（サイズを主張することはすでにこうだった）。

私にとって、次の2つのステップで解決しました。

  1. e2fsck -y -f nand_2016_06_02.img（エラーがあるかどうかはyなしで最初に確認できます-エラーがない場合は必要ありません）
  2. testdisk nand_2016_06_02.img、メニューをウォークスルーし（続行›（パーティションテーブル）なし›詳細›イメージの作成）、testdiskにイメージを作成させます。

Testdiskによって作成されたイメージ（名前はimage.dd）は、完全にマウントされます。

Sudo mount image.dd /tmp/img -t ext4 -o loop,ro

（私はそれがext4であることを知っていたので、誤って変更しないように読み取り専用でマウントすることを明示的に望んでいました。私の場合、それはダウンロードされたイメージではなく、私をあきらめた「回収された」SDカードであり、データはmyrescue -r 1000 -b 4096 /dev/sdf2 sdpart2.img、1014個の不良ブロックがある8 GBのパーティションで約24時間かかりました）

0
Izzy