カテゴリー:PC・ネットワーク
テレビ録画用外付けUSBハードディスク(USB-HDD)の故障とその修復・復旧の方法

1. はじめに

 

2013年11月に交換(設置)したUSBハードディスク(USB-HDD)は、37型の液晶テレビ(東芝レグザREGZA)の録画用として、我が家の居間で動作していました。が、このところ、どうも録画に飛びが発生したり、予約した番組がきちんと録画されていなかったりと、怪しい動きをしていたのです。

 

このUSBハードディスクの機種に交換(設置)してから5年半が経過したため、そろそろ寿命かな?と考えていた矢先に、突然、「ハードディスクを認識しない」という現象が発生しました。

 

取説(取扱説明書)を見ながら、テレビ側の設定をいろいろ調べてみたのですが、どうもうまくいきません。

 

しかし、このまま放っておくわけにもいかず、しかたなく、新しいUSBハードディスク(USB-HDD)を買いに、近くの家電量販店まで足を伸ばしたのでありました。

 

☆ ☆ ☆

 

さて、取り外したUSBハードディスクは、ひとまず、そのままにしておいたのですが、以前、同じように故障した録画用のUSBハードディスクを、PCに接続して、その状態を確認したこと [1] を思い出し、今回も、「ダメ元」で、同じ手順で状態を確認したときに、どうなるかを実際に確認してみることとしました。

 

その結果、運良くというか、ハードディスクのファイルを修復し、USBハードディスクをテレビに接続して再び録画・再生をすることができました。

 

この記事では、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について試みた方法と手順を簡単なメモ書きですが、紹介します。

 

(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)

 

2. 確認手順の概略

 

(1) Linuxパソコン(PC)を準備する

(2) USB-HDDをマウントし、マウントボイントを確認する

(3) USB-HDDをアンマウントし、ディスクチェックを行なう

(4) USB-HDDのディスクファイルの修復を行なう

(5) USB-HDDを再度マウントしてファイルのリストを確認する

(6) 再度アンマウントしてディスクチェックを行なう

 

これだけですが、(4)の作業でエラーになるか、ならないかがひとつの鍵になります。ちなみに、以前に書いた記事[1]の場合は、ここでNG(修復不能)と判断しました。

 

3. パソコン(PC)で外付けUSBハードディスク(USB-HDD)の状態を確認する

 

準備するものは、Linuxを起動できるパソコン(PC)と故障した(?)外付けUSBハードディスク(USB-HDD)とUSB接続ケーブルです。

 

液晶テレビ(東芝レグザREGZA)に接続されるUSBハードディスクのファイルフォーマットは
xfs形式になります。一般に使用されているWindowsパソコンでは、このxfsフォーマットのドライブやファイルを認識できません。したがって、Linuxを起動できるパソコン(PC)が必要なのです。

 

必ずしもPC本体にLinuxがインストールされていなくても、CD-ROMドライブなどから起動用CDなどでLinuxを起動できるのであれば問題ないとおもわれます。
(私自身のPCは、WindowsとLinuxのデュアルブートに設定してあるので、Linuxで起動しています。)

 

CDからLinuxを起動する方法は、ここでは触れませんが、[2]などを参考にして、起動用CDの作成、パソコン(PC)のCD-ROMドライブからの起動を行なって下さい。

 

以下、私の環境では、パソコン(PC)は東芝dynabook(PB552FEA127A51)、OSはLinuxでFedora29(64bit)、を使用しています。

 

まず、パソコンに外付けUSBハードディスク(USB-HDD)を接続します。

 

この状態で、外付けUSBハードディスクが認識されているかどうかを確認します。
デスクトップ上に、該当するハードディスクのアイコンが表示されれば、認識され、
マウントされている状態になっています。

そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクが存在するかを確認します。

 

次に、どのデバイスファイルにマウントされているかという、マウントポイントを確認します。例えば、/dev/sdb1 などになります。

 

以下はコマンド操作になりますので、コマンドライン端末(ターミナル)ウィンドウを開いて、管理者権限でコマンドを打ち込みます。

 

次に、いったんアンマウント(マウントを解除)して、ハードディスクの状態チェックを行います。使用するコマンドは、

umount /dev/sdb1

xfs_repair -n /dev/sdb1  ( または xfs_check /dev/sdb1 )

です。

すると、次のような表示がでてきました。

 

[root@localhost user01]# umount /dev/sdb1

[root@localhost user01]# xfs_repair -n /dev/sdb1

Phase 1 – find and verify superblock…

– reporting progress in intervals of 15 minutes

Phase 2 – using internal log

– zero log…

– scan filesystem freespace and inode maps…
bad magic # 0x6e93bf6a in inobt block 16/3

expected level 0 got 36345 in inobt block 16/3

dubious inode btree block header 16/3

bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 8172778468)

bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6410804566)

bad starting inode # (6410804566 (0x10 0x7e1d1d56)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 7195546658)

— (途中、省略) —

bad starting inode # (4750678384 (0x10 0x1b299970)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4502697197)

