タグ：ハードディスクの記事一覧

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. はじめに

 

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)

 

 

 

1. はじめに

 

これまで使用していたネットブックのCartina UM が、どうも使いずらくなった。発端は、ディスプレイの開閉でふたつある蝶番のうち、ひとつが破損したことにあった。止めてあるネジが緩み、プラスチックの一部が破損したのである。

 

いちどは裏蓋のネジを外して、内部の様子を見てみたが、とても直せそうにない。しかたなく、ネジを締め直して、もとにもどしたものの、今度は無線LANの受信感度がどうも良くない。基板に損傷が起きたのではないかとおもわれたのである。また、冷却ファンのモーターが異音を発するようになった。

 

いま入れてあるOSは、Fedora11で、PC自体はおよそ三年前に購入したものであるが、まだまだ使えるとおもいながら、使うたびに、無線LANの感度に悩まされるようになった。

 

そこで、この際、新機種に乗り換えることにした。いろいろと探してみたところ、秋葉原の家電量販店で、たまたま、MSI社のU160DXという機種のネットブックがアウトレットで23,800円で売られているのを見つけた。そして、直ぐに購入したのであった。

 

ここでは、Cartina UM からMSI U160DXにネットブックPCの乗り換え(データ移行)を行い、デュアルブートの環境を構築したので、それについて書いてみようとおもう。

 

2. MSI社のネットブックU160DX

 

U160DXは、Intel Atom N455というCPUでハードディスク容量が320GBのものだった。メモリは、1GBだったが、2GBまで増やせるということで、2GBのDDR3のタイプも同時に購入した。

 

そして、OSは、もともとインストールされていたのが、Windows7 Starter だったが、LinuxのFedoraとデュアルブートさせようと考えた。どうも、Linuxのほうが使いやすいからであった。

 

まずは、ハードディスクを交換しようと考えたが、U160DXでは、なかなか簡単にいきそうもなかったので、今回は見送った。

メモリの交換は簡単にできた。裏蓋の一部を外して、搭載されている1GBのメモリを2GBのメモリと入れ替えるだけであった。メモリのスロットは一個しかないので、メモリ増設は交換のみである。

 

3. ハードディスクの構成とデュアルブートのための準備

 

次に、ハードディスクの中味を調査した。このために、USBタイプのDVD/CDマルチドライブを外付けし、このドライブから、ツールを起動させた。使ったツールは、LifeBoat社の「LBパーティションワークスCD起動版2」である。

 

U160DXを購入したときの状態では、ハードティスクは次の4つのパーティションに区分されていた。

 

1. リカバリ用のデイスク領域(RCVR)-約4GB (NTFS)

2. Windows7の起動システム領域(SYSTEM)-約100MB (NTFS)

3. Windows7の本体、システム(OS_Install)-約170GB (NTFS)

4. データ領域(DATA)-約120GB (NTFS)

 

おおよそ、こんな感じであった。いずれも基本パーティションとなっている。そして、通常の使い方では、スイッチを入れると自動的に2の状態を経由し、3の状態のWindows7 Starterが立ち上がるしくみになっている。

 

さて、いろいろと試行錯誤した結果、上記の2-4の領域をフォーマットし、サイズも変更することとした。Windowsはリカバリ領域に入っているWindows7 Starterをそのまま再インストールして使用することとし、LinuxはFedoraの最新ディストリビューションであるFedora17をインストールすることにした。また、PCの起動には、「マルチブートマネジャー MBM (Multi Boot Manager)」を用いることとした。

 

最初に、MBMのシステムのISOファイルをダウンロードし、CD-Rを作成した。

→
http://elm-chan.org/fsw/mbm/mbm039.iso.gz

 

その次に、 Fedora17 のISOファイル(約680MB)をダウンロードし、CD-Rを作成した。

→　
http://download.fedoraproject.org/pub/fedora/linux/releases/17/Live/x86_64/Fedora-17-x86_64-Live-Desktop.iso

 

上記のパーティション作成ツールを使い、あらかじめ、2、3の領域を削除し、4のデータ領域のサイズを変更した後に、削除した領域をほぼ半分ずつに分けて、Linux以外の領域をフォーマットした。

 

