システム領域を変更しようとすると、起動の失敗の可能性ありと警告。起動しましたが、特に問題ありませんでした。パーティション3は、390GBに縮小され、1460GBの未割り当て領域ができる。これを小さなディスクに、ddコピーし、gdiskでGPTテーブルを修復すれば、本当の縮小クローンの完成です。これについては、適当なディスクが手元になかったので、未検証ですが、たぶん、問題なく動作すると思います。動かしたときに電源が落ちてしまいました!AC電源を使っていたつもりだったのですが、電気が来ておらず、バッテリーだけで動作させている状態でした。バッテリーも、裏ブタをしっかりと閉めずにいたので、動かしたときに接点が外れたのでしょう。この突然の不正シャットダウンでファイルシステムを壊したらしく、その後、アカウントにサインインできなくなりました。アカウントにサインインできない!マイクロソフトのホームページ*2に従って、ファイルシステムチェッカー*3を実行しましたが、復旧せず、諦めました。ファイルシステムチェッカーの実行。このことが、その後、パーティション拡大時のエラーの原因となります。gpartedによるパーティション構成の変更パーティション4、5を末尾に移動し、パーティション3を拡大します。変更予定のパーティション構成。パーティション4、5を右に移動し、パーティション3とパーティション4の間に1.4TiBの空きを作り、その空き領域を使って、パーティション3を拡大します。その後、パーティション3とパーティション4の間にできた1MiB程度の隙間を埋めるために、パーティション4,5を左に移動するようにしました。gpartedでエラーが発生!パーティション構成変更の実行中にエラーが発生しました。エラー発生!詳細情報を見ると、ファイルシステムのエラーチェックで、エラーを検知して、処理を中断したようです。前述した不意の電源断でファイルシステムを破壊したのだと思います。ファイルシステムのエラーチェックで処理を中断。2回行うことを指示していますが、再起動だけ2回なのか、chkdskも含めて2回なのか良く分からなかったので、「chkdsk→再起動→chkdsk→再起動→完全シャットダウン」と処理しました。その後、拡大処理から再開し、無事、パーティション3の拡大処理を完了しました。chkdsk後のパーティション構成。拡大処理後のパーティション構成。パーティション3が1.8TiBに拡大。アライメント調整の影響です。隙間ができたり、できなかったりします。入れて、動作確認しましたが、サインインできない問題を除けば、問題なく動作しました。サインインの問題は、パーティションのリサイズが原因ではなく、不意の電源断が原因です。パーティション3は、1.8TiBと大きくなっている。最後にgpartedを使って、パーティションのリサイズ・移動を行いました。gpartedによってリサイズしても今のことろ動作には問題はないようです。WindowsのOSが入っているシステム領域のリサイズ・移動や、ハードウェアの変更によって、Windowsが起動できなくなると危惧していましたが、(突然の電源断がなければ)案外、簡単にクローンディスクを作れることが分かりました。今回はパーティション1のEFIシステムや、パーティション2のMicrosoft予約領域については、一切、移動・リサイズを行っていません。パーティション4やパーティション5のWindowsの回復環境についても、移動はしましたが、リサイズは行っていません。パーティション1やパーティション2のリサイズ・移動を行うと、Windowsの起動で問題が発生すると思っています。」の警告は、Windowsが認識しているディスクサイズが、Linuxでgdiskが認識しているディスクサイズよりも小さいために発生している現象と疑っていました。WIndowsの「システム情報」に書かれた「サイズ」が小さかったからです。「システム情報」の「サイズ」は、gdiskが定義するディスクサイズとは違い、Windowsが認識するディスクサイズが小さいとは必ずしも言えないようです。Windowsの「システム情報」の「サイズ」「セクター合計」は、実際に使えるディスクのサイズを表していません。」(12,552,503,296バイト)から、パーティションの末尾は、500,107,837,440バイト目となります。これは、「サイズ」よりも、2,588,160バイト、セクタ数で言うと5,055セクタ大きい数字です。最後のパーティションは、ディスクを5,055セクタはみ出てしまうことになります。SSDは、クリアインストールしたディスクですので、Windowsの標準的なインストールによって、パーティションが作られています。パーティション作成で異常が発生していることもありえますが、可能性としては低いと思います。「システム情報」の「セクター合計」「サイズ」は、実際に使えるディスクサイズを反映していないと考えれます。「システム情報」の「セクタ合計」「サイズ」は何を表すかというと、「シリンダー合計」から算出したディスクサイズです。「サイズ」=「シリンダー合計」×255×63×512バイトとなります。この計算方法で、500GBのSSDや2TBのHDDの「システム情報」の「セクタ合計」「サイズ」を説明できます。Microsoftの公式ツールで、実際のディスクサイズの大きさを調べられるか、私は知りません。Windows版gdiskでは調べられます。Windows版のgdiskの結果は、Linux版gdiskと同一でした。このことからすれば、Windowsから見たディスクサイズとLinuxで見たディスクサイズは一致する可能性が高いと推測しています。同じgdiskなので、同じ数字を出力している可能性もあります。詳しく調べるためには、直接、GPTテーブルを解析する必要もありそうです*4。追記:GPTテーブルを読み込むプログラムを作って解析しましたが、WindowsのGPTテーブルには問題はなさそうです。虎之助の徒然記Windowsの「システム情報」。付録C:ディスクケースによって、認識するディスクサイズが異なる今回、用いた外付けディスクケースは、ELUTENGですが、SMART情報が見れないため、別のディスクケースに繋いだところ、gdisk、gnome-disksで見たディスクサイズが異なっていることに気付きました。ELUTENG・玄人志向・センチュリーのディスクケースそこで、次の3つのディスクケースについてgdisk、gnome-disksの動作を調べてみました。HDTV等対応ELUTENG先月購入したスケルトンケース。GW2.5CR-U3玄人志向2014年発売でUSB3.0対応。CSS25U2BKセンチュリーUSB2.0接続の古い製品です。ディスクサイズが小さくなる玄人志向・センチュリー500GBのSSD、2TBのHDDに対するgdiskやgnome-disksの出力の主な違いを表にまとめると、以下の通りです。認識gdisk、gnome-disksのどちらの場合でも、玄人志向・センチュリーのディスクケースではディスクサイズをELUTENGよりも小さく認識します。gdiskにおける警告メッセージとディスク検証500GBのSSD(Windowsシステムの入ったディスク)に対して、それぞれgdiskを行うと次のメッセージが得られます。起動時のメッセージパーティションが大きすぎると警告されるも、GPTテーブルは有効と判定。GPT.検証コマンドvのメッセージ問題なし。起動時のメッセージディスクサイズが小さすぎ、第2GPTテーブルが壊れていると、警告される。recommended.****************************************************************************検証コマンドvのメッセージGPTテーブルがディスク末尾にない、ディスクが小さすぎる、パーティションが大きすぎると、3つの問題点を指摘される。sectors.”の指摘からすると、次のようなことかと思います。SSDのGPTテーブルには、ディスクサイズは976,773,168セクタと書いてある。玄人志向・センチュリーの外付けケースを介して認識されたディスクサイズは、それよりも1つ少ない976,773,167セクタである。このため、GPTテーブルのディスクサイズよりも、ディスクが小さすぎると指摘される。玄人志向・センチュリーの外付けディスクケースは正しくディスクサイズを認識せず、本来のディスクよりも1セクタ少ないディスクとして取り扱ってしまうということです*5。以前の記事で、dynabookの1TBのHDDをddで読み込んだデータが1セクタ不足する現象が発生したと書きました。このときに用いたディスクケースは、センチュリーのケースです。センチュリーのディスクケースを使ったため、オリジナルのディスクを1セクタ少なく認識し、ddダンプしたデータが1セクタ不足するという現象が発生したと考えられます。blog*5:仕様上は、玄人志向・センチュリーの方が正しくて、ELUTENGやdynabookの内蔵ディスクのドライバが1つ多く間違って認識しているという可能性もあります。今回の場合は、dynabookの内蔵ディスクのドライバと同様にディスクサイズを認識する必要があるので、dynabookと一致する場合が「正しい」と考えることにします。この動作は、Linux上での動作であって、Windows上では異なった動作をするのかもしれません。楽天ROOMにガジェットをまとめてます。グレイテスト・ショーマン心温まるミュージカル。