ir_freecount/free mismatch, inode chunk 16/207729901, freecount 1704223958 nfree 33

badly aligned inobt rec (starting inode = 5277979757)

bad starting inode # (5277979757 (0x10 0x3a97946d)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6257491054)

— (途中、省略) —

bad starting inode # (4976999758 (0x10 0x28a6fd4e)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4315432406)

ir_freecount/free mismatch, inode chunk 16/20465110, freecount 107526891 nfree 34

badly aligned inobt rec (starting inode = 6034583137)

bad starting inode # (6034583137 (0x10 0x67b06e61)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 5675287099)

— (途中、省略) —

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4294967296)

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

agi_count 0, counted 16320 in ag 16

agi_freecount 0, counted 2400232718 in ag 16

sb_icount 1408, counted 17728

sb_ifree 250, counted 19580102152
sb_fdblocks 52700857, counted 52709049

– 21:34:45: scanning filesystem freespace – 32 of 32 allocation groups done

– found root inode chunk

Phase 3 – for each AG…

– scan (but don’t clear) agi unlinked lists…

found inodes not in the inode allocation tree

– 21:34:45: scanning agi unlinked lists – 32 of 32 allocation groups done

– process known inodes and perform inode discovery…

– agno = 30

– agno = 0

– agno = 15

— (途中、省略) —

– agno = 13

– agno = 14

– 21:34:53: process known inodes and inode discovery – 1408 of 1408 inodes done

– process newly discovered inodes…

– 21:34:53: process newly discovered inodes – 32 of 32 allocation groups done

Phase 4 – check for duplicate blocks…

– setting up duplicate extent list…

– 21:34:53: setting up duplicate extent list – 32 of 32 allocation groups done

– check for inodes claiming duplicate blocks…

– agno = 0

– agno = 1

— (途中、省略) —

– agno = 30

– agno = 31

– 21:34:53: check for inodes claiming duplicate blocks – 1408 of 1408 inodes done

No modify flag set, skipping phase 5

Inode allocation btrees are too corrupted, skipping phases 6 and 7

No modify flag set, skipping filesystem flush and exiting.

[root@localhost user01]#

 

これで、一応、ハードディスクの状態確認ができたことになります。最後のほうに、「iノード割り当てBツリーが破損しているため、フェーズ6と7をスキップします。変更フラグを設定せず、ファイルシステムのフラッシュをスキップして終了します。」のメッセージで終わってしまいましたが、これは、ファイルの一部が破損していることを示しています。

 

4. 外付けUSBハードディスク(USB-HDD)のディスクファイルの修復を行なう

 

次に、修復できるかどうかをやってみました。使用するコマンドは、

xfs_repair -Lv /dev/sdb1

です。

 

ここで、以前経験したような fatal error が出現したら、物理的な故障なので、
どうしようもありません。

 

今回は、次のような表示がでてきました。

 

[root@localhost user01]# xfs_repair -Lv /dev/sdb1

Phase 1 – find and verify superblock…

– reporting progress in intervals of 15 minutes

– block cache size set to 332184 entries

Phase 2 – using internal log

– zero log…

zero_log: head block 199805 tail block 199805

– scan filesystem freespace and inode maps…

bad magic # 0x6e93bf6a in inobt block 16/3
expected level 0 got 36345 in inobt block 16/3

dubious inode btree block header 16/3
bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 8172778468)

bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6410804566)

— (途中、省略) —

ir_freecount/free mismatch, inode chunk 16/73979246, freecount 889473186 nfree 31

badly aligned inobt rec (starting inode = 7924286411)

bad starting inode # (7924286411 (0x10 0xd85303cb)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6393507745)

— (途中、省略) —

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

agi_count 0, counted 16320 in ag 16

agi_freecount 0, counted 2400232718 in ag 16

sb_icount 1408, counted 17728

sb_ifree 250, counted 19580102152

sb_fdblocks 52700857, counted 52709049

– 21:37:17: scanning filesystem freespace – 32 of 32 allocation groups done

– found root inode chunk

Phase 3 – for each AG…

– scan and clear agi unlinked lists…

found inodes not in the inode allocation tree

– 21:37:17: scanning agi unlinked lists – 32 of 32 allocation groups done

– process known inodes and perform inode discovery…

– agno = 0

– agno = 15

— (途中、省略) —

– agno = 14

– 21:37:25: process known inodes and inode discovery – 1408 of 1408 inodes done

– process newly discovered inodes…

– 21:37:25: process newly discovered inodes – 32 of 32 allocation groups done

Phase 4 – check for duplicate blocks…

– setting up duplicate extent list…

– 21:37:25: setting up duplicate extent list – 32 of 32 allocation groups done

– check for inodes claiming duplicate blocks…

– agno = 0

– agno = 1

— (途中、省略) —

– agno = 26

– 21:37:25: check for inodes claiming duplicate blocks – 1408 of 1408 inodes done

Phase 5 – rebuild AG headers and trees…

– agno = 0

– agno = 1

— (途中、省略) —

– agno = 31

