東芝のTVについないだHDDが認識しなくなったと持ち込まれる(1)

どうやら、たまになる病気ということでよくあることらしい。
以下で復旧することもあるということで、こいつらは試したらしい。
・USBケーブルの抜き差しで直らない。
・HDDのほうの電源を入れなおしても直らない。
・電源ボタン長押しで、本体を初期化しても直らない。
その度に録画が飛ぶと、二度と買わなくなるよね。
なんでファームを直さないんだろう?
太古のNASでも、そのへん直すようにしてるというのに。
たしか、XFSだったよな。

復旧環境

AtomNAS筐体が転がってたので、それを使う。
OS入れるのもめんどくさいので、入ってたやつを使う。

# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)


とりあえずUSBのままで入れるとマウントしちゃうのかな?

# rpm -qa | grep autofs

ない感じ。
USBメモリを差し込んで見る。
dmesgではsdc割り当てが見えているけど、/proc/mountsには変化なし。
こいつは自動マウントはされないようだ。


xfs_repairコマンドがない。

# rpm -qa | grep xfs

なしかよ。
入れる。

# yum install xfsprogs
(snip)
Installed:
xfsprogs.x86_64 0:4.5.0-9.el7_3

復旧してみる

USBのまま接続。
dmesgを見る。

[1734711.940047] usb 1-3: new high-speed USB device number 5 using ehci-pci
[1734712.055106] usb 1-3: New USB device found, idVendor=04bb, idProduct=0136
[1734712.055117] usb 1-3: New USB device strings: Mfr=10, Product=11, SerialNumber=3
[1734712.055123] usb 1-3: Product: I-O DATA AVHD-U
[1734712.055129] usb 1-3: Manufacturer: I-O DATA DEVICE, INC.
[1734712.055135] usb 1-3: SerialNumber: 000045C0C1100334
[1734712.059139] usb-storage 1-3:1.0: USB Mass Storage device detected
[1734712.059454] scsi host7: usb-storage 1-3:1.0
[1734713.061796] scsi 7:0:0:0: Direct-Access I-O DATA AVHD-U 1379 PQ: 0 ANSI: 2 CCS
[1734713.062988] sd 7:0:0:0: Attached scsi generic sg2 type 0
[1734713.064338] sd 7:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[1734713.066121] sd 7:0:0:0: [sdc] Write Protect is off
[1734713.066140] sd 7:0:0:0: [sdc] Mode Sense: 3c 00 00 00
[1734713.068229] sd 7:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[1734713.131838] sdc: sdc1
[1734713.135842] sd 7:0:0:0: [sdc] Attached SCSI disk
[1734713.321876] sd 7:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[1734713.321889] sd 7:0:0:0: [sdc] Sense Key : Medium Error [current]
[1734713.321897] sd 7:0:0:0: [sdc] Add. Sense: Unrecovered read error
[1734713.321906] sd 7:0:0:0: [sdc] CDB: Read(10) 28 00 00 00 00 20 00 00 18 00
[1734713.321913] blk_update_request: critical medium error, dev sdc, sector 32
[1734713.381124] sd 7:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[1734713.381150] sd 7:0:0:0: [sdc] Sense Key : Medium Error [current]
[1734713.381166] sd 7:0:0:0: [sdc] Add. Sense: Unrecovered read error
[1734713.381183] sd 7:0:0:0: [sdc] CDB: Read(10) 28 00 00 00 00 28 00 00 08 00
[1734713.381195] blk_update_request: critical medium error, dev sdc, sector 40
[1734713.383424] Buffer I/O error on device sdc, logical block 5
[1734713.498374] sd 7:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[1734713.498387] sd 7:0:0:0: [sdc] Sense Key : Medium Error [current]
[1734713.498395] sd 7:0:0:0: [sdc] Add. Sense: Unrecovered read error
[1734713.498404] sd 7:0:0:0: [sdc] CDB: Read(10) 28 00 00 00 00 28 00 00 08 00
[1734713.498410] blk_update_request: critical medium error, dev sdc, sector 40
[1734713.523247] sd 7:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[1734713.523261] sd 7:0:0:0: [sdc] Sense Key : Medium Error [current]
[1734713.523269] sd 7:0:0:0: [sdc] Add. Sense: Unrecovered read error
[1734713.523278] sd 7:0:0:0: [sdc] CDB: Read(10) 28 00 00 00 00 29 00 00 01 00
[1734713.523284] blk_update_request: critical medium error, dev sdc, sector 41
[1734713.526494] Buffer I/O error on device sdc1, logical block 1
[1734713.551367] sd 7:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[1734713.551377] sd 7:0:0:0: [sdc] Sense Key : Medium Error [current]
[1734713.551384] sd 7:0:0:0: [sdc] Add. Sense: Unrecovered read error
[1734713.551392] sd 7:0:0:0: [sdc] CDB: Read(10) 28 00 00 00 00 2a 00 00 06 00
[1734713.551398] blk_update_request: critical medium error, dev sdc, sector 42
[1734713.554697] Buffer I/O error on device sdc1, logical block 2
[1734713.558076] Buffer I/O error on device sdc1, logical block 3
[1734713.561404] Buffer I/O error on device sdc1, logical block 4
[1734713.564706] Buffer I/O error on device sdc1, logical block 5
[1734713.567983] Buffer I/O error on device sdc1, logical block 6
[1734713.571239] Buffer I/O error on device sdc1, logical block 7

軽微ですが、先頭のほう死んでますやん。1TBもあるのに。
さすがに1TBをダンプして遊ぶ余裕はないな...

