Bluray(ブルーレイ)ディスクが壊れている。
一見キズも無いし、盤面もキレイだが、何回やってもエラーが出る。
HDDいうところの不良セクタらしい。
映像ファイルだから、多少誤りがあっても読み取ってほしい
仕方がないので、Recovery Toolbox for CD Free を使って読み取らせる。
C:\> dism /Online /Cleanup-image /ScanHealth
システムイメージのチェックを行う。
修復は行わない。
C:\> dism /Online /Cleanup-image /CheckHealth
システムイメージのチェックを行い、イメージが正常か・破損している場合は修復が可能か不可能かの表示を行う。
修復は行わない。
C:\> dism /Online /Cleanup-image /Restorehealth
システムイメージのチェックを行い、問題がある場合にWindows Updateを用いて破損ファイルの修復を行います。
C:\> sfc /scannow
最近のHDDは大容量にになっていて消去に時間がかかるので、一挙に全部やるのではなく、分割して少しづつやる方法。
＜ポイント＞
・大容量HDDをパーティション分割して、パーティション事に削除する。
・パーティション削除は、ddコマンドで、status=progress オプションをつけ、進捗が分かるようにする
・ddの速度アップのためbsの値を大きめに調整する（128Mとか）
(1)gparted等で、ハードディスクをパーティションで分割する。
例えば、1000GBなら、200GBx5パーティション等。
/dev/sdb1
/dev/sdb2
/dev/sdb3
/dev/sdb4
/dev/sdb5
ができる。
(2)ddコマンドでパーティションを1づつ削除する。statusオプションをつけ進捗状況が分かるようにする。
# dd if=/dev/urandom of=/dev/sdb1 bs=128M status=progress
上記では乱数(/dev/urandomを指定していますが、ゼロ（/dev/zero）でもいいでしょう。
/dev/randomは乱数生成に厳密性を高めるため、マシンのエントロピーをたくさん必要とするため、HDD消去の目的には不向きです。
（時間がかかりすぎる、書き込む乱数の品質を高めてもしょうがない）
bsの値は小さすぎてもダメ、大きすぎてもダメ、何度かトライしてみて下さい。
パーティション分割が難しい場合は、ブロックするサイズを1024Mとかにして（わかりやすように）
・seek=ブロック数 で開始ブロックを指定
・count=個数 で書き込むブロック数を指定
するのでも良いでしょう。
（全体が何ブロックあって、開始位置と、個数を指定して、計画的にやる。面倒ですが）
■その後、ddは速度が出ない（遅い）ことが判明。
報告書
https://digitalforensic.jp/home/act/products/data_report/
低レベルな機能ゆえ、ddが一番シンプルで速そうだが、そうでもないようだ。原因を考えてみたが、/dev/zeroや/dev/urandom のシステムコールがボトルネックになってるんだろうか？
Windowsのcipherコマンドを利用する手もあるが、途中の進捗状況が分からないのは頂けない。求める要件は、
・消去速度が速いこと
・途中の進捗状況が分かる事
・パーティション事に消去出来れば、大容量HDDを分割消去できる。
速度が速いのは、DBAN, shred あたりのようだ。
shredを使って、乱数の1回書込みで十分なので、
# shred -v -n 1 /dev/sdd
とかで十分っぽい
-v: 途中詳細を表示させる
-n 1: 乱数書込み回数=1回
今のところ、DBANか、shred が一番速い。
後日、時間を測ってみる。
CentOSのバージョンが古くなり、アクセス先リポジトリに必要なUpdateが存在しない場合、
404エラーとなってUpdateができなくなります。
centos-release パッケージを更新する
# yum update centos-release
# yum check-update
→無事できるようになった
■Panasonic CF-SZ6JD3QR 【2017夏モデル】
Windows 10 Pro 64bit
CPU: Intel Core i7-7500U
メモリ: 8GB
ストレージ: 256GB SATA M.2 SSD
DVD: DVD スーパーマルチ
ディスプレイ: 12.i inch WUXGA 1290 x 1200
Microsoft Office Home & Business Premium
ストレージの仕様: Samusung PM871a 256GB, MZ-NLN256A, M.2 2280 SATA, KeyB+M型
本体M.2ソケットの仕様: Socket3(KeyM)
内蔵ストレージは、M.2 SATA SSDとDVDのみで、2.5インチSATA SSDを接続するコネクタが準備されていない！（スペースはあるが接続するコネクタが無い！）
内蔵HDDのモデルは、M/BのSATAコネクタから①DVD、②HDDの2つに分岐するケーブルが利用されているが、上記モデルは①DVDのみのケーブルになっている。
■ThinkPad X1 1286CTO Core i7 2640M搭載パッケージ
CPU Core i3 2350M, 2.3GHz/2コア
画面サイズ 13.3 インチ
解像度 WXGA (1366x768) タッチパネル
メモリ容量 2GB, メモリ規格 DDR3 PC3-10600
ストレージ容量 HDD回転数 7200 rpm
光学ドライブ 無し
Windows Update で 8024613 エラーが多発する。
当方の環境
OS: Windows Server 2012 R2 Standard
アンチウィルス(Anti virs): Symantec Endpoint Protection バージョン14
⇒ Symantec Endpoint Protection を無効にして、Windows Update をかけると解決。
2年越しのトラブルが解決。残っていた75個の update が無事成功。
他ユーザの参考になれば。
我が家のTV（東芝 Regza）の録画用に BuffaloのNASを利用。
換装履歴：たぶん2TB -> 4TB -> 8TB(今回実施）
1回目の換装
まっさらのHDDに tftpd でファームをロード
tftpdサーバの設定等、面倒だった記憶が。。。
2回目の換装（今回）
4TBのHDDをイメージコピーで8TBに引っ越し、後で、ファイルシステムを拡張することにする。
(0)以降のHDD移行時間を短くするためには、できるだけ容量が少ないほうが良いので、事前にNAS->USB HDD(別の8TBドライブ)にデータを移行させる。
移行作業は色々と試行錯誤なので、作業時間を短くしたい。
8TB HDDへの引っ越し完了後、データを戻せばよい。
実はここに落とし穴があり、多くのファイルを消したはずなのに時間がかかった！
理由はすぐ分かった。NASの設定で削除したファイルをtrashboxフォルダに残す設定になっていたため。ファイルを消さずにtrashboxにムーブする設定にしている人は、trashboxを空にしておく。
(1)HDDをバックアップツール(clonezilla)で4TB -> 8TBにリストア
disk to disk mode で実施。
dd でコピーしてもよかったのだが、clonezillaはxfsサポートしているので、格納しているファイル容量が少なければ、コピーが早く終わる（はずだった）。
USB Boot の LiveCD /dev/sda
コピー元 HDD(4TB) /dev/sdb
コピー先 HDD(8TB) /dev/sdc
(2)コピー後そのままでは、4TBしか使えないので、
a) 最後のデータ用パーティション（/dev/sdc6)を、SystemRescueCDのGparted で最大容量まで拡張する。
# startx
System -> GParted
/dev/sdc6を最大まで拡張する。
おそらくこれだけでいいはず。
私の方では、最初わからずうまく行っていない気がしたので、xfs_growfsも実施。
# mkdir /mnt/xfs
# mount /dev/sdc6 /mnt/xfs
# xfs_growfs /mnt/xfs #瞬間終わります。
容量を確認する
# df -h
RSAの鍵ペアを生成する際、高品質な乱数が必要という事で、どうやったらよいか調べてみた。
openssl コマンドで鍵ペア生成する際、乱数の指定( -rand )として
- 何も指定しない
- 乱数ファイルを指定する（何かのハッシュ値等）
- /dev/randomを指定する
方法があるが、/dev/random は、マシンのエントロピーを利用しているため、処理の進行がなかなか進まない（応答が返ってこない）。
OSは内部のHDDの動き等からエントロピーを取得して、ためているようだが、遅い。
そのため、エントロピーを増やすツールが提供されている。
- rng-tools #物理マシンならコレ
- havege(d) #仮想マシンならコレ
乱数を取得した後、素数判定のために、Miller-Rabin Test をかけるんだから、乱数の品質がどの程度影響あるのか・・・、という気もするが、ここは、深く追求しないことにする。
#真相を知ってる人がいたら教えて欲しい
仮想サーバ（VM）を使っている場合は、CPUに搭載されている乱数生成器（RNG）が使えない？ため、havegedを使うと良いらしい。
【作戦】
- 鍵ペア生成は物理マシンのLinuxで行う。
- opensslでRSA鍵ペア生成する際、-rand オプションで /dev/random を利用する
- /dev/random の値を増やすツールを動かす
今回、作戦3 を中心に記載します。
エントロピープールにどの程度情報がたまっているかを調べる
#cat /proc/sys/kernel/random/entropy_avail
⇒ 2桁位で少ない
エントロピープールの上限値を調べる（デフォルト4096）
# cat /proc/sys/kernel/random/poolsize
rng-toolsをインストールする
# yum install rng-tools
rngd デーモンを起動する
# systemctl start rngd
rngデーモンのステータスを確認する
# systemctl status rngd
現在溜まっているエントロピーを確認し、1000位上、2000位に増えていれば、正常に動作しているものと思われる。
# cat /proc/sys/kernel/random/poolsize
⇒1000～2000位に増えている。
鍵ペアを生成する
# openssl genrsa -rand /dev/random -out /tmp/privatekey.pem 2048
これで、無事、鍵ペア生成ができました。
rngd デーモンを停止する（普段は不要なので）
# systemctl stop rngd
方針
VMware謹製の VMware Tools ではなく、OSS版 open-vm-tools を導入する。
下記の記事を参考にする。
VMware : Open VM Tools のインストール
https://kb.vmware.com/s/article/2073803?lang=ja
Centos7になり、色々と変わっているようなので、まとめました。
■Consoleのキー設定入れ替え
やらないといけないことは、キーマップを書き換える事
/usr/lib/kbd/keymaps/legacy/i386/qwerty/jp106.map.gz
の中身が、
keycode 29 Control
keycode 58 Caps_Lock
となっているのを、
keycode 29 Caps_Lock
keycode 58 Control
に変更する。
実際には、keymap設定(jp106.map)を jp106-swapcaps.map にコピーして、中身を書き換えて
jp106-swapcaps.mapを読み込ませる、とやります。
直接変更して上書きしてもいいはずです。
#cd /usr/lib/kbd/keymaps/legacy/i386/qwerty
#cp -p jp106.map.gz jp106-swapcaps.map.gz
#gzip -d jp106-swapcaps.map.gz
#vi jp106-swapcaps.map
上記のkeycodeの入れ替えを行う
keycode 29 Caps_Lock # 要アンダースコア
keycode 58 Control
#gzip jp106-swapcaps.map
#localectl set-keymap jp106-swapcaps
----> /etc/vconsole.conf の内容が書き換わる
■X-Window (GNOME) のキー設定の入れ替え
#gsettings set org.gnome.desktop.input-sources xkb-options "['ctrl:swapcaps']"
■GNOMEのxkb-options の変更設定がうまくいかないとき
$ dconf-editor
GUI の設定画面が開くので org > gnome > desktop > input-sources > xkb-options を開きます。
そこに Custom Value 欄があるので、必要な内容（ここでは 'ctrl:swapcaps' ）を記述して下さい。
デフォルト値を設定してもなぜかダメでした。
参考: https://qiita.com/mkuriki1990/items/6fcdf9ab9eb9d4d74eb6