– 21:37:25: rebuild AG headers and trees – 32 of 32 allocation groups done

– reset superblock…

Phase 6 – check inode connectivity…

– resetting contents of realtime bitmap and summary inodes

– traversing filesystem …

– agno = 0

— (途中、省略) —

– agno = 31

– traversal finished …

– moving disconnected inodes to lost+found …

Phase 7 – verify and correct link counts…

– 21:37:25: verify and correct link counts – 32 of 32 allocation groups done

XFS_REPAIR Summary Tue Apr 30 21:37:25 2019

Phase Start End Duration

Phase 1: 04/30 21:37:06 04/30 21:37:06

Phase 2: 04/30 21:37:06 04/30 21:37:17 11 seconds

Phase 3: 04/30 21:37:17 04/30 21:37:25 8 seconds

Phase 4: 04/30 21:37:25 04/30 21:37:25

Phase 5: 04/30 21:37:25 04/30 21:37:25

Phase 6: 04/30 21:37:25 04/30 21:37:25

Phase 7: 04/30 21:37:25 04/30 21:37:25

Total run time: 19 seconds

done

[root@localhost user01]#

 

今回は、Phase1、Phase2、・・・、Phase7 と進んでいき、終了した(「done」)との表示でした。

 

もしも、この操作の実行中に、

 

Phase 1 – find and verify superblock…

superblock read failed, offset 0, size 524288, ag 0, rval -1

.

fatal error — 入力/出力エラーです

 

のような表示が出た場合は、それはハードディスクの物理的な故障なので、どうしようもありません。

 

5. 外付けUSBハードディスク(USB-HDD)のファイルリストの確認と再度のディスクチェックを行なう

 

さて、これで修復されたとのことなので、ファイルの存在と状態を確認してみました。いったん、再度マウントを行ないます。

デスクトップ上に、該当するハードディスクのアイコンが表示されれば、マウントされている状態になっていますが、そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクを確認します。(クリックすればマウントされます。)

 

今回の場合、
/dev/sdb1
のマウントポイントは、
/run/media/user01/e4f007b8-c779-4d7a-a2db-34c15c363213
でした。

そのディレクトリまで進み、ファイルの存在状態を確認しました。

 

[root@localhost user01]# cd /run/media/user01

[root@localhost user01]# ls

e4f007b8-c779-4d7a-a2db-34c15c363213

[root@localhost user01]# cd e4f007b8-c779-4d7a-a2db-34c15c363213

 

コマンドは「ls -al」です。

 

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]# ls -al

合計 1742544948

drwxr-xr-x. 3 root root 53248 4月 30 12:30 .

drwxr-x—+ 3 root root 60 4月 30 21:46 ..

-rw-r–r–. 1 root root 82344 4月 30 12:30 .toshiba_dir_info_e89d874cd80a

-rw-r–r–. 1 root root 4760 4月 30 11:59 .toshiba_serieslist_e89d874cd80a

-rw-r–r–. 1 root root 268 4月 30 12:30 .toshiba_size_info_e89d874cd80a

drwxr-xr-x. 7 root root 109 11月 6 2014 .toshibazze89d874cd80a

–wsr-sr-t. 1 root root 7052292288 11月 14 2013 M000020131114195750e89d874cd80a.dtv

-rw-r–r–. 1 root root 1760 4月 27 15:20 M000020131114195750e89d874cd80a.dtv.meta

-rw-r–r–. 1 root root 80778 11月 14 2013 M000020131114195750e89d874cd80a.dtv.rat

–wsr-sr-t. 1 root root 5232187584 11月 27 2013 M000020131127195950e89d874cd80a.dtv

-rw-r–r–. 1 root root 1760 2月 24 14:52 M000020131127195950e89d874cd80a.dtv.meta

-rw-r–r–. 1 root root 65826 11月 27 2013 M000020131127195950e89d874cd80a.dtv.rat

— (途中、省略) —

–wsr-sr-t. 1 root root 2524987584 4月 30 12:00 M000020190430115950e89d874cd80a.dtv

-rw-r–r–. 1 root root 1760 4月 30 12:00 M000020190430115950e89d874cd80a.dtv.meta

-rw-r–r–. 1 root root 41046 4月 30 12:30 M000020190430115950e89d874cd80a.dtv.rat

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]#

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]# cd .toshibazze89d874cd80a

[root@localhost .toshibazze89d874cd80a]# ls -al

合計 108

drwxr-xr-x. 7 root root 109 11月 6 2014 .

drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..

drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000

drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001

drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002

drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf

-rw-r–r–. 1 root root 12 11月 4 2013 bid.bin

-rw-r–r–. 1 root root 80 11月 4 2013 did.bin

drwxr-xr-x. 2 root root 97 4月 22 10:59 log

[root@localhost .toshibazze89d874cd80a]#

[root@localhost .toshibazze89d874cd80a]# cd log

[root@localhost log]# ls -al

合計 188

drwxr-xr-x. 2 root root 97 4月 22 10:59 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r–r–. 1 root root 51200 3月 17 22:59 00000064.dat