次に、Windows7のインストールを領域1を起動させて行い、領域2にWindows7の本体システムをインストールした。これは、MBMを起動させて、領域1を起動することによってできる。

さらに、次に、未フォーマットの領域3にFedora17をディスクからインストールした。もちろん、この操作は、外付けのドライブから起動させての操作である。この場合の注意点として、Fedora17の起動に必要なブートローダー(GRUB)のインストール位置は、論理パーティションである領域3の先頭にすべきであって、ハードディスクの先頭にはしないことである。ハードディスクの先頭にインストールしてしまうと、MBMが使えなくなるという不都合が起きる可能性があるためである。

 

そして、MBMを外付けDVD/CDディスクドライブから起動し、ハードディスクへのインストールを行う。

 

 

最終的に、ハードディスクの中は、次のようなパーティションができる。

 

1. リカバリ用のデイスク領域(RCVR)-約4GB (ここは変更しない) (NTFS)

2. Windows7の本体、システム(OS_Install)-約80GB (NTFS)

3. 論理ドライブ -約80GB (LVM)

-- 3-1. Fedora17のBOOT領域 (EXT3)

-- 3-2. Fedora17の本体 (LVM)

-- 3-3. SWAP領域 (SWAP)

4. データ領域(DATA)-約120GB (FAT32)

 

データ領域は、Windows7とFedora17の両方から参照できるように、フォーマットはFAT32形式とした。

 

 

この構成で、起動にMBMを使って、デュアルブートの環境ができたのであった。上記の「2」と「3-1」を起動時に選択する。

 

ひとまず、現在はこの環境で問題なく動作できている。

 

4. 無線LANのドライバ

 

今回の移行で、一番、懸念した点は、Linuxで無線LANが使えるかどうかであった。しかし、Fedora17には標準でドライバが装備されているらしく、特にわざわざドライバをインストールしなくても無線LANが認識された。Windows7では、もちろんその問題はなかったので、これで、Windows/Linuxどちらの環境でも無線LANが使えるということができることとなった。

 

5. 最後に

 

データに関しては、バックアップしておいた外付けハードディスクから、内蔵ハードディスクのデータ領域に必要なデータをコピーすることで、特に大きな問題はなかった。また、 Dropbox をインストールしたので、これまで使用していたPCで使っていたクラウド上に保存してあるデータも同期させることができ、PCの乗り換えにあたっても問題はほとんど生じなかった。唯一、Dropbox設定直後のフォルダの同期に多少時間がかかったくらいで、これはデータの量を考えれば、妥当かなとおもえる。

 

 

(注意事項)

 

以上が、Cartina UM から U160DX への乗り換えの顛末となります。なんらかの参考になれば幸いです。ただし、ここに述べた操作は、筆者の経験をもとに記述したものであり、この記事の内容を適用したことによるいかなる結果にも筆者は一切の責任を負いかねますのでご了承ください。あくまでもPCの改造は自己責任で行って下さい。

 

(2012-7-15)

 

ことしも、幕張メッセで開催されたCEATECという展示会に出かけてきた。目的はいくつかあったのだが、世の中の流れを知るためには、実際に足を運んで見てみたかったのである。昨年と比べての大きな違いがあるとすれば、それは規模が縮小されているような印象を受けたことである。やはり不景気を反映しているのだろうか。

 

主なトピックスとしては、3D映像技術(しかもめがね不要の)、地デジ対応のさまざまな機器、アンテナやハードディスク、クラウドコンピューティング、非接触充電、無線LAN、さまさまなデータ処理技術、である。もちろん、見落としもあり、興味のないところは素通りしたので、ここで述べることが主観的で、すごく偏った感想となっていることはご承知を願いたい。

 

地デジ化の流れは、アナログテレビ放送が来年7月に終わることを受けてか、いよいよ本格的になってきたようである。

 

テレビをみるのには、いろんな方法があるが、CATVやLANに接続されていないところでみるために必要なアンテナが、UHFアンテナであり、そして衛星放送(BS)も見たい人はさらにパラボラアンテナが必要となってくる。

 