# xfs_repair -v /dev/sdc
Phase 1 - find and verify superblock...
superblock read failed, offset 0, size 524288, ag 0, rval -1

fatal error -- Input/output error

XFSってスーパーブロックのリペア用バックアップ持ってなかったっけ?

# mount -t xfs /dev/sdc1 /mnt/ -o ro,norecovery

# dmesg
[1735583.635579] SGI XFS with ACLs, security attributes, no debug enabled
[1735583.642610] XFS (sdc1): Mounting V4 filesystem in no-recovery mode. Filesystem will be inconsistent.
[1735584.033812] SELinux: initialized (dev sdc1, type xfs), uses xattr

# ls /mnt/
M000020160103230951e8e0b7a3c118.dtv
M000020160103230951e8e0b7a3c118.dtv.meta
M000020160103230951e8e0b7a3c118.dtv.rat
(snip)

見えますね。

# ls -la /mnt/.toshiba*
-rw-r--r--. 1 root root 95316 Jan 18 23:30 /mnt/.toshiba_dir_info_e8e0b7a3c118
-rw-r--r--. 1 root root 1632 Jan 18 22:59 /mnt/.toshiba_serieslist_e8e0b7a3c118
-rw-r--r--. 1 root root 0 Jan 1 2016 /mnt/.toshiba_size_info_e8e0b7a3c118

/mnt/.toshibazze8e0b7a3c118:
total 76
drwxr-xr-x. 6 root root 91 Aug 17 10:29 .
drwxr-xr-x. 3 root root 32768 Jan 18 23:30 ..
drwxr-xr-x. 2 root root 8192 Jan 18 10:50 aeef0000000
drwxr-xr-x. 2 root root 4096 Jan 18 23:30 aeef0000001
drwxr-xr-x. 2 root root 118 Jan 18 23:30 alkf
-rw-r--r--. 1 root root 12 Jan 1 2016 bid.bin
-rw-r--r--. 1 root root 80 Jan 1 2016 did.bin
drwxr-xr-x. 2 root root 78 Nov 2 22:59 log

本体固有データ類っぽいのも見える。
しかし、結構データ入っている。つらい。

# df -h /dev/sdc1
Filesystem Size Used Avail Use% Mounted on
/dev/sdc1 932G 747G 186G 81% /mnt

さて、東芝のドライブ認識はUUIDでやっていると聞いたことがある。
合わせれば問題ないかな?

# blkid /dev/sdc1
# blkid /dev/sdc
/dev/sdc: PTTYPE="gpt"
# ls -l /dev/disk/by-uuid | grep sdc

ないな。

# fdisk -l /dev/sdc1
fdisk: cannot open /dev/sdc1: Input/output error
# fdisk -l /dev/sdc
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes, 1953525168 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
Disk label type: gpt


# Start End Size Type Name
1 40 1953525134 931.5G Microsoft basic primary

ない。

# xfs_admin -u /dev/sdc1
xfs_admin: read failed: Input/output error
xfs_admin: /dev/sdc1 is invalid (cannot read first 512 bytes)

ない。当たり前だけど。


東芝隠しファイルに"e8e0b7a3c118"が含まれているということは、これがUUIDの断片なんだろう。
これは、TV側のROMの中に、どこまでUUIDを格納してあるかという勝負になるな。
先頭一致だけ見てくれればいいけど。
たぶん、こんな感じならいいんじゃなかろうか?
"e8e0b7a3-c118-xxxx-xxxx-xxxxxxxxxxx"

# grep e8e0b7a3 -R /mnt/.toshiba*
Binary file /mnt/.toshiba_dir_info_e8e0b7a3c118 matches

ファイルインデックスのようだ。

# hexdump -C /mnt/.toshiba_dir_info_e8e0b7a3c118
00000000 4d 30 30 30 30 32 30 31 36 30 31 30 33 32 33 30 |M000020160103230|
00000010 39 35 31 65 38 65 30 62 37 61 33 63 31 31 38 2e |951e8e0b7a3c118.|
00000020 64 74 76 00 00 00 00 00 00 00 00 00 00 00 00 00 |dtv.............|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
(snip)

ファイル名には一部が埋まっているから、出て当たり前か。


あれ?
これって、MACアドレスか。

Search results for "e8e0b7"
MACVendor
E8E0B7Toshiba

正解。
ということは、この一致しか見てない可能性もあるな。


ググると、なんかbinファイルの位置をTV側で持っていて、マッチするか見ているという話もあるな。

# find /mnt/ | grep .bin
/mnt/.toshibazze8e0b7a3c118/did.bin
/mnt/.toshibazze8e0b7a3c118/alkf/alk.bin
/mnt/.toshibazze8e0b7a3c118/alkf/ald.bin
/mnt/.toshibazze8e0b7a3c118/alkf/alc0000000.bin
/mnt/.toshibazze8e0b7a3c118/alkf/alc0000001.bin
/mnt/.toshibazze8e0b7a3c118/bid.bin
/mnt/.toshibazze8e0b7a3c118/aeef0000000/aee0000000d.bin
/mnt/.toshibazze8e0b7a3c118/aeef0000000/aee00000003.bin
(snip)


あとは、USB-HDDインターフェイスのVID/PIDか。
それともSerialNumberか。


とりあえず、ハードディスクの先頭部分が読めなくなったことで、普通では復旧できないことがわかった。
XFSのバックアップ機能で、マウントしてファイルをコピることはできそう。
あとは、何が揃えば、東芝側で認識してくれるかどうかってあたりか。


(2)に続く。
http://d.hatena.ne.jp/kinneko/20170127/p1