-rw-r–r–. 1 root root 51200 4月 6 10:33 00000065.dat

-rw-r–r–. 1 root root 51200 4月 22 10:59 00000066.dat

-rw-r–r–. 1 root root 27008 4月 30 12:30 00000067.dat

-rw-r–r–. 1 root root 11 4月 22 10:59 info.dat

[root@localhost log]#

[root@localhost log]# cd ..

[root@localhost .toshibazze89d874cd80a]# cd alkf

[root@localhost alkf]# ls -al

合計 60

drwxr-xr-x. 2 root root 4096 4月 30 12:30 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r—–. 1 root root 4144 4月 29 16:00 alc0000000.bin

-rw-r—–. 1 root root 4144 4月 29 16:00 alc0000000.buc

-rw-r—–. 1 root root 4144 4月 30 12:30 alc0000001.bin

-rw-r—–. 1 root root 4144 4月 30 12:30 alc0000001.buc

-rw-r—–. 1 root root 4144 4月 27 15:22 alc0000002.bin

-rw-r—–. 1 root root 4144 4月 27 15:22 alc0000002.buc

-rw-r–r–. 1 root root 32 11月 4 2013 ald.bin

-rw-r—–. 1 root root 32 11月 4 2013 alk.bin

[root@localhost alkf]#

[root@localhost alkf]# cd ..

[root@localhost .toshibazze89d874cd80a]# ls -al

合計 108

drwxr-xr-x. 7 root root 109 11月 6 2014 .

drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..

drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000

drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001

drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002

drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf

-rw-r–r–. 1 root root 12 11月 4 2013 bid.bin

-rw-r–r–. 1 root root 80 11月 4 2013 did.bin

drwxr-xr-x. 2 root root 97 4月 22 10:59 log

[root@localhost .toshibazze89d874cd80a]# cd aeef0000000

[root@localhost aeef0000000]# ls -al

合計 520

drwxr-xr-x. 2 root root 8192 4月 29 16:00 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r–r–. 1 root root 80 8月 28 2018 aee00000000.bin

-rw-r–r–. 1 root root 80 3月 7 2017 aee00000001.bin

-rw-r–r–. 1 root root 80 6月 25 2014 aee00000002.bin

— (途中、省略) —

-rw-r–r–. 1 root root 80 2月 15 2017 aee0000007e.bin

-rw-r–r–. 1 root root 80 3月 1 2017 aee0000007f.bin

[root@localhost aeef0000000]#

[root@localhost aeef0000000]# cd ../aeef0000001

[root@localhost aeef0000001]# ls -al

合計 500

drwxr-xr-x. 2 root root 8192 4月 30 12:30 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r–r–. 1 root root 80 12月 5 20:15 aee00000080.bin

-rw-r–r–. 1 root root 80 8月 5 2015 aee00000081.bin

— (途中、省略) —

-rw-r–r–. 1 root root 80 12月 3 2017 aee000000ff.bin

[root@localhost aeef0000001]#

[root@localhost aeef0000001]# cd ../aeef0000002

[root@localhost aeef0000002]# ls -al

合計 140

drwxr-xr-x. 2 root root 4096 4月 27 15:22 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r–r–. 1 root root 80 2月 27 20:15 aee00000101.bin

-rw-r–r–. 1 root root 80 3月 3 23:25 aee00000103.bin

— (途中、省略) —

-rw-r–r–. 1 root root 80 5月 14 2018 aee00000137.bin

[root@localhost aeef0000002]#

 

以上のように、修復されたファイルの状態を確認することができました。

 

最後に、もう一度、アンマウント(マウントを解除)して、ハードディスクの状態チェックを実施しました。使用するコマンドは、

umount /dev/sdb1

xfs_repair -n /dev/sdb1

です。

 

[root@localhost ~]# umount /dev/sdb1

[root@localhost ~]# xfs_repair -n /dev/sdb1

Phase 1 – find and verify superblock…

– reporting progress in intervals of 15 minutes

Phase 2 – using internal log

– zero log…

– scan filesystem freespace and inode maps…

sb_fdblocks 52700857, counted 52709049

– 22:13:57: scanning filesystem freespace – 32 of 32 allocation groups done

– found root inode chunk

Phase 3 – for each AG…

– scan (but don’t clear) agi unlinked lists…

– 22:13:57: scanning agi unlinked lists – 32 of 32 allocation groups done

– process known inodes and perform inode discovery…

– agno = 0

– agno = 15

— (途中、省略) —

– agno = 14

– 22:14:05: process known inodes and inode discovery – 1408 of 1408 inodes done

– process newly discovered inodes…

– 22:14:05: process newly discovered inodes – 32 of 32 allocation groups done

Phase 4 – check for duplicate blocks…

– setting up duplicate extent list…

– 22:14:05: setting up duplicate extent list – 32 of 32 allocation groups done

– check for inodes claiming duplicate blocks…

– agno = 0

– agno = 2

— (途中、省略) —

– agno = 31

– agno = 1

