【概要】 ddで作ったクローンディスクのWindowsのシステムパーティションをgpartedを使ってリサイズし、Windowsの正常動作を確認しました。gpartedでは、ファイルシステムにエラーがある場合でも、それをチェックして、修正を促してくれます。GUIベースの便利なツールです。
- 1. はじめに
- 2. 丸ごとコピーのクローン
- 3. 縮小クローン
- 4. 拡大クローン
- 5. 最後に
- 関連記事
- 付録A：SSDおよびddコピーしたHDDのgdiskの結果
- 付録B：Windowsが認識するディスクサイズ
- 付録C：ディスクケースによって、認識するディスクサイズが異なる
1. はじめに
dynabook の SSD への換装の記事を書いてきましたが、一応は、SSD へ換装できました。但し、クリアインストールです（涙）。
リベンジと「ディスククローンの作り方」の記事の検証を兼ねて、クリアインストールしてセットアップした SSD イメージのクローンを作成しました。
今度は、500GB の SSD がマスターイメージ、ターゲットディスクは 2TB の HDD です。パーティションを変更しない丸ごとコピーのクローン、縮小したクローン、拡大したクローンのそれぞれを作りました。
まずは、パーティションを変更しない丸ごとコピーのクローンを作って動作確認した後に、次に同じハードディスクでパーティションを縮小したクローンを作り、最後にパーティションを拡大したクローンを作ります。
2. 丸ごとコピーのクローン
2.1 ddによるコピー
まず、 SSD イメージを dd でハードディスクに dd で丸ごとコピーします。
$ dd if=/dev/sdS of=/dev/sdT bs=1M
ここで、/dev/sdS は SSD、/dev/sdTは 2TB のハードディスクです（適宜、 /dev/sda、 /dev/sdb のように読み替えてください）。また、ddのオプションとしてブロックサイズを指定すると高速にコピーできます。環境によって違うと思いますが、1Mバイト（=2048セクタ×512バイト）を指定しました。
2.2 gdisk による GPT テーブルの修正
gdiskによって、SSD、HDDのそれぞれについてパーティション構成を調べました（それぞれのログは付録A参照）。
まず、gdiskは、SSD、HDDのいずれの場合にも、「The protective MBR's 0xEE partition is oversized! Auto-repairing. 」というエラーメッセージを出力します。GPTテーブルとディスクサイズの間に不整合があるようです*1。
当初、このエラーメッセージは、Windowsが認識しているディスサイズとLinuxで認識しているディスサイズの違いかと思いましたが、必ずしもそうではなさそうです。この問題については付録Bで考察します。
また、gdiskの結果は、ディスクのハードウェア情報を除けば、一致しています。
（SSD） Disk /dev/sdc: 976773168 sectors, 465.8 GiB Model: Samsung SSD 860 （HDD） Disk /dev/sdb: 3907029168 sectors, 1.8 TiB Model: ST2000LM003 HN-M
ディスクとそのディスクが持つセクタ数の違いをgdiskは認識していますが、パーティション構成は同じで、空きスペースも同じと表示します。
Total free space is 3342 sectors (1.6 MiB)
HDDに対してコマンドvで検証すると、第2GPTの位置がディスク末尾に来ていないという問題点を指摘されます。SSDの場合には、この問題は指摘されません。
Problem: The secondary header's self-pointer indicates that it doesn't reside at the end of the disk. If you've added a disk to a RAID array, use the 'e' option on the experts' menu to adjust the secondary header's and partition table's locations. Identified 1 problems!
コマンドeで第2GPTテーブルをディスク末尾にリロケーションすると、空きスペースの領域は、1.4TiBとなり、正しく認識されました。また、検証コマンドvでも問題点は指摘されないようになります。
（HDD：GPT修正前） First usable sector is 34, last usable sector is 976773134 Total free space is 3342 sectors (1.6 MiB) （HDD：GPT修正後） First usable sector is 34, last usable sector is 3907029134 Total free space is 2930259342 sectors (1.4 TiB)
また、gnome-disksでみるパーティション構成は、下図のようになりました。
500GB の SSD のパーティション構成（gnome-disks）
2TB の HDD のパーティション構成（gnome-disks）
gnome-disksの出力は、GPTテーブルの修正前後で同一で、当初から1.5TBの空き領域を認識している。
なお、今回、ディスクケースを変更したところ、ディスクケースによって、認識するディスクサイズが異なる場合があることに気づきました。詳しくは付録Cで説明します。
2.3 dynabookに内蔵して動作確認
出来上がったクローンディスクをdynabookに入れ直して、動作確認しました。以前にSSDを内蔵したままHDDを外付けで繋いだら、内蔵していたオリジナルのディスクのWindowsシステムを破壊したことがあるので、SSDは外しました。SSDとdynabookには、物理的な接続はありません。
さて、ディスクを入れ替えて、Windows10を起動したところ、無事、起動できました。
起動に2分近くかかったので、途中あせりましたが、SSD での数秒の起動に慣れてしまうと、ハングアップしていると思ってしまいます。
「コンピュータの管理」の「ディスクの管理」を確認すると、1.4TiB が未割り当てとして正常に認識されています。
未割り当て領域は 1.4TiB。
また、「イベントビューアー」にディスク構成の変更が記録されています。
デバイスが異なると、警告あり。
イベントビューアーには、警告があります。今回のデバイス (シーゲートのHN-M201RAD) は、前回のデバイス (SamsungのSSD 860) と異なっているためです。この違いが、他の動作に影響を与えているか、不明ですが、今のところ、不具合はなさそうです。
Windows 上の gdisk を使って、GPT テーブルの比較をしましたが、ディスクのモデル名を除き、Linux 上の結果と一致しました。
3. 縮小クローン
次に同じディスクを用いて、縮小クローンを作成しました。Windows OSが入っている約450GBのNTFSのパーティションを390GBに縮小します。
3.1 gpartedによるパーティション構成の変更
gpartedを起動し、GUIに従って、Windowsシステムが入っているパーティション3を約450GBから約390GBに縮小しました。それ以外のパーティションは変更せず、パーティション４、５については、ディスクの先頭方向（gparted画面の左方向）に移動させて、パーティション３を縮小してできた隙間を埋めます。
処理時間は20分程度で、特に問題は発生しませんでした。gdiskでみたパーティション情報にも、特に問題はありませんでした。
$ gparted /dev/sdT
変更前のパーティション構成。パーティション３は、452GB。
パーティション3を452GBから390GBに縮小。
但し、パーティション４、パーティション５は、パーティションタイプが「Microsoft Windows回復環境（システム）」(gnome-disks）であり、このパーティションを移動させようとすると、gparted は次の警告を与えます。ちょっと心配になります。
システム領域を変更しようとすると、起動の失敗の可能性ありと警告。
3.2 dynabookに内蔵して動作確認
dynabook の内蔵ディスクを 2TB の縮小クローンディスクに入れ替え、Win10 を起動しましたが、特に問題ありませんでした。
パーティション３は、390GBに縮小され、1460GBの未割り当て領域ができる。
この段階の縮小クローンのディスクサイズは 2TB ですが、これを小さなディスクに、ddコピーし、gdiskでGPTテーブルを修復すれば、本当の縮小クローンの完成です。これについては、適当なディスクが手元になかったので、未検証ですが、たぶん、問題なく動作すると思います。
3.3 あっ、電源が！
dynabook をちょっと動かしたときに電源が落ちてしまいました！AC電源を使っていたつもりだったのですが、電気が来ておらず、バッテリーだけで動作させている状態でした。バッテリーも、裏ブタをしっかりと閉めずにいたので、動かしたときに接点が外れたのでしょう。突然の電源オフです。
この突然の不正シャットダウンでファイルシステムを壊したらしく、その後、アカウントにサインインできなくなりました。
アカウントにサインインできない！
マイクロソフトのホームページ*2に従って、ファイルシステムチェッカー*3を実行しましたが、復旧せず、諦めました。
ファイルシステムチェッカーの実行。
このことが、その後、パーティション拡大時のエラーの原因となります。
4. 拡大クローン
次に同じディスクで、未割り当て領域の 1.4TiB をパーティション３ (Windows領域) に割り当てます。
4.1 gpartedによるパーティション構成の変更
パーティション４、５を末尾に移動し、パーティション３を拡大します。
変更予定のパーティション構成。
パーティションp4, p5を右に移動し、p3 を拡大、その後、p4, p5を左に移動。
パーティション４、５を右に移動し、パーティション３とパーティション４の間に1.4TiBの空きを作り、その空き領域を使って、パーティション３を拡大します。その後、パーティション３とパーティション４の間にできた1MiB程度の隙間を埋めるために、パーティション４，５を左に移動するようにしました。（アライメント調整の影響ですが、gpartedでは、なぜか、隙間ができたり、できなかったりします）
4.2 gpartedでエラーが発生！
パーティション構成変更の実行中にエラーが発生しました。
エラー発生！
詳細情報を見ると、ファイルシステムのエラーチェックで、エラーを検知して、処理を中断したようです。おそらく、前述した不意の電源断でファイルシステムを破壊したのだと思います。
ファイルシステムのエラーチェックで処理を中断。
エラーメッセージにあるように、Windowsで、chkdsk /f を行いました。２回行うことを指示していますが、再起動だけ２回なのか、chkdskも含めて２回なのか良く分からなかったので、「chkdsk→再起動→chkdsk→再起動→完全シャットダウン」と処理しました。
その後、拡大処理から再開し、無事、パーティション３の拡大処理を完了しました。
chkdsk後のパーティション構成。
拡大処理後のパーティション構成。パーティション３が1.8TiBに拡大。
今度のパーティション構成では、ディスク末尾の空き領域はなくなっていますが、gparted のアライメント調整の影響です。アライメント調整の制限を加えると、gparted では、隙間ができたり、できなかったりします。原因は不明です。
4.3 dynabookに内蔵して動作確認
拡大クローンを dynabook に入れて、動作確認しましたが、サインインできない問題を除けば、問題なく動作しました。サインインの問題は、パーティションのリサイズが原因ではなく、不意の電源断が原因です。
パーティション３は、1.8TiBと大きくなっている。
5. 最後に
gpartedを使って、パーティションのリサイズ・移動を行いました。gpartedによってリサイズしても今のことろ動作には問題はないようです。
WindowsのOSが入っているシステム領域のリサイズ・移動や、ハードウェアの変更によって、Windowsが起動できなくなると危惧していましたが、（突然の電源断がなければ）案外、簡単にクローンディスクを作れることが分かりました。
但し、今回はパーティション１のEFIシステムや、パーティション２のMicrosoft予約領域については、一切、移動・リサイズを行っていません。パーティション４やパーティション５のWindowsの回復環境についても、移動はしましたが、リサイズは行っていません。
おそらく、パーティション１やパーティション２のリサイズ・移動を行うと、Windowsの起動で問題が発生すると思っています。
(2018/9/19)
関連記事
- Dynabook AZ77のSSDへの換装 (1) データのバックアップ - 虎之助の徒然記
- Dynabook AZ77のSSDへの換装 (2) HDD/SSDの入れ替え - 虎之助の徒然記
- Dynabook AZ77のSSDへの換装 (3) ddを使ったディスクのコピー - 虎之助の徒然記
- Dynabook AZ77のSSDへの換装 (4) NTFSには完全シャットダウンが必須 - 虎之助の徒然記
- クローンディスクの作り方 (1) Linuxの場合 - 虎之助の徒然記
- GPTテーブルを読み取るプログラムを作って、Windowsディスクを調べた（in Python） - 虎之助の徒然記
付録A：SSDおよびddコピーしたHDDのgdiskの結果
- 500GBのSSD
$gdisk /dev/sdS -l
GPT fdisk (gdisk) version 1.0.3
The protective MBR's 0xEE partition is oversized! Auto-repairing.
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 976773168 sectors, 465.8 GiB
Model: Samsung SSD 860
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): D169EDB1-AEC2-11E8-A251-8FB413A6DF47
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3342 sectors (1.6 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 534527 260.0 MiB EF00 EFI system partition
2 534528 567295 16.0 MiB 0C01 Microsoft reserved ...
3 567296 950381278 452.9 GiB 0700 Basic data partition
4 950382592 952256511 915.0 MiB 2700
5 952256512 976773119 11.7 GiB 2700 Basic data partition
- 2TBのHDD
$ sudo gdisk -l /dev/sdT
GPT fdisk (gdisk) version 1.0.3
The protective MBR's 0xEE partition is oversized! Auto-repairing.
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 3907029168 sectors, 1.8 TiB
Model: ST2000LM003 HN-M
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): D169EDB1-AEC2-11E8-A251-8FB413A6DF47
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3342 sectors (1.6 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 534527 260.0 MiB EF00 EFI system partition
2 534528 567295 16.0 MiB 0C01 Microsoft reserved ...
3 567296 950381278 452.9 GiB 0700 Basic data partition
4 950382592 952256511 915.0 MiB 2700
5 952256512 976773119 11.7 GiB 2700 Basic data partition
- GPTヘッダ修正後のHDD
$ gdisk -l /dev/sdT
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 3907029168 sectors, 1.8 TiB
Model: ST2000LM003 HN-M
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): D169EDB1-AEC2-11E8-A251-8FB413A6DF47
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2930259342 sectors (1.4 TiB)
Number Start (sector) End (sector) Size Code Name
1 2048 534527 260.0 MiB EF00 EFI system partition
2 534528 567295 16.0 MiB 0C01 Microsoft reserved ...
3 567296 950381278 452.9 GiB 0700 Basic data partition
4 950382592 952256511 915.0 MiB 2700
5 952256512 976773119 11.7 GiB 2700 Basic data partition
付録B：Windowsが認識するディスクサイズ
当初、gdiskが出力する「The protective MBR's 0xEE partition is oversized! Auto-repairing. 」の警告は、Windowsが認識しているディスクサイズが、Linuxでgdiskが認識しているディスクサイズよりも小さいために発生している現象と疑っていました。
なぜなら、WIndowsの「システム情報」に書かれた「サイズ」が小さかったからです。しかし、「システム情報」の「サイズ」は、gdiskが定義するディスクサイズとは違い、Windowsが認識するディスクサイズが小さいとは必ずしも言えないようです。
Windowsの「システム情報」の「サイズ」「セクター合計」は、実際に使えるディスクのサイズを表していません。今回のSSDでは、「セクター合計」は976,768,065 で、「サイズ」はセクタ数を512倍した 500,105,249,280 バイトです。一方、最後の「パーティション#3」の「開始オフセット」 (487,555,334,144バイト) と「パーティションサイズ 」(12,552,503,296バイト)から、パーティションの末尾は、500,107,837,440バイト目となります。これは、「サイズ」よりも、2,588,160バイト、セクタ数で言うと5,055セクタ大きい数字です。最後のパーティションは、ディスクを5,055セクタはみ出てしまうことになります。
SSDは、クリアインストールしたディスクですので、Windowsの標準的なインストールによって、パーティションが作られています。パーティション作成で異常が発生していることもありえますが、可能性としては低いと思います。つまり、「システム情報」の「セクター合計」「サイズ」は、実際に使えるディスクサイズを反映していないと考えれます。
では、「システム情報」の「セクタ合計」「サイズ」は何を表すかというと、「シリンダー合計」から算出したディスクサイズです。
- 「サイズ」＝「セクター合計」×512バイト
- 「セクター合計」＝「トラック合計」×63
- 「トラック合計」＝「シリンダー合計」×255
よって、
- 「サイズ」＝「シリンダー合計」×255×63×512バイト
となります。この計算方法で、500GBのSSDや2TBのHDDの「システム情報」の「セクタ合計」「サイズ」を説明できます。
Microsoftの公式ツールで、実際のディスクサイズの大きさを調べられるか、私は知りません。
しかし、Windows版gdiskでは調べられます。Windows版のgdiskの結果は、Linux版gdiskと同一でした。このことからすれば、Windowsから見たディスクサイズとLinuxで見たディスクサイズは一致する可能性が高いと推測しています。
しかし、同じgdiskなので、同じ数字を出力している可能性もあります。より詳しく調べるためには、直接、GPTテーブルを解析する必要もありそうです*4。
|
追記：GPTテーブルを読み込むプログラムを作って解析しましたが、WindowsのGPTテーブルには問題はなさそうです。 GPTテーブルを読み取るプログラムを作って、Windowsディスクを調べた（in Python） - 虎之助の徒然記 |
Windowsの「システム情報」。
付録C：ディスクケースによって、認識するディスクサイズが異なる
今回、用いた外付けディスクケースは、ELUTENGですが、SMART情報が見れないため、別のディスクケースに繋いだところ、gdisk、gnome-disksで見たディスクサイズが異なっていることに気付きました。
C.1 ELUTENG・玄人志向・センチュリーのディスクケース
そこで、次の3つのディスクケースについてgdisk、gnome-disksの動作を調べてみました。
- ELUTENG
- 玄人志向
- センチュリー
C.2 ディスクサイズが小さくなる玄人志向・センチュリー
500GBのSSD、2TBのHDDに対するgdiskやgnome-disksの出力の主な違いを表にまとめると、以下の通りです。
| ELUTENG | 玄人志向 | センチュリー | |
| gnome-disks | |||
| ディスクサイズ | - | 512バイト少ない | 512バイト少ない |
| SMART | - | 対応 | - |
| 不良セクタ検知 | - | 不良セクタを検知 | - |
| シリアルナンバー | 認識せず | 正しく認識 | 間違って認識 |
| gdisk | |||
| セクタサイズ | - | 1セクタ少ない | 1セクタ少ない |
| モデル名 | 正しく認識 | 間違って認識 | 正しく認識 |
gdisk、gnome-disksのどちらの場合でも、玄人志向・センチュリーのディスクケースではディスクサイズをELUTENGよりも小さく認識します。
C.3 gdiskにおける警告メッセージとディスク検証
500GBのSSD（Windowsシステムの入ったディスク）に対して、それぞれgdiskを行うと次のメッセージが得られます。
- ELUTENGの場合
- 起動時のメッセージ
パーティションが大きすぎると警告されるも、GPTテーブルは有効と判定。The protective MBR's 0xEE partition is oversized! Auto-repairing.
Partition table scan: MBR: protective BSD: not present APM: not present GPT: present
Found valid GPT with protective MBR; using GPT. - 検証コマンドvのメッセージ
問題なし。No problems found. 3342 free sectors (1.6 MiB) available in 3 segments, the largest of which is 2014 (1007.0 KiB) in size.
- 起動時のメッセージ
- 玄人志向・センチュリーの場合
- 起動時のメッセージ
ディスクサイズが小さすぎ、第2GPTテーブルが壊れていると、警告される。Warning! Disk size is smaller than the main header indicates! Loading secondary header from the last sector of the disk! You should use 'v' to verify disk integrity, and perhaps options on the experts' menu to repair the disk. Caution: invalid backup GPT header, but valid main header; regenerating backup header from main header.
Partition table scan: MBR: protective BSD: not present APM: not present GPT: damaged
**************************************************************************** Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended. **************************************************************************** - 検証コマンドvのメッセージ
GPTテーブルがディスク末尾にない、ディスクが小さすぎる、パーティションが大きすぎると、3つの問題点を指摘される。Problem: The secondary header's self-pointer indicates that it doesn't reside at the end of the disk. If you've added a disk to a RAID array, use the 'e' option on the experts' menu to adjust the secondary header's and partition table's locations.
Problem: Disk is too small to hold all the data! (Disk size is 976773167 sectors, needs to be 976773168 sectors.) The 'e' option on the experts' menu may fix this problem.
Partition(s) in the protective MBR are too big for the disk! Creating a fresh protective or hybrid MBR is recommended.
Identified 3 problems!
- 起動時のメッセージ
C.4 結論：玄人志向・センチュリーはディスクサイズを１セクタ小さく誤認識する
”Disk size is 976773167 sectors, needs to be 976773168 sectors.”の指摘からすると、次のようなことかと思います。
- SSDのGPTテーブルには、ディスクサイズは976,773,168セクタと書いてある。
- 玄人志向・センチュリーの外付けケースを介して認識されたディスクサイズは、それよりも1つ少ない976,773,167セクタである。
- このため、GPTテーブルのディスクサイズよりも、ディスクが小さすぎると指摘される。
つまり、玄人志向・センチュリーの外付けディスクケースは正しくディスクサイズを認識せず、本来のディスクよりも1セクタ少ないディスクとして取り扱ってしまうということです*5。
以前の記事で、dynabookの1TBのHDDをddで読み込んだデータが1セクタ不足する現象が発生したと書きました。
このときに用いたディスクケースは、センチュリーのケースです。センチュリーのディスクケースを使ったため、オリジナルのディスクを1セクタ少なく認識し、ddダンプしたデータが1セクタ不足するという現象が発生したと考えられます。
*1:"The oversized 0xEE partition ...(snip)... could indicate something strange to do with disk size detection." (Rod Smith, gdiskの開発者)
https://superuser.com/questions/1023343/after-upgrading-from-windows-7-to-windows-10-system-thinks-gpt-partition-is-mbr#comment1424307_1023702
*2:https://support.microsoft.com/ja-jp/help/4027881/windows-10-we-cant-sign-in-to-your-account
*3:https://support.microsoft.com/ja-jp/help/4026529
*4:GPTとMBRはどのように違うのか？ - syuu1228's blog
*5:仕様上は、玄人志向・センチュリーの方が正しくて、ELUTENGやdynabookの内蔵ディスクのドライバが１つ多く間違って認識しているという可能性もあります。しかし、今回の場合は、dynabookの内蔵ディスクのドライバと同様にディスクサイズを認識する必要があるので、dynabookと一致する場合が「正しい」と考えることにします。また、この動作は、Linux上での動作であって、Windows上では異なった動作をするのかもしれません。