これらアンテナのデザインといえば、いままではその形をぱっと見で理解できるような単純なものであったが、今回、展示会で見かけたものは、ちょっと変わっていた。UHFアンテナは窓に取り付ける縦長タイプのものがあった。それは一見しただけではアンテナとは思えない優れたデザインのものだった。そして、BS用のアンテナも、「なんだ、これは、本当にアンテナ?」とおもわせるようなデザインであった。

 

共通することは、どちらもかわいいディズニーのキャラクターが使用されていることである。いままでのアンテナの固定観念を打破する画期的なデザインと感じた。(マスプロ電工　http://www.maspro.co.jp )

 

ミッキー・マウスのBS・CSアンテナ

 

ディズニー・キャラクターのアンテナのパンフレット

 

テレビ自体も、大型化大画面化の流れはあるが、立体化すなわち3D化も進んでいた。各社ともに3D対応のテレビが展示され、試写会が行われていて、そこは長蛇の列で二時間待ち、三時間待ちは普通とのこと。私はそんな時間もないので、素通りしたが、新しい情報とおもったことがひとつあった。

 

それは、眼鏡(めがね)不要で3Dが見られるものがあったということ。いままでは、3Dというのは見るために専用のめがねを必要とした。でもわすらわしい。やはり、眼鏡なしで見たいのが正直なところ。そんな人にはうれしい技術である。

 

NHKのブースに展示されていたのは、解像度がいまいちだったが、立体感は充分だった。横に見ても立体感は失われていなかった。大手各社も開発しているらしいが、前述のとおりの大混雑のため、今回はパス。きっと、眼鏡(めがね)不要の3Dテレビも展示されていたことであろう。ただ、NHKブースの人の話では、それらは横方向のみの制御しかしていないため、例えば、横に寝た状態でみると、立体に見えなくなるらしいとのこと。実際のところはまだよくわからずじまい。

 

これに関連して、録画の話題をひとつ。テレビ用のハードディスクが展示されていたのだが、なんと8台をひとつのテレビにつないでいた。ハードディスクの容量は一台あたり2TB(テラ・バイト、1TB=1000GB)で、それをハブとよばれる拡張機器で8台をつないだという。なるほど、こういう使い方もあるのか、と、ひとつ勉強になった。(ちなみに、そこに展示されていたテレビは東芝の「Cell Regza」であった。)

(アイ・オー・データ機器　http://www.iodata.jp )

 

従来は、250GBのハードディスクが一般的だった。ちなみに自宅のテレビ録画用ハードディスクの容量は150GBである。これに比べたら、ものすごい容量である。

 

非接触充電という技術も目を引いた。現実に携帯電話で実用化されているとのこと。ベースとなる台から機器(例えば、携帯電話の本体)に、周波数は忘れたが、たしか数百kHz(?)で電力を送る、そして、機器ではそれを整流して直流に直し、電池に充電するというもの。「電波で電力を送る」というしくみ、これから、一般化してくるのだろう。

 

コンピュータの進化もめざましかった。最近、クラウドコンピューティングということばを耳にする機会が多いように感じる。

 

クラウドとは、英語のcloud (雲)のことで、コンピュータの中にあるデータやプログラムといったソフトウェアが、実は遠く離れたサーバーという別の大型コンピュータ(?)の中にあるしくみで、手元のコンピュータ本体には、入力と表示の機能しかはいっていないものだそうだ。もちろん、インターネットの環境が必要で、暗号化により情報は保護されている。

 

デモをやっていたので、ちょっと触らせていただいた。なかなか使いやすい。これがクラウド型のシンクライアントソリューションなのかと。たしかに、もし、仮にコンピュータ本体を紛失しても(盗難にあったとしても)、情報は漏れないし、失われることがない。
(IIJ　http://www.iij.ad.jp )

 

今後、こういうものがだんだんと一般化してくるのだろうか。そういえば、TM社のウィルス対策ソフトも「クラウド」技術を導入したものだとか。

 

最後に、データ処理に関して、おもしろいとおもったことをひとつ、ご紹介したい。

 

携帯電話の待ち受け情報から人口の推移を見る

 

人口が時間毎にどのように変化していくかを、日本全体を対象に、地図上でグラフ表示している展示があった。写真では動きがわからないが、まず、何か所かに人口の集中している箇所がある。これが、時間毎に変化していくのだ。NTT docomoの携帯電話の位置発信機能を使って、統計処理しているとのことだった。昼と夜とでは、若干、分布が異なってくる。このデータは、また、別の意味で、日本の人口の都市集中の現実を考えさせられる。

 

(2010-10-11)

 

I purchased a small note PC called 'Cartina UM', the so-called net-book computer, at a low price by the mail order last year end.

 

Now I'm going to use it by wireless LAN connection by setting Fedora 9 as OS.
Although WLAN connection at Linux had a slightly high hurdle for me, I think, it was a good experience for the gymnastics of my brain.

 

The note PC currently I used mainly was operated under Windows 98SE OS. Since there were few memories which can be mounted (max 320MB), I wished to change it someday.

 

Last year, net-book computer 'Prime Note Cartina UM' with 8.9 type liquid crystal display was exactly released for 34,800 yen to the mail order site of Dospara, I decided to purchase it.

 

Please refer to the site of Dospara , or the next review site, etc. if you want to know what kind of the product it is.

 

- The review about Prime Note Cartina UM by Satlab

 

In my home, we use several sets of PCs connected by wireless LAN. Then, I decided to connect this 'Cartina UM' also by wireless LAN. Although it was easy when running, many things at the beginning were tried and it did not go very well.

 

There were two problems. One should say that OS is Linux. Another was that the ON/OFF method of the wireless LAN equipment as hardware was not indicated anywhere in the attached document.

 

Therefore, although many things will be tried, it became quite good study (gymnastics of my brain).

 

Originally attached first was an OS called fOS by FOXCONN, Taiwan. However, there is no description about the equipment of wireless LAN, operation, and a setup in the attached document. Although the driver for Windows was contained in the attached DVD-ROM disk, there is nothing for Linux.

 

According to the research result by the Internet, it becomes clear first that the chip set is of Realtek, and driver software can be obtained.

 

Then, I carried out the usual installation, and if a WLAN-related configuration file is added, it should run. But the WLAN did not work.

 

After further investigation, I found that the switch of ON/OFF of wireless LAN was [Fn]+ [F2]. (Since this was not indicated anywhere, before discovering, it will have required time.)

 

When it rebooted and the switch was turned ON, Cartina UM has accessed the Internet via wireless LAN at last.

 

I think that fOS, which contains general application softwares, can be used satisfactory every time, except the one point that a Japanese input cannot be performed.

 

Although I tried many things after that, a Japanese input was not worked in fOS after all. So, I decided to switch OS to another Linux, and choosed Fedora Core 9.

 

After having started from the external USB optical disk drive (used TEAC Portable USB CD-RW/DVD-ROM Unit purchased for 1,980 yen), installing and updating Fedora Core 9 to the hard disk and adding some software, 'Cartina UM' was connectable with the Internet via wireless LAN as well as the case of fOS.

 

The method I performed is indicated somewhat in detail in the document;
Cartina_UM_and_WLAN_with_FC9.pdf (in Japanese)
Cartina_UM_and_WLAN_with_FC9_(en).pdf (in English)

 

In fact, although the means of ndiswrapper was also considered, it is not progressing any more, because it was connectable with wireless LAN by the above-mentioned method about Fedora Core 9, .

 

Once, although ndiswrapper was also tried, it becomes an error and was improper here indicated that there is no libstdc++5.so.0.

Seemingly, the version of a system is different in fOS somehow.

I will leave it as a subject which should be solved in the future.

 

(2009-1-7)

 

 

One of the understanding; Somehow, seemingly, the wireless LAN driver must be re-installed in whenever a kernel is updated.
(Enter in the 'make' directory, and then type 'make uninstall'
and 'make install' to re-install.)

 

(2009-3-14 added)

 

 

---

(Comment)

 

In order to take the WLAN setting procedure using WEP introduced in the attached document, the MAC address of your PC (child's equipment) should be registered in the WLAN access point (parent's equipment) prior to use WLAN.