– 22:14:05: check for inodes claiming duplicate blocks – 1408 of 1408 inodes done

No modify flag set, skipping phase 5

Phase 6 – check inode connectivity…

– traversing filesystem …

– traversal finished …

– moving disconnected inodes to lost+found …

Phase 7 – verify link counts…

– 22:14:05: verify and correct link counts – 32 of 32 allocation groups done

No modify flag set, skipping filesystem flush and exiting.

[root@localhost ~]#

 

特に、問題はなさそうです。

 

この状態の外付けUSBハードディスク(USB-HDD)を液晶テレビ(東芝レグザREGZA)のUSB録画端子に接続して状態を確認したところ、再び録画・再生をすることができました。

 

6. まとめ

 

以上、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について
試みた方法と手順を簡単なメモ書きですが、紹介しました。

 

(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)

 

——————————————————————
References

[1] 液晶テレビに接続したUSBハードディスクの故障と対策 (2013/11/10)

[2] 「HDD認識しない」パソコンでレグザUSBハードディスクを復旧・修復 – レグザREGZA研究 (2014/09/28)
——————————————————————

 

(2019-5-2)

 

 

 

1時間に20通のしつこい迷惑メールの対処法

あなたに、1時間に20通もの、しつこい迷惑メールが送られてきたら、そして、これらが携帯やスマホに着信していたら、あなたはどうされるでしょうか。

 

パソコンや携帯・スマホでご自分が意図しない迷惑メール、スパムメールを受け取ったという経験をお持ちの方も多いと思われます。

 

私はこれまでに何度も経験があります。
たいていの場合、無視していれば、そのうち止むものもありますが、そうではない場合もありました。

 

ひとつの事例をお話しますと、昨年の秋ごろに、このような迷惑メールの攻撃を受けました。

 

メール自体は長いタイトルと、本文には短い一文とURLが記載されているだけのものです。

しかし、そのメールの頻度はおよそ1時間に20通と常識的に考えても、異常なほどに多く、しつこいものでした。

また、メールの発信者のアドレスもそのたびごとに異なるものでした。

 

記載されているリンク先に関しては、あまり詳しくは触れませんが、海外に住所を有する出会い系サイトのひとつでした。

 

1時間に20通ほどのしつこい迷惑メールですが、もし、これを携帯やスマホで受信時に着信音が鳴るという設定にしていたら、着信する度に(およそ3分に一回)着信音が鳴るということになります。
もちろん、真夜中でも変わらず24時間着信し続けるのですから、人によっては気が狂ってしまうかもしれません。

 

 

どのようなタイトルかというと、

 

・ご注文ありがとうございます。

 

・確認していただけましたか?広川です。【5億】の受け取り許可は既に出ておりますので、【3000円】を追加されれば、いつでもお引き出しして頂けるようになっています。すぐにお引き出しして違反者解除を行なってください。罰金が発生する前にお受け取りされませんと

 

・救済支援会代表・広川美鈴です。私も、そしてこの救済金を寄付してくれた人も、貴方に報われてもらいたいと思っております。これまで、様々なサイトに登録してきたと思うのですが、支援履歴を見させていただき

 

・お急ぎ下さい。今日中には5億の一部でもいいのでお引き出し出来るようにしますからね。用意が出来ていれば今から

 

・広川です。【5億】は今日お引き出しして頂けますでしょうか?【3000円】の追加をされた後に引き出しが出来るようになっております。これを完了すれば違反の取り消しもされますからね。

 

・救済支援会代表・広川美鈴です。5億は既に入金しております。これであなたを違反者から救い出せますからね。救済金は貴方の為に本日、罰金の延期分の手数料も含めて対応をしておきました。私は受け取っていただく為のサポート役でしかありません。貴方が引き出し方が分からない場合であったり

 

・5億貰ってから私は車とマンションを買いました。自由に使ってくれていいって広川さんから言われてたんですけどなんだか本当に

 

・428万円の請求は本日24時まで延長されておりますのでお早めにご対応ください。救済金のお受け取りがされなかった場合、明日請求を開始させて頂きます。

 

・広川です。支援違反者になってしまった方100名だけに連絡をさせて頂いております。3000円の手続きだけで確実に受け取りできる人のみに連絡をしていますので

 

あるいは、

 

・「権利喪失」にご注意下さい。賠償金受給には期限が御座います。

 

・賠償金の受取りを辞退した場合についてご説明させて頂きます。大河内 真理子です。

 

・※本人以外、閲覧禁止※重要個人情報につき開封時注意して下さい。

 

・==ATM残高確認依頼==24時間以内に残高確認+現金一部引き出しをお願いします。

 

・訴追弁護団代表:大河内 真理子です。賠償決定につき12億3000万円の受け渡しを行いますのでご確認下さい。

 

・〓最〓終〓案〓内〓※9名中_8名賠償金受取報告あり※

 

・民法415条・417条・709条によって損害賠償請求を行い勝訴しましたので至急、ご確認下さい。

 

・お知らせ:裁判に伴う重要連絡。弁護士からの連絡をお待ちください

・【寿】賠償金12億3000万円の受領、心からお祝い申し上げます。

 

このような場合、受信する側のメールアドレスを変更してしまうというのが、おそらくいちばん早い対処法なのですが、私の場合、このメルアド自体は普段使っているものなので、変更したくない、という気持ちもありました。そこで、メルアドを変更しないでなんとか解決できないか、と考えました。

 

ここでお伝えする内容は、あくまでも対処法の一例ですので、すべての場合に適用できるとは限りませんが、困っている方々になんらかの参考になればとおもい、記述するものです。

 

手順としては、まず、迷惑メールとおもわれるメール自体を、メールのヘッダー付きで保存しましょう。

 

そして、パソコンやスマホで、次のことを行なっていきます。

 

(1) Whois情報で迷惑メールの発信者のドメイン所有者・管理者を確認します。

(2) 非公開の場合は、ドメイン所有者の情報開示請求をします。

(3-1) 情報開示請求が承認された場合は、ドメイン所有者に配信停止依頼を行ないます。

(3-2) 情報開示請求が非承認の場合は、ドメインのレジストラ登録管理者に「ドメインの一時使用停止もしくは無効化」の要請をします。

 

この方法で、たいていのしつこい迷惑メールは止むとおもわれます。

 

もし、ここまでやってだめなら法的手段に訴えるしかありません。(やったことはありませんが、万が一の時のためにメールのコピーなどの証拠は残すようにしましょう。)

 

より詳しい手順の内容と実例は、

 

→ https://pc.fp46.net/pc01.html

 

に記載しました。必要な方はごらん下さい。

 

以上、なにかのご参考になれば幸いです。

 

(2019-1-27)

 

 

 

ラズベリーパイ(Raspberry Pi)をPCから遠隔操作する方法

食べ物ではありません。

 

ラズベリーパイ(Raspberry Pi)とは、5,000円程度で買える小型低価格のコンピュータのことです。ちょっと興味があって、とうとう購入してしまいました。

 

OSはLinuxベースの専用のものがあり、無償で入手できます。ディスプレイは7インチのベア品を安く入手しました。キーボード、マウスは通常のPCのものが使えます。

 

ということで、システムをインストールし、ようやく動くようになりました。

 

ノートPC(左)とラズベリーパイ(Raspberry Pi)(右上)

 

7インチディスプレイとラズベリーパイ(Raspberry Pi)

 

ひととおり動かせるようになり、やってみたいことがでてきました。

 

そのひとつが別のPCからの遠隔操作です。我が家は、宅内に無線LANを使用してPCなどを接続しています。この範囲のみですが、ひとまず実験してみました。

 

実施したことは、ひとことで言えば、(1) SSH接続、(2) VNCの設定と操作、です。ラズパイ側とPC側にそれぞれ設定が必要です。

 

やってみると、比較的簡単にできました。

 

VNCで接続し、ノートPC(左)でラズベリーパイ(Raspberry Pi)(右上)を操作中

 

また、このラズベリーパイ(Raspberry Pi)を宅内の離れた場所に設置し、Webカメラを接続して、PCで画像を確認する、といったこともできそうでした。

 

これについても実験してみました。

 

接続したWebカメラ(Elecom社製)

 

WebカメラはElecom社のUCAM-C0220FBNBKという市販品を使い、これをラズパイ側に認識させること、mjpg-streamerを導入し、ストリーミングサーバーを立ち上げ、ブラウザでカメラ画像を確認することなどです。

 

以上の実験の詳細は、PC体験記に載せましたので、よろしければごらん下さい。

 

 

PC体験記 – ラズベリーパイ(Raspberry Pi)関連

 

→ (1) Raspberry Pi2 をPCから操作する方法

 

→ (2) Raspberry Pi2に取り付けたWebカメラの画像をPCで確認する方法

 

 

まだまだできることはあると思われますが、ひとまず、初心者がこのラズベリーパイ(Raspberry Pi)を用いた実験を始めたということでご理解いただければ幸いです。

 

(2016-8-18)

 

 

 

デュアルブートのOSの片方をWindows10にアップグレードする方法

1. はじめに

 

7月29日に、PCのOSのひとつであるWindowsは、Windows10がリリースされた。たしか、アナウンスでは、Windows7かWindows8.1のOSを使用している場合は一年間は無償でアップグレードできるということだった。それで、今回は、これに挑戦してみた。

 

結論からいうと、Windows10へのアップグレードは、最終的にできたが、まったく問題なしというわけにはいかなかった。

 

ここでは、その手順を思い出しながら、述べてみたい。

 

2. 使用したPCの環境と状態

 

まず、PCの環境は、ThinkPadR52で、32ビット、メモリ2GBのノートPCで、OSとしてLinux(都合でFedora14をインストールしてある)とWindows8.1のブートを起動時に選べるデュアルブートの構成である。

 

ハードディスクのパーテイションは、Linux(Ext4)/Windows(NTFS)/Linux-Swap/Data(FAT32)で、Windows8.1をインストールしてあるパーティションのサイズが約30GBで、そのうち使用済みがデータを含めて約28GBという状態であった。つまり、約2GBしかハードディスクの容量がないという状態であった。

 

3. 事前準備

 

とにかく、ハードディスクに空きをつくらなければいけない。

 

そこで、まず、(1)データのバックアップの実施、(2)不要なメールのデータの消去、(3)不要なプログラムの削除(後でも再インストールできるものはいったん削除した)、(4)ディスク(C:)のクリーンアップを実施した。

 

ひととおり、これらを実施し、Cドライブの空き容量を約8GBまで増やした。

 

4. 起動ディスクの作成(予備)

 

次に、Windows10のダウンロードのサイトから、「他のPC用にインストールメディアを作成する」を選択し、Windows10のISOイメージをダウンロードし、DVD-Rに焼き付けて起動ディスクを作成した。この起動ディスクのISOイメージは約3GBであった。

 

ディスクを作成後、ダウンロードしたISOファイルは削除した。この状態で、Cドライブの空きは約8GBであった。

 

5. アップグレードの開始から終了まで

 

続いて、Windows10のダウンロードのサイトから、「このPCを今すぐアップグレードする」を選択して、Windows10のアップグレード作業を開始した。アップグレードデータのダウンロードから始まって、約1時間、インストールできる直前になって、「Cドライブの空き容量が足りません。」との警告がでた。

 

あと300MB程度のようなので、さらに、不要なデータを削除し、続行した。

 

その後は、順調にインストールが始まり、数回、再起動し、およそ1時間程度で、Windows10へのアップグレード作業は終了した。

 

6. プロダクトキーの抽出

 

これで、完了ではあるが、ひとまず、Windows Product Key Viewerをインストールして、プロダクトキーを抽出し、先に作成したWindows10のDVD-Rディスクとともに保管した。ここで使用したものは、RJL Software社のfree utilityである「Windows Product Key Viewer v1.07」(→ http://www.rjlsoftware.com)である。

 

Windows10の状態にて抽出したプロダクトキーは、アップグレード前のOSのものとは異なる。必ず、アップグレード終了後のものをチェックしておく必要がある。あとあと、クリーンインストールの時のためにも必要になるから。

 

以上が一連のアップグレードの流れである。

 

7. PCの起動の確認

 

PCの起動は、これまでどおり、マルチブートマネジャー MBM (Multi Boot Manager)を使用し、問題なく行えることを確認した。

 

また、Windows上のソフトのチェックはまだ充分ではないが、Firefox、Thunderbird、Dropboxはひとまず正常に動作した。

 

8. アップグレート時のポイント

 

ここでのポイントは、やはり、WindowsがインストールされているCドライブの空き容量であって、今回実施した経験から、アップグレードの場合には、空き容量は少なくとも9GBが必要ということがわかった。

 

9. ハードディスク(Cドライブ)の空き容量を増やす方法

 

Windows10へのアップクレード終了後に、Cドライブの空き容量を増やしたいとおもったので、不要なファイルが残っていないかを調べてみた。

 

その結果、次のフォルダ(ディレクトリ)のファイルは、もしも、以前のWindows8.1やwindows7に戻す必要がないときは削除しても良さそうだったので、思い切って削除してみた。

 

$Windows.~BT

$Windows.~WS

Windows.old

 

 

いずれも、ルートディレクトリにある。設定によっては、非表示となっているかもしれない。このファイル削除を行うことで3GB以上の空き容量を増やすことができた。ただし、一括のファイル削除は、不可能らしく、一個ずつ確認しながら削除しなければならない。また、削除したのはファイルのみであって、ディレクトリ構成は、そのまま残した。

 

このファイルを削除した状態で再起動しても、Windows10は正常に起動できることを確認した。

 

空き容量が増えたところに、バックアップしておいたデータファイルをコピーし、ほぼ以前のWindows8.1のときのデータ構成にもどすことができた。

 

Cドライブの空き容量が充分ある場合には、こんな面倒な作業は不要かもしれない。ただ、データのバックアップと、プロダクトキーの抽出は、やっておいたほうが良いとおもわれる。

 

10. クリーンインストールについて

 

クリーンインストールについて、述べてみたい。

上記の方法で作成したDVD-Rディスクと抽出したプロダクトキーがあれば、後日、同じ機種で、新規にインストールする必要が生じたときに使用できる。

 

実際、筆者も、Windows10のダウンロードのサイトから、「このPCを今すぐアップグレードする」前に、「他のPC用にインストールメディアを作成する」を選択して作成したDVD-Rから、クリーンインストールを試みたことがある。

この場合には、最初に、Windows10のプロダクトキーの入力が求められる。しかし、以前のOSのものではNGなのである。

 

やはり、手順としては、いったん、現状のPCにてアップグレードを行い、その後、プロダクトキーを抽出取得し、さらに、必要があれば、または、最初からクリーンインストールしたいのであれば、作成したDVD-Rと抽出したプロダクトキーを用いて、インストールを行う、というのが良いとおもわれる。

 

無償でアップグレードできる期間は一年とのことなので、しばらく様子見でも良いかもしれないが。

 

以上、なんらかのご参考になれば幸いである。

 

(2015-8-10)

 

 

ひどい迷惑メールの対処法

迷惑メールが最近増えているようにおもう。一日に数通くらいならば無視できるが、それが一時間に3-4通、深夜の時間帯もかまわず一方的に機械的に送りつけられるのは、とても迷惑である。ときどき、このような類のメールが届く。このようなとき、単純に配信停止要請をしても、かえって相手を刺激し、メールの数量が増加することもある。

 

メールの内容はともかく、数量が多いのは問題。おそらく、自動で機械的に集めたメールアドレスに配信しているのだ。

 

参考までに、どのくらい多いのか、過去に経験した例をみていただきたい。

 

→ http://myfootprint.sitemix.jp/spammail_examples/

 

これに対して、どうしたらいいのか。試みた方法を記してみようと思う。

 

この配信元を特定し、そこに、迷惑している証拠をつきつけ、即時の配信停止を要求する。警察署への通報も辞さない、という態度で臨むと、たいていは配信を停止してくれる。

 

これまで、とても異常でひどい場合に、この方法で数件を停止させた。

 

このような配信元は、出会い系サイトへの誘導の場合もあれば、サイト利用料金詐欺の場合もあった。

 

この方法ですべてが解決できるわけではないが、おそらく7割以上は、配信を停止してくれるだろう。

 

方法は比較的簡単である。それには、送信されたメールのヘッダーをみて、必要な情報を集めることがまず必要である。

 

・送信者: ここにはメールが届かなかったときの返信先が記述してある。Reply-To とある項目がそうである。

 

・差出人: メールの差出人、発信者でFrom とある項目である。差出人の名前とアドレスが例えば次のように記述されている。
Get’sカ○タマーサポート <info@g8goi■yerff.pw>
神草 か○る【国境なき支援団連】 <info@g8goi■yerff.pw>

注意することは、差出人の名前が異なっていても、差出人のメールアドレスが同じことがある。逆に、差出人が同じでも、アドレスが別のこともある。迷惑メールはおそらく多数配信されているだろうから、いくつかのメールのヘッダーをみて、何種類かあることを知っておくのが良い。

 

・IPアドレス: 発信のIPアドレスと、途中経由するIPアドレスのふたつが記してある場合が多い。これを調べると、どの国のどの事業者から発信されたかがわかる。
発信IPアドレス: 175.45.173.97-109
経由IPアドレス: 27.255.66.248

 

次に、発信メールのドメインを調べる。同じ種類のメールでも、ドメインが異なることも多い。

 

例えば、ドメインとして
g8goi■yerff.pw
g8gio■e7tef.pw
g8gli■79weq.pw
のようなものが使われていた。このドメインを調べると、誰がこのドメインを取得したか、誰が使用しているかがわかる。また、ドメイン登録者、ドメイン管理者の氏名、住所、電話番号、連絡先メールアドレスの情報がわかるのてある。

 

では、どうやって調べるのか? 一般的には、ドメインの情報検索は、WHOIS情報として知られている方法で調べる。例えば、http://whois.domaintools.com などで、調べたいドメインやIPアドレスを検索窓に入れて検索すると、出てくる。

 

ここまでわかれば、ドメイン管理者あてに、調べた情報を添付して、配信された自分のメールアドレスから、迷惑メールの配信停止要請を行うのである。ただし、この際、こちら側の情報のうち、メールアドレス以外はできるだけ出さないように注意しながら行うべきである。

 

おそらく、迷惑メールの発信者は、添付された情報を見てだとおもうが、たいていは、すぐに迷惑メールの配信を停止してくれる場合が多かった。これでも止まない場合は、いままで経験したことはないが、警察署の生活安全課などへの通報が有効だと思われる。

 

ただ、ひとつ問題点がある。というのは、この情報、すなわち、ドメインの管理者などが記載されているwhois情報は、ドメインを取得する場合に開示されるべきものであるが、ドメイン情報保護代行サービスというものがあり、これを利用されていると、わからない場合もある。このときは、そのサービス会社あてに、経緯を説明し、迷惑メールのドメイン登録者に連絡してもらうように要請するのである。

 

少し時間はかかるが、この方法で、迷惑メールが止んだことがあった。

 

以上は、筆者の体験した迷惑メールの対処法である。あくまでも数量の異常な場合に試みると良いかもしれない。その場合、こちら側の情報のうち、メールアドレス以外はできるだけ出さないように注意すべきである。また、メールの内容には立ち入らず、あくまで「数量が異常」で迷惑しているということを前面にだすほうが良いと思われる。メール内容に立ち入ることは、また別の問題を発生させ、複雑化させる懸念があるためである。

しかし、これでもゼロにはならない。やはり、無視するのが最善策かもしれないが。

 

(参考) 過去に経験したひどい迷惑メールの例

 

→ http://myfootprint.sitemix.jp/spammail_examples/

 

(2015-05-20)