虎之助の徒然記

ubuntuのインストールメモ

【概要】
 ubuntuやlubuntuの筆者用のカスタマイズのための設定についてまとめました。

1. はじめに

 最近、ubuntuやlubuntuを何度となくインストールしました。筆者用のカスタマイズのための設定をメモしておきます。

  • 対象OS:ubuntu (MATE環境) , lubuntu の18.04

 ubuntu-mateは、15.10からアップグレードし続けているものを参考にしているので、クリアインストールした場合とは違う可能性があります。

 ubuntuとlubuntuで設定が違う場合もありますが、そこは、適宜対応。

2. インストールするパッケージ

 いつも使うパッケージをインストールする。

$ sudo apt install package1 package2 ...
  • emacs, ssh, tcsh, xrdp, gnome-screenshot, gpartedなど(スクリプトが最新版)
  • net-tools: ifconfigに必要
  • gnome-tweaks
    • CapsLockのCtrlへのアサイン、蓋を閉じたときの動作、ウィンドウフォーカスなどの設定
    • 蓋の動作、ウィンドウフォーカスなどには、gnome-tweak-toolやgnome-shellが必要かも。
#!/bin/sh

# basic tools
sudo apt install emacs tcsh gnome-screenshot gnome-tweaks

# networks
sudo apt install ssh net-tools xrdp

# file system and disk utility
sudo apt install ntfs-3g gnome-disk-utility gdisk gparted

# nfs client & server
sudo apt install nfs-common nfs-kernel-server

# might be required additionally 
# sudo apt install gnome-tweak-tool

# octave
# sudo apt install octave

# python3
# sudo apt install python3-numpy
  • パッケージを探す*1
$ apt search pattern
$ apt-cache search parttern
  • インストール済のパッケージに入っているツールをリストアップする
$ dpkg -L package1 package2 ...
  • ツールが入っているインストール済のパッケージを探す
$ dpkg -S pattern1 pattern2 ...

3. 設定

  • gnome-tweaks
     gnome-tweaksで、GUIベースで簡単にいろいろなカスタマイズを行える。

    • CapsLockをCntrlにアサインする
      • 「Ctrl position」と「CapsLock behavior」の二つがあるが、どちらかで設定すれば大丈夫。
    • ラップトップの蓋を閉じたときの動作
      • 「電源」→「ラップトップの蓋を閉じるとサスペンドする」をオフ  これは、ubuntu, lubuntuのデスクトップパネルからも設定できる(どちらが優先されるか不明)
        • lubuntu:「設定」→「電源管理」→「ラップトップの蓋」(「サスペンド」以外を選択)にも設定あり。BIOSの場合もあり。
        • ubuntu-mate:「システム」→「設定」→「ハードウェア」→「電源管理」(ここに、ノートパソコンならあると思う。未確認)
           
  • aliasesの設定
    .bash_aliases

    alias   ls='/bin/ls -CF'
    alias   mv='/bin/mv -i'
    alias   rm='/bin/rm -i'
    alias   cp='/bin/cp -i'
    

  • 固定IPアドレス
    /etc/network/interface を編集して、固定IP化するのが古典的方法。ifup や ifdownで制御できる。

source /etc/network/interfaces.d/*
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

#### dhcp setting ######
# auto enp0s3
# iface enp0s3 inet dhcp
 
#### static ip setting ######
auto enp0s3
iface enp0s3 inet static
address 192.168.1.180
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
dns-nameserver 192.168.1.1

 DHCPサーバーになっているルーターでDHCP固定アドレス割当をすると、個別のマシンはDHCPの設定だけしておけばよい(でも、やったことはない)。

  • Network Manager
     無線LANの場合、古典的な方法ではwpa_supplicantを使うが、wpa_supplicantの設定が面倒。Network ManagerでGUIベースで設定するのが楽。
     但し、ログインしてからでないと、ネットワークに繋がらないので、rebootしたときに不便。変更するなら、有線接続にするか、真面目にwpa_supplicant.confを設定する。

    • ubuntu-mate:「システム」→「設定」→「インターネットとネットワーク」→「ネットワーク接続」→「歯車マーク」→いろいろ設定
    • lubuntu:「タスクバー」→「無線LANアイコン」→「接続を編集する」→SSIDを選択→「歯車マーク」→いろいろ設定

  • /etc/hosts の編集

  • xrdp

    $ sudo apt install xrdp
    $ sudo systemctl enable xrdp
    $ sudo systemctl restart xrdp
    

    • 昔は、日本語キーボード用の設定をする必要があったが、今は不要。
    • Windows側では、マシン名での指定もできたが、不安定。IPアドレスでの指定が安定する。
       これは、nmb (NetBIOS名)の扱いが不安定の模様。たぶん、Windows側の問題。windows側からのping などでも名前を指定では見つからない場合があるが、何回か繰り返すと、動くようになる。別のマシンでも、SMB(samba)によるネットワーク共有フォルダで、見つからない場合がしばしばある。
    • .xsessionの作成
      • lubuntuの場合:
        $ echo "lxsession -s Lubuntu -e LXDE" > ~/.xsession
      • ubuntu-mateの場合(要確認):
        $ echo "gnome-session --session=gnome"  > ~/.xsession
  • ディスク管理

    • gdisk, gparted, gnome-disk-utility
    • ラベルを付ける(e2fsprogs, ntfs-3g)
      • e2label /dev/sda1 labelname
      • ntfslabel /dev/sdb1 labelname

  • rootでログインできるようにする*2

    $ sudo su -
    $ passwd
    Enter new UNIX password:
    Retype new UNIX password:
    passwd: password updated successfully
    

  • デフォールトで使うエディタを設定する
    sudoeditを起動する前に設定しておく。

$ sudo update-alternatives --config editor
There are 4 choices for the alternative editor (providing /usr/bin/editor).

  Selection    Path               Priority   Status
------------------------------------------------------------
  0            /bin/nano           40        auto mode
  1            /bin/ed            -100       manual mode
  2            /bin/nano           40        manual mode
* 3            /usr/bin/emacs25    0         manual mode
  4            /usr/bin/vim.tiny   15        manual mode

Press  to keep the current choice[*], or type selection number: 3
  • 環境変数 LANG *3
LANG=C
LANG=ja_JP.utf8
  • NFS サーバ
$ sudo apt install nfs-kernel-server 

 /etc/exportsで共有するディレクトリを指定する。

/home/tora    *(rw)

 - 必要に応じて、* をクライアント側のマシンのhostnameにする。
 - sync, no_subtree_checkのオプションは、デフォールトなので不要。

 サーバ側でエクスポートする。

$ sudo exportfs -a

 クライアント側でマウントする。

$ sudo mount nfs-server-hostname:/home/tora /mnt/tora

3. 最後に

 気が付いたときに、随時、更新します。

(2018/9/21)

関連記事

サポート外となった17.04のLubuntuを18.04へアップデートした

【概要】
 サポート切れとなった17.04のlubuntuを18.04へアップグレードしました。基本的にはレポジトリの変更だけで、アップグレードできますので、難しい作業ではありませんでした。

1. いつの間にかサポート期限を過ぎていた

 HDD/SSDへの換装に当たって、久しぶりにLubuntuをインストールしたHP miniを起動しました。gdiskを入れていなかったので、apt-getでインストールしようとしたら、既にOSのバージョンが古くて、リポジトリがなくなっていました。

 入れていたOSのバージョンは、lubuntu17.04。LTSでない通常版のサポート期間は、9か月なので、2018年9月時点では、既にサポート対象期限を過ぎています。

 LTS (Long Term Support) は、サポート期間が5年間。たまにしか使わないマシンにはLTS版を入れるべきでした。

2. 17.04から18.04へのバージョンアップ

 以下の記事を参考に、バージョンアップを行いました。

Ubuntu 最新バージョンへのアップグレード - eTuts+ Server Tutorial

 この記事の「次へ進む前に軽く一読 : アップグレード可能と言ってるのに、アップグレードしようとするとアップグレード出来ないと怒られる」の説明と同様に、do-release-upgradeは拒否されました。

 A(17.04)→C(18.04)にバージョンアップしたいのだけど、A(17.04)のdo-release-upgradeは、A→B(17.10)のアップグレードしかサポートしない。だから、いきなり18.04へのアップグレードはできないということのようです。

 この記事の「歯抜け状態でのアップグレード その1. sources.list を書き換えて、A → B → C へ」の説明と同様に、/etc/apt/sources.list を編集することで、A(17.04) から B(17.10) に dist-upgrade したうえで、B(17.10) からC(18.04) に do-release-upgrade しました。

 具体的な作業は以下の通りです。

  • /etc/apt/sources.listを編集する。
    • "zesty"(17.04)をすべて "artful"(17.10) に置き換える。
  • sudo dist-upgrade を実行する。
    • この時点でリリースは、17.10となる
  • sudo do-release-upgrade を実行する
    • この結果、18.04になる
  • sudo reboot

 以上で、18.04へのアップグレードは完了です。レポジトリの変更だけで解決しました。

3. 最後に

 あまり使わないマシンにはLTS版を入れるべし。

(2018/9/20)

関連記事

付録:zestyをartfulに書換え後の/etc/apt/sources.list

 zestyをartfulに機械的に置き換えて構いません。

# deb cdrom:[Lubuntu 17.04 _Zesty Zapus_ - Release i386 (20170412)]/ zesty main multiverse restricted universe

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://archive.ubuntu.com/ubuntu artful main restricted
# deb-src http://jp.archive.ubuntu.com/ubuntu/ artful main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://archive.ubuntu.com/ubuntu artful-updates main restricted
# deb-src http://jp.archive.ubuntu.com/ubuntu/ artful-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://archive.ubuntu.com/ubuntu artful universe
# deb-src http://jp.archive.ubuntu.com/ubuntu/ artful universe
deb http://archive.ubuntu.com/ubuntu artful-updates universe
# deb-src http://jp.archive.ubuntu.com/ubuntu/ artful-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu 
## team, and may not be under a free licence. Please satisfy yourself as to 
## your rights to use the software. Also, please note that software in 
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://archive.ubuntu.com/ubuntu artful multiverse
# deb-src http://jp.archive.ubuntu.com/ubuntu/ artful multiverse
deb http://archive.ubuntu.com/ubuntu artful-updates multiverse
# deb-src http://jp.archive.ubuntu.com/ubuntu/ artful-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://archive.ubuntu.com/ubuntu artful-backports main restricted universe multiverse
# deb-src http://jp.archive.ubuntu.com/ubuntu/ artful-backports main restricted universe multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu artful partner
# deb-src http://archive.canonical.com/ubuntu artful partner

deb http://archive.ubuntu.com/ubuntu artful-security main restricted
# deb-src http://security.ubuntu.com/ubuntu artful-security main restricted
deb http://archive.ubuntu.com/ubuntu artful-security universe
# deb-src http://security.ubuntu.com/ubuntu artful-security universe
deb http://archive.ubuntu.com/ubuntu artful-security multiverse
# deb-src http://security.ubuntu.com/ubuntu artful-security multiverse

http://archive.ubuntu.com でファイルが見つからない場合には、http://old-releases.ubuntu.com に変更すれば、更新できると思います。

 なお、ダウンロード元は「日本のサーバー」にしていましたが、「メインサーバー」に切り替えて作業しました。

f:id:toranosuke_blog:20180826212245p:plain:w500
日本のサーバーでもできるかは、よく分かりません。

Dynabook AZ77のSSDへの換装 (5) gpartedでパーティションをいろいろリサイズした

【概要】 ddで作ったクローンディスクのWindowsのシステムパーティションをgpartedを使ってリサイズし、Windowsの正常動作を確認しました。gpartedでは、ファイルシステムにエラーがある場合でも、それをチェックして、修正を促してくれます。GUIベースの便利なツールです。

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でみるパーティション構成は、下図のようになりました。

f:id:toranosuke_blog:20180917090152p:plain
500GB の SSD のパーティション構成(gnome-disks)

f:id:toranosuke_blog:20180917090210p:plain
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 が未割り当てとして正常に認識されています。

f:id:toranosuke_blog:20180918105522p:plain
未割り当て領域は 1.4TiB。

 また、「イベントビューアー」にディスク構成の変更が記録されています。

f:id:toranosuke_blog:20180919100826p:plain
 デバイスが異なると、警告あり。

 イベントビューアーには、警告があります。今回のデバイス (シーゲートのHN-M201RAD) は、前回のデバイス (SamsungのSSD 860) と異なっているためです。この違いが、他の動作に影響を与えているか、不明ですが、今のところ、不具合はなさそうです。

 Windows 上の gdisk を使って、GPT テーブルの比較をしましたが、ディスクのモデル名を除き、Linux 上の結果と一致しました。

3. 縮小クローン

 次に同じディスクを用いて、縮小クローンを作成しました。Windows OSが入っている約450GBのNTFSのパーティションを390GBに縮小します。

3.1 gpartedによるパーティション構成の変更

 gpartedを起動し、GUIに従って、Windowsシステムが入っているパーティション3を約450GBから約390GBに縮小しました。それ以外のパーティションは変更せず、パーティション4、5については、ディスクの先頭方向(gparted画面の左方向)に移動させて、パーティション3を縮小してできた隙間を埋めます。

 処理時間は20分程度で、特に問題は発生しませんでした。gdiskでみたパーティション情報にも、特に問題はありませんでした。

$ gparted /dev/sdT

f:id:toranosuke_blog:20180919110056p:plain
変更前のパーティション構成。パーティション3は、452GB。

f:id:toranosuke_blog:20180919104524p:plain
パーティション3を452GBから390GBに縮小。

 但し、パーティション4、パーティション5は、パーティションタイプが「Microsoft Windows回復環境(システム)」(gnome-disks)であり、このパーティションを移動させようとすると、gparted は次の警告を与えます。ちょっと心配になります。

f:id:toranosuke_blog:20180919110851p:plain:w450
システム領域を変更しようとすると、起動の失敗の可能性ありと警告。

3.2 dynabookに内蔵して動作確認

 dynabook の内蔵ディスクを 2TB の縮小クローンディスクに入れ替え、Win10 を起動しましたが、特に問題ありませんでした。

f:id:toranosuke_blog:20180919111947p:plain
パーティション3は、390GBに縮小され、1460GBの未割り当て領域ができる。

 この段階の縮小クローンのディスクサイズは 2TB ですが、これを小さなディスクに、ddコピーし、gdiskでGPTテーブルを修復すれば、本当の縮小クローンの完成です。これについては、適当なディスクが手元になかったので、未検証ですが、たぶん、問題なく動作すると思います。

3.3 あっ、電源が!

 dynabook をちょっと動かしたときに電源が落ちてしまいました!AC電源を使っていたつもりだったのですが、電気が来ておらず、バッテリーだけで動作させている状態でした。バッテリーも、裏ブタをしっかりと閉めずにいたので、動かしたときに接点が外れたのでしょう。突然の電源オフです。

 この突然の不正シャットダウンでファイルシステムを壊したらしく、その後、アカウントにサインインできなくなりました。

f:id:toranosuke_blog:20180919112916p:plain
アカウントにサインインできない!

 マイクロソフトのホームページ*2に従って、ファイルシステムチェッカー*3を実行しましたが、復旧せず、諦めました。

f:id:toranosuke_blog:20180919113511p:plain
ファイルシステムチェッカーの実行。

 このことが、その後、パーティション拡大時のエラーの原因となります。

4. 拡大クローン

 次に同じディスクで、未割り当て領域の 1.4TiB をパーティション3 (Windows領域) に割り当てます。

4.1 gpartedによるパーティション構成の変更

 パーティション4、5を末尾に移動し、パーティション3を拡大します。

f:id:toranosuke_blog:20180919114257p:plain
変更予定のパーティション構成。

f:id:toranosuke_blog:20180919114359p:plain
パーティションp4, p5を右に移動し、p3 を拡大、その後、p4, p5を左に移動。

 パーティション4、5を右に移動し、パーティション3とパーティション4の間に1.4TiBの空きを作り、その空き領域を使って、パーティション3を拡大します。その後、パーティション3とパーティション4の間にできた1MiB程度の隙間を埋めるために、パーティション4,5を左に移動するようにしました。(アライメント調整の影響ですが、gpartedでは、なぜか、隙間ができたり、できなかったりします)

4.2 gpartedでエラーが発生!

 パーティション構成変更の実行中にエラーが発生しました。

f:id:toranosuke_blog:20180919115155p:plain:w400
エラー発生!

 詳細情報を見ると、ファイルシステムのエラーチェックで、エラーを検知して、処理を中断したようです。おそらく、前述した不意の電源断でファイルシステムを破壊したのだと思います。

f:id:toranosuke_blog:20180919115358p:plain
ファイルシステムのエラーチェックで処理を中断。

 エラーメッセージにあるように、Windowsで、chkdsk /f を行いました。2回行うことを指示していますが、再起動だけ2回なのか、chkdskも含めて2回なのか良く分からなかったので、「chkdsk→再起動→chkdsk→再起動→完全シャットダウン」と処理しました。

 その後、拡大処理から再開し、無事、パーティション3の拡大処理を完了しました。

f:id:toranosuke_blog:20180919120333p:plain
chkdsk後のパーティション構成。

f:id:toranosuke_blog:20180919120421p:plain
拡大処理後のパーティション構成。パーティション3が1.8TiBに拡大。

 今度のパーティション構成では、ディスク末尾の空き領域はなくなっていますが、gparted のアライメント調整の影響です。アライメント調整の制限を加えると、gparted では、隙間ができたり、できなかったりします。原因は不明です。

4.3 dynabookに内蔵して動作確認

 拡大クローンを dynabook に入れて、動作確認しましたが、サインインできない問題を除けば、問題なく動作しました。サインインの問題は、パーティションのリサイズが原因ではなく、不意の電源断が原因です。

f:id:toranosuke_blog:20180919121848p:plain
パーティション3は、1.8TiBと大きくなっている。

5. 最後に

 gpartedを使って、パーティションのリサイズ・移動を行いました。gpartedによってリサイズしても今のことろ動作には問題はないようです。

 WindowsのOSが入っているシステム領域のリサイズ・移動や、ハードウェアの変更によって、Windowsが起動できなくなると危惧していましたが、(突然の電源断がなければ)案外、簡単にクローンディスクを作れることが分かりました。

 但し、今回はパーティション1のEFIシステムや、パーティション2のMicrosoft予約領域については、一切、移動・リサイズを行っていません。パーティション4やパーティション5のWindowsの回復環境についても、移動はしましたが、リサイズは行っていません。

 おそらく、パーティション1やパーティション2のリサイズ・移動を行うと、Windowsの起動で問題が発生すると思っています。

(2018/9/19)

関連記事

付録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) - 虎之助の徒然記
f:id:toranosuke_blog:20180919220601p:plain
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 結論:玄人志向・センチュリーはディスクサイズを1セクタ小さく誤認識する

 ”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の内蔵ディスクのドライバが1つ多く間違って認識しているという可能性もあります。しかし、今回の場合は、dynabookの内蔵ディスクのドライバと同様にディスクサイズを認識する必要があるので、dynabookと一致する場合が「正しい」と考えることにします。また、この動作は、Linux上での動作であって、Windows上では異なった動作をするのかもしれません。

クローンディスクの作り方 (1) Linuxの場合

【概要】
 Linuxを用いたクローンディスクの作り方について説明します。ディスククローンには、dd、gdisk、gpartedの3つのコマンドを用います。それぞれの使い方や注意事項についてまとめます。

1. はじめに

 容量拡大のためにディスクのクローンを作成したり、SSD換装のために容量が小さなクローンディスクを作成したい場合があります。本稿では、これらをLinuxを用いて実現する方法について説明します。

2. クローンディスクの作成

 クローンディスクの作成には、主に次の3つのケースがあります。

  • ミラーリング:ディスクパーティションの大きさを変更せずにコピーする。
  • 拡張:サイズが大きなディスクに移し替える。
  • 縮小:サイズが小さなディスクに移し替える。

 それぞれのケースのクローンの作成について説明します。

 記事では、次のデバイス名を使っています。

  • /dev/sdS:オリジナルのディスク
  • /dev/sdT:クローン化するターゲットディスク
  • /dev/sdW:作業用のディスク

 マシン環境に合わせて、適宜、/dev/sdbや/dev/sdcと読み替えてください。

 なお、この記事は、パーティションテーブルは GPT (GUID Partion Table) で作成されていることを前提としてます。

3. 事前準備

3.1 必要なツールのインストール

3.1.1 dd、gdisk、gparted、ntfs-3gなど

$ apt install gdisk gparted ntfs-3g coreutils

 実際に、検証を行った Linux は Ubuntu18.04 です。aptを使う Debian 系のOSであれば、ほとんど同じパッケージ名でインストールできると思います。

 また、dd や shred が入っている coreutils はインストール済のはずですので通常は指定不要です。gdisk、ntfs-3g、gpartedなども、他のパッケージと同時にインストールされる場合があります。

3.1.2 gnome-disks

 必須ではありませんが、gnome-disk-utilityパッケージの中の gnome-disks もパーティションや SMART の情報などを見ることができて、ディスク管理に便利なコマンドです。

$ apt install gnome-disk-utility

3.1.3 parted

 partedでもパーティションテーブルを編集できますが、基本的には用いません。但し、パーティションテーブルの種類を調べるには、gdisk よりも parted の方が分かりやすいです。

$ apt install parted

 例えば、次のオプションでパーティションの種類を確認できます。

$ parted -l

あるいは

$ fdisk -l

「Partition Table」が「gpt」であれば GPT(GUIDパーティションテーブル)、「msdos」であれば MBR(マスターブートレコード)です。

 Windowsの場合、「ディスクの管理」 からディスクのプロパティを開き、「ボリューム」タブの「パーティションのスタイル」が「GUIDパーティションテーブル(GPT)」であることを確認します。MBRの場合には「マスターブートレコード(MBR)」と表示されます。

3.1.4 sudo について

 パッケージのインストールはroot権限が必要なので、sudo apt .... と sudo をつけて実行するか、rootにログインして実行します。ubuntu 系のOSではデフォールトではrootにはログインできないようになっているので、sudo を使うことが一般的です。

3.2 Windowsのシャットダウン

  • Windowsのディスクは、完全シャットダウンを行うこと*1

 完全シャットダウンをしていないntfsパーティションをLinuxではリサイズを行うことはできません。マウントもリードオンリーです。

 Windowsシステムが入ったディスクでも、外付けディスクとして別のWindowsマシンに接続して、完全シャットダウンしても大丈夫です。

3.3 ディスクの初期化

 今回の方法は、簡単な方法ですが、ある意味、乱暴な方法です。なぜなら、ディスクの末尾のパーティションテーブルを正しく取り扱っていません。

 ディスクに残った以前のGPTテーブルが悪さをするかもしれません。このため、ターゲットディスク・作業用ディスクを完全に初期化しておいた方が安心です(たぶん、不必要とは思いますが、ディスクを使いまわすときの習慣でいつもshredしているので、念のため書いておきます)。

$ shred -v -z -n 0 /dev/sdT /dev/sdW

 このコマンドで、ディスクの全セクタを0値に初期化します(非常に時間がかかります。2TBで丸一日ぐらい)。

3.4 本稿検証のためのデータの作成

 本稿で用いた方法は、loopデバイスを用いて検証しています。この検証のためのデータは、次のように作成しています。

  • 予め0値で埋まったファイルを作成し、loopデバイスと紐づけする。
     loopデバイスの使い方は、以前の記事
  • ファイルサイズは、以下の通り(1 MiB=1024x1024 bytes)。
    • sdS, sdW:100MiB
    • sdT1:80MiB
    • sdT2:100MiB
    • sdT3:120MiB
  • sdSのファイルシステムとパーティションサイズ:
    • part1:FAT16(30MiB)
      • FAT16としたのは、容量が小さすぎて、FAT32では作成できなかったため。
    • part2:NTFS(30MiB)
    • part3:ext4(30MiB)
    • 未割り当て(10MiB)
  • sdSに収めるデータ。
     ファイルがある領域とない領域が交互に現れるようにファイルを作成。
    • ① 未使用領域と同じサイズの乱数を書き込んだファイルを作成、直ぐに削除する。
      $ dd if=/dev/zero of=tmpfile ; shred -v -n 1 tmpfile ; rm tmpfile
      
    • ② 異なる乱数の1MiBのファイルで、ファイルシステムを満たす。
    • ③ 1, 3, 5,..., 17, 19番目の 10個のファイルの(10MiB)を残し、それ以外は削除する。

4. ミラーリングする場合

 パーティションサイズを変更せず、そのままの構成を保つ場合です。

4.1 同一サイズのディスクへコピーする場合

 オリジナルのディスクと全く同一のセクター数を持つディスクを使う場合です。

① ターゲットディスクへのコピー

 ddコマンドを用いてディスクをコピーします。これで終了です。

$ dd if=/dev/sdS of=/dev/sdT

 但し、例えば、同じ1TBのディスクといっても、セクタ数が同じとは限りません(違うと思っていた方がよいです)。

 同じブランド、同じ型番の商品を同時期に購入すれば、一致する可能性は高いですが、それでも、異なることがあるかもしれません。

4.2 大きなディスクへコピーする場合

 オリジナルのディスクよりも大きいセクター数を持つディスクへコピーする場合です。余分なセクタは使用せず、未割り当てのままとします。

① ターゲットディスクへのコピー

$ dd if=/dev/sdS of=/dev/sdT

② ターゲットディスクのGPTテーブルの修正

 GPTテーブルでは、第2GPTテーブル(バックアップGPTテーブルともいう。内容は第1GPTテーブルと同一)がディスク末尾のセクタに配置されなければなりません。そのため、ddでコピーしたそのままの状態では ターゲットディスク は、GPTテーブルの仕様に準拠しません。

● この状態で、gnome-disksでディスクを見ると、余分なセクタ部分が見えない状態となっています。余分なセクタ部分を未割り当てのままとして使用しないのなら、修正する必要はないのかもしれません。
● gpartedでは、GPTテーブルの位置不正を自動的に検知します。また、修正することも可能です。

 この問題を修正するために、gdiskを用いて、次のように第2GPTテーブルをディスク末尾に移動させます。

$ gdisk /dev/sdT 
Command (? for help): b              (GPTテーブルのバックアップを作成)
Enter backup filename to save: gpt-backup.dat 
Command (? for help): x              (Expertメニューに入る)
Expert command (? for help):  e      (第2GPTテーブルをディスク末尾に移動)
Expert command (? for help):  w      (変更したテーブルをディスクに書き込む)
$ partprobe /dev/sdT

 gdsikでは、GPTテーブルを新規に作り直したり、パーティションを作成・削除できます。しかし、これらの操作を行ってはなりません。なぜなら、これらの操作は、ディスクやパーティションにつけられたGUID/UUIDを変更してしまうからです。

 GUID/UUIDを変更すると、ディスク内のシステムがGUID/UUIDを参照していれば、問題が発生する可能性があります。例えば、Linuxでは、 /etc/fstab のディスクマウント定義でUUIDを用いることがあります。この場合、UUIDを変更すれば、対象のパーティションはマウントされなくなります。

 また、起動に関連するファイルシステムは、リサイズ・移動をしない方がよいでしょう。Linuxの場合、grubが起動イメージの配置をセクタで管理しています。パーティションをリサイズ・移動した場合には、起動イメージの配置されるセクタが変更される可能性があります。この場合、(LiveUSBなどを使って)grub コンフィギュレーションを修正します。

gdiskの使用上の注意事項

  • 作業の最初に、必ず、GPTテーブルのバックアップを取ること。
  • こまめに "p"(テーブルの表示)、"v"(検証)を行い、状況を把握すること。
  • オリジナルディスクとターゲットディスクのパーティションの一致を確認すること。
  • コマンドw(GPTテーブルをディスクへ書込んで終了)は、慎重に。
  • パーティション変更後は、partprobeを実行すること。

5. ディスクを拡張する場合

 サイズが大きなディスクに移し替える場合です。この場合、GPTテーブルの修正に加えて、パーティションの移動・拡大を行う必要があります。

① ターゲットディスクへのコピー

$ dd if=/dev/sdS of=/dev/sdT

② ターゲットディスクのGPTテーブルの修正

 ミラーリングの場合と同様に、gdiskで第2GPTテーブルをディスク末尾に配置します。

$ gdisk /dev/sdT 
Command (? for help): x              (Expertメニューに入る)
Expert command (? for help):  e      (第2GPTテーブルをディスク末尾に移動)
Expert command (? for help):  w      (変更したテーブルをディスクに書き込む)
$ partprobe /dev/sdT

③ ターゲットディスクのパーティションの拡大

 gpartedを用いて、パーティションの拡大を行います。

 今回は、それぞれ30MiBのfat16、ntfs、ext4のパーティションサイズを10MiB増加させて、40MiBにします。

  • gpartedを起動する
$ gparted /dev/sdT 
f:id:toranosuke_blog:20180912175236p:plain
当初のパーティション構成。ターゲットのデバイス名は/dev/loop1。

  • ディスクの末尾側のパーティション(/dev/loop1p3)をリサイズ・移動を指定する。

 「パーティション(P)」→「リサイズ/移動(R)」を選択し、前後の空き領域やサイズを指定し、「リサイズ/移動」をクリックする。

f:id:toranosuke_blog:20180912181845p:plain
前後の空き領域・サイズを指定する。

f:id:toranosuke_blog:20180912182253p:plain:w400
ブートに失敗するかもね、と警告される。

f:id:toranosuke_blog:20180912182807p:plain

 前方に19MB、後方に1MBの空き領域ができ、サイズも19MBとなる。これは、2048セクタ(=2048x512=1MiB)単位のアライメント調整を行っているため *2。リサイズパラメータの指定画面で「位置合わせ」を「なし」とすると、後方の空き領域をなくすことができる。

  • 同様に、ntfs、fat16の領域もリサイズ・移動の指定を行う。
f:id:toranosuke_blog:20180912184231p:plain

 パーティション間に隙間ができてしまった。ちゃんとリサイズ・アライメントすれば、パーティション間には隙間はできないはずだが、なぜか今回は隙間ができた。

f:id:toranosuke_blog:20180912190535p:plain
アライメント調整をなしにして、隙間を埋めた。

  • リサイズ・移動を実行する。

 「編集(E)」→「保留中の全ての操作を適用する(A)」をクリックして、リサイズ・縮小処理を実行します。

  今回の設定での検証実験では、ext4のパーティションの拡大に失敗し、エラーが発生しています。

f:id:toranosuke_blog:20180912203929p:plain:w300
エラーを知らせるポップアップ。

f:id:toranosuke_blog:20180912203935p:plain:w400
末尾のパーティションext4の拡大でエラーが発生。

 末尾のパーティション(ext4)の拡大に失敗していますが、それ以外は問題ありません。この失敗も、パーティションの拡大がディスク末尾の第2GPTテーブルを上書きする不正な要求だったためです。エラー判定されますが、チェック段階で不正と判定されているため、最後の処理は実行されていません。
  • 拡大後のパーティション構成

 最初のパーティション(fat16)と最後のパーティション(ext4)が1MiB足りず、計2MiB足りませんが、それぞれ、第1GPTテーブル、第2GPTテーブルが配置されている領域にはパーティションが拡張できないためです。

f:id:toranosuke_blog:20180912210716p:plain
リサイズ・移動後の最終的なパーティション構成。

  • 拡大前後のパーティション構成の詳細

 パーティションの拡大前後におけるgdiskのパーティション情報は、以下の通りです。

(拡大する前)
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048           63487   30.0 MiB    0700  Microsoft basic data
   2           63488          124927   30.0 MiB    0700  Microsoft basic data
   3          124928          186367   30.0 MiB    8300  Linux filesystem

(拡大した後)
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048           81919   39.0 MiB    0700  Microsoft basic data
   2           81920          163839   40.0 MiB    0700  Microsoft basic data
   3          163840          243711   39.0 MiB    8300  Linux filesystem
  • ディスク内容の確認

 ディスクの内容を確認します。今回は、それぞれのパーティションに入れた10個のファイル(乱数を書き込んだ1MiBのファイル)について、cmpやdiffコマンドを用いてバイナリーレベルで一致を確認しました。

6. ディスクを縮小する場合

 サイズが小さなディスクに移し替える場合です。

 オリジナルディスクの使用量は、ターゲットディスクよりも小さくなければならないことは言うまでもありませんが、ディスクパーティションも小さくしておく必要があります。

 このディスクパーティションの縮小には、初めにオリジナルディスクで行う場合と作業ディスクで行う場合とがあります。

 前者であれば、作業ディスクは不要です。

6.1 オリジナルディスクのパーティションを縮小する場合

 作業の開始前に、必ずオリジナルディスクのバックアップを取っておきます。

① オリジナルディスクのパーティションの縮小・移動

 ディスク拡大の場合と同様に、gpartedを用いてパーティションを縮小します。

 ここでは、それぞれのパーティションを20MiBに縮小し計80MiBにしようと思いましたが、gpartedはfat16の縮小には対応してなかったので*3、ntfs、ext4のパーティションのみを20MBに縮小します。なお、fat32であれば、縮小にも対応しています。

$ gparted /dev/sdS
f:id:toranosuke_blog:20180913125553p:plain
縮小後のオリジナルディスクのパーティション。

注意事項:  第2GPTテーブルをディスク末尾に配置しますので、ターゲットディスクの末尾に少なくとも1MiBの未割り当ての領域を確保しておく必要があります。

Windowsの場合
 Windowsの機能を用いて、パーティションのリサイズができます。

● 「アプリ」→「Windows管理ツール」→「コンピュータの管理」→「記憶域」→「ディスクの管理」

 具体的な操作方法は、例えば、次の記事に解説があります。

[FAQ番号:027519]Cドライブのサイズを変更(拡張/縮小)する方法(Windows 7 / Windows 8 / Windows 8.1)|FAQ Search|エプソンダイレクト

 実際には、「ディスクの管理」では、空きがあるにも関わらず、縮小できない場合があるようです*4

② ターゲットディスクへのコピー

 オリジナルディスクをターゲットディスクへコピーします。

$ dd if=/dev/sdS of=/dev/sdT
dd: writing to '/dev/sdT': No space left on device
163841+0 records in
163840+0 records out
83886080 bytes (84 MB, 80 MiB) copied, 3.93326 s, 21.3 MB/s

 ターゲットディスクよりも大きい部分のデータはコピーされません。ターゲットディスクが小さくて入りきらかなかったので、"No space left on device" のメッセージとともに、ddは終了します。

③ ターゲットディスクのGPTテーブルの修正

 ミラーリングの場合と同様に、gdiskで第2GPTテーブルをディスク末尾に配置します。

$ gdisk /dev/sdT
Command (? for help): x              (Expertメニューに入る)
Expert command (? for help):  e      (第2GPTテーブルをディスク末尾に移動)
Expert command (? for help):  w      (変更したテーブルをディスクに書き込む)
$ partprobe /dev/sdT

 これは、前述したgdiskによるGPTテーブルの末尾への移動の場合と同じコマンドです。しかし、今回は、第2GPTテーブルが存在しないため、ディスク末尾に新たに第2GPTテーブルが作成されます。

 また、gdiskコマンド実行中に、ディスクサイズが小さい、第2GPTテーブルが破壊されている等の警告メッセージが現れます。

f:id:toranosuke_blog:20180913140904p:plain
クローンでの最終的なパーティション構成。この例では、80MiBのディスクへ縮小。

④ ディスク内容の確認

 mountを行い、オリジナルディスクの内容とターゲットディスクの内容が一致するか、例えば、cmpコマンドやdiffコマンドを用いて確認します。

6.2 作業ディスクでパーティションを縮小する場合

 オリジナルディスクを作業ディスクにコピー後、作業ディスクのパーティションを縮小、ターゲットディスクに書き込みます。

① 作業ディスクへのコピー

 オリジナルディスクを作業ディスクにコピーします。

$ dd if=/dev/sdS of=/dev/sdW

② 作業ディスクのGPTテーブルの修正

 gdiskを用いて作業ディスクの第2GPTテーブルをディスク末尾に配置します。

$ gdisk /dev/sdW
Command (? for help): x              (Expertメニューに入る)
Expert command (? for help):  e      (第2GPTテーブルをディスク末尾に移動)
Expert command (? for help):  w      (変更したテーブルをディスクに書き込む)
$ partprobe /dev/sdW

③ 作業ディスクのパーティションの縮小・移動

 gpartedを用いて前述と同様に作業ディスクのパーティションを縮小・移動します。

 ターゲットディスクの末尾に少なくとも1MiBの未割り当ての領域できるように作業ディスクの末尾の未割り当て領域を調整します。

gparted /dev/sdW

④ 作業ディスクの内容をターゲットディスクにコピー

ddによって作業ディスクの内容をターゲットディスクにコピーします。

$ dd if=/dev/sdW of=/dev/sdT

 作業ディスクよりもターゲットディスクの容量が小さいので、警告メッセージがでますが、意図通りの動作です。

⑤ ターゲットディスクのGPTテーブルの修正

 gdiskでコマンドeを実行すると、ディスク末尾に第2GPTテーブルが新規に作成されます。

$ gdisk /dev/sdT
Command (? for help): x              (Expertメニューに入る)
Expert command (? for help):  e      (第2GPTテーブルをディスク末尾に移動)
Expert command (? for help):  w      (変更したテーブルをディスクに書き込む)
$ partprobe /dev/sdT

⑥ ディスク内容の確認

 mountを行い、オリジナルディスクの内容とターゲットディスクの内容が一致するか、例えば、cmpコマンドやdiffコマンドを用いて確認します。

7. まとめ

 今回は、Linuxにおけるクローンディスクの作り方について、リサイズする場合も含めて説明しました。今回説明した方法で、データが一致することは確認できました。

 しかし、この方法では、次のような点が原因となって不具合が発生するかもしれません。

  • 直接セクター配置によってアクセスするプログラムがある場合。
     特にブートに関連するプログラムには、このようなプログラムがあります。このため、システムディスクの起動関連のパーティションについては、リサイズ・移動をしない方が安心です。
  • ディスクのハードディスク情報を用いて動作している場合
     システムは、ハードディスクのシリンダー数やヘッド数、SSDなどの情報を用いています。これらの情報が誤っていれば、システムの動作に影響を与えるかもしれません。
  • ハードディスクにセキュリティ対策が施されている場合
     ハードウェアレベルでディスクに暗号化がかかっているのであれば、ディスクの中身を知ることはできませんので、パーティション変更等はできません。ミラーリングなどもできないようにセキュリティ保護される場合もあると思います。また、クローンディスクができたとしても、セキュアブートの設定を変更する必要があるかもしれません。

 システムディスクの場合、様々なトラブルに見舞われる可能性がありますので、オリジナルのディスクはそのままの状態で一切変更を加えずに、丸ごとコピーしたディスクをオリジナルディスクと見立てて、作業するとよいと思います。

(2018/9/13)

関連記事

*1:完全シャットダウンは、Shiftキー+「シャットダウン」をクリック、あるいは、"shutdown /s /t 0"

*2:gdiskでアライメント単位を変更することができるようなので、それを変更すれば、gpartedのアライメントの単位も変わるのかもしれません(未確認)。

*3:gpartedがサポートしているファイルシステムは、「表示」→「サポートするファイルシステム(F)」から確認できます。これによれば、fat16の縮小にも対応しているはずですが、一定以上のファイルサイズであることなどの条件があるのかもしれません。

*4:https://www.disk-partition.com/jp/articles/unable-to-shrink-c-drive.html

Dynabook AZ77のSSDへの換装 (4) NTFSには完全シャットダウンが必須

【概要】1TBのHDDの内容を500GBのSSDに縮小して入れようと思っています。そこで、まずはWindowsのシステムディスクをLinuxのgpartedコマンドを用いて、パーティションのリサイズを試みました。しかし、LinuxでWindowsのディスクをリサイズするためには、ハイバネーションの関係で、Windowsマシンを完全シャットダウンする必要があることが分かりました。

1. はじめに

 dynabookから取り出した1TBの内蔵ハードディスクの内容を500GBのSSDへコピーします。但し、1TBのハードディスクの内容を500GBに収めようとするのですから、使用するパーティションを縮小し、全体で500GB以下にする必要があります。

 この記事では、Linuxのgpartedを用いて、パーティション領域を縮小しようとして、つまずいたことについてまとめています。

2. 完全シャットダウンなしにLinuxでのリサイズは不可

 当然のことですが、1TBのハードディスクの使用領域は500GB以下でないと、パーティションを500GB以下に収めることはできません。今回のディスクの使用量は、400GB程度なので、うまくリサイズできれば、500GBのSSDに収まるはずです。

 Linuxのgpartedコマンドを使うと、パーティションの縮小・拡大・移動ができます。

 しかし、結論を先に言うと、Linuxのgpartedでは、少なくともWindowsでのシャットダウン時に完全シャットダウンしていないと、パーティションのリサイズはできません。

 まずは、完全シャットダウンを行うこと*1が必要でした。

3. gpartedでパーティションのリサイズ

3.1 gpartedを起動

 Linuxの場合、gpartedを使うとパーティションのリサイズを行うことができます。但し、今回、対象とするディスクは、ddでダンプしたファイルをloopデバイスを用いて認識させたものです(詳しくは、前の記事)。

 gpartedを起動すると、Windowsシステムの入っているパーティション(loop0p3)にオレンジ色の警告マークが示されます。また、詳細情報で操作ができない場合があると指摘され、実際、リサイズ・移動はできません。

$ gparted /dev/loop0
f:id:toranosuke_blog:20180909115759p:plain
Windowsのシステム領域(loop0p3)に警告マーク。

f:id:toranosuke_blog:20180905184804p:plain:w400
/dev/loop0p3 のパーティション情報。ntfs-3gはインストール済。

 そこで、対象のloop0p3をマウントしてみます。

$ mount -t ntfs /dev/loop0p3 /mnt/tmp1
$ gparted /dev/loop0

 すると、オレンジ色の警告マークが鍵マークに変わりました。この状態でもパーティションのリサイズ・移動はできません。

f:id:toranosuke_blog:20180905184615p:plain
mountした場合。/dev/loop0p3にはロックがかかり、リサイズ・移動できない。
ディスクの使用容量を黄色で表示。

3.2 読取専用マウントしかできない

 gparted の起動の前に、縮小対象となるパーティション /dev/loop0p3 をマウントしていますが、次の警告メッセージがでて、リードオンリー(読込専用)でマウントされます。

$ mount -t ntfs /dev/loop0p3 /mnt/tmp1/
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Falling back to read-only mount because the NTFS partition is in an
unsafe state. Please resume and shutdown Windows fully (no hibernation
or fast restarting.)

 読込専用でマウントされるので、gpartedでリサイズできないのも、もっともな話です。mountの警告メッセージからすると、対象ディスクは、予め完全シャットダウンをしておく必要があったようです。

 mount.ntfsのremove_hiberfileオプションを使って、hibernationのためのファイルを強制的に削除して、マウントすることを試みましたが、拒否されてできませんでした。

$ mount -t ntfs -o remove_hiberfile /dev/loop0p3 /mnt/tmp1/
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Failed to mount '/dev/loop0p3': 許可されていない操作です
The NTFS partition is in an unsafe state. Please resume and shutdown
Windows fully (no hibernation or fast restarting), or mount the volume
read-only with the 'ro' mount option.
  • remove_hiberfile オプションの説明
$ man mount.ntfs
NAME
     ntfs-3g - Third Generation Read/Write NTFS Driver

SYNOPSIS
     mount -t ntfs-3g [-o option[,...]]  volume mount_point
  
 OPTIONS
     remove_hiberfile
         When the NTFS volume is hibernated, a read-write mount is denied
         and a read-only mount is forced. One needs either to resume Win‐
         dows  and  shutdown  it  properly, or use this option which will
         remove the Windows hibernation file.  Please  note,  this  means
         that the saved Windows session will be completely lost. Use this
         option under your own responsibility.

4. 完全シャットダウンが必要だった

4.1 ハイバネーションが悪さする

 mountコマンドのエラーメッセージやコマンド説明にあるように、完全シャットダウンしない場合、LinuxではNTFSディスクへの処理は、mountもgpartedも読込処理に限定されていました。ハイバネーションの影響です。

 Linux上でもNTFSパーティションのリサイズはできますが、少なくとも、次を行わなければならないことが分かりました。

  • Windowsで完全シャットダウンをしなければならない

 ハイバネーションは、メモリ上に展開したファイルをディスク上へ退避する仕組み。完全シャットダウンしないとLinuxでは手に負えないため、処理は読取に限定しているということですね。

4.2 完全シャットダウンは外付けディスクで構わない

 後から気が付いたのですが、別のWindowsマシンに外付けディスクとして繋げて、そのマシンを完全シャットダウンしても、構いません。

 これならば、瀕死のHDDでWindowsを起動する必要はありません(瀕死のHDDはシャットダウンもできない状態だった)。

 実際、瀕死のHDDでも試しましたが、外付けディスクとしての完全シャットダウンは、ごく僅かなHDDへのアクセスだけで、短時間で終わります。mountコマンドによるマウントも読取専用ではなく、読み書き可能な状態でマウントができました。

5. 最後に

 完全シャットダウンを行えば、gpartedでも、パーティションの縮小はできそうです。

 しかし、瀕死のHDDを、再度、一週間近くかけて、ddダンプをする気にはなれなかったので、やり直しませんでした。今回は、アプリ丸ごと復旧させることは諦め、リカバリーディスクからクリアインストールすることにしました。

 ディスクイメージを縮小する試みは失敗しましたが、エクスプローラーでコピーしたバックアップやddダンプしたディスクイメージからデータを復旧できたので、一応はよしとしました。

 但し、クリアインストールしたディスクも、その後、いろいろやってお釈迦にして、2度目のクリアインストールをする羽目にはなったのですが...(付録参照)。

 Linuxで再挑戦したWIndowsの丸ごとコピー・リサイズについては次の記事でまとめます。

(2018/9/9)

関連記事

付録A:Windowsディスクの丸ごとddコピーで起動できるか?

A.1 セーフモードで起動できた!

 WindowsをクリアインストールしたディスクをddでHDDにコピーし、そのHDDから起動できるか確認しました。

 まずは、Ubuntu18.04のLiveUSBを作り、LiveUSBからdynabookを起動、内蔵ディスク(SSD)を外付けの2TBのHDDへddコピーしました。

$ dd if=/dev/sda of=/dev/sdc
   (内蔵SSD)→(外付けHDD)

 ddコピーした外付けディスクからWindowsを起動すると、、、正常起動できません。

 そうは言っても、セーフモードでは起動できました。

f:id:toranosuke_blog:20180906142939j:plain:w300f:id:toranosuke_blog:20180906142953j:plain:w300
f:id:toranosuke_blog:20180906143205j:plain:w300f:id:toranosuke_blog:20180906143236j:plain:w300
セーフモードなら、起動できた!

A.2 内蔵ディスクからWindowsが起動できなくなった!

 HDDから正常起動できるように、いろいろと設定を変えていたら、内蔵ディスクからの起動もできなくなってしまいました(冷汗)。

 Windowsのbcdbootコマンド(Microsoftの解説はここ)が原因ではないかと思います。

 Windowsの起動設定を破壊したようで、「回復」画面にしかなりません。セーブモードにさえ入れない状態となり、Windowsを再度クリアインストールする羽目になりました(涙)。

f:id:toranosuke_blog:20180906144525j:plain:w500
Windowsからのご臨終のお知らせ。
回復環境(F1キー)にもスタートアップ設定(F8キー)にも入れない。

A.3 Linuxでのハードルは高かった...

 外付けのHDD起動でもセーフモードでは起動できたので、ddコピーしたディスクを内蔵ディスクと入れ替えれば、起動できたのではないかと思います。

 そうは言っても、確実に起動できるか、分かりません。Windowsの場合には、専用のクローン化のツールがあるので、そちらを使うのが正しいのでしょう。例えば、EaseUS Todo BackupAOMEI Backupper などが人気があるようです。

 しかし、Linux freakな私としては、敗北感を感じます(笑)。

*1:「完全シャットダウン」は、Shiftキーを押しながら「シャットダウン」をクリックすればできます。また、"shutdown.exe /r /t 0"でも構いません。私は、いつもは、shutdownコマンドへのショートカットを作って、完全シャットダウンを行っています。

Dynabook AZ77のSSDへの換装 (3) ddを使ったディスクのコピー

【概要】 昔からunix系にあるddコマンドはディスクコピーに重宝する強力なツールです。取り出した内蔵ハードディスクのデータをddコマンドを使って、コピーする方法についてまとめました。さらに、ddコマンドで落としたディスクイメージファイルをマウントする方法についても説明します。

1. はじめに

 前回までの記事でdynabook内蔵の1TBのハードディスクを取り出しまでについて書きました。今回は、このハードディスクの中に入っているデータのコピーについて説明します。

2. 外付けディスクケース

 内蔵ハードディスクのままでは扱えませんので、外付けのディスクケースに入れて使用します。

 今回、用いた外付けのディスクケースは、玄人志向とCenturyの製品です。Centuryの製品は8年ぐらい前に購入した古いもの。最近は、玄人志向の製品を使うことが多いです。

 今回は、別のLinuxパソコンを使って、内蔵ハードディスクをディスクケースに入れて、外付けディスクとして取り扱いました。ubuntuのLive CD/USBなどを作って、元々のパソコンをLinuxマシンとして起動できれば、内蔵HDDを取り出さずに、外部デバイスにコピーできます。考えてみると、Live USBを作ってLinux上で作業した方が良かったかもしれません(が、わざわざマシンが壊れたときに作るのは面倒。余裕のあるときに予め作っておくのがよいのでしょうね)。

3. ディスクの障害診断

 lubuntuをインストールしたHP miniにHDDを接続して、SMART(Self-Monitoring, Analysis and Reporting Technology)の情報を調べました(SMARTの各項目の意味は、ウィキペディア参照)。

 画像は、gnome-disksの画面です。64個の不良セクターがあり、HDD障害が発生していることが分かります。ひどい状態です。まともに動作しないのも納得。

$ gnome-disks

あるいは、「アクセサリ」→「ディスク」から起動(lubuntuの場合)
f:id:toranosuke_blog:20180823130955p:plain:w500

不良セクターが64個あります。使用可能となっていますが、不良セクターが64個もあれば、ディスクは即交換です。

f:id:toranosuke_blog:20180823131008p:plain:w500
SMARTのセルフテストの結果。
Current Pending Sector Countが16。16セクタが代替処理ができずにいる。

4. ディスクのコピー

 ディスクのコピーにはいろいろやり方はありますので、いくつか紹介します。実際に行ったのは、4.1.1節で説明する丸ごとディスク内容を抜き出して、ファイルに落とす方法です。

4.1 ディスクを丸ごとコピーする

4.1.1 ディスク内容を丸ごとファイルに落とす

 ddコマンドを使って、ディスクの内容をそのままファイルに落とします。

 一旦、全部をファイルに落とすので、その後は、壊れかけのディスクにアクセスせずに取り扱えるようになります。出力したファイルは、ハードディスクにディスク内容を書き戻し(4.1.3節)やファイルをディスクと見立てたマウント(4.2.2節)のために利用します。

$ dd if=/dev/sdc of=dynabook-az77-1tb-hdd.img bs=1M

 出力ファイルは、容量1TBになります。従って、of(output file)には、1TB以上の空きが必要です。今回は、2TBハードディスクをバックアップ用に用意しました。

 bsオプション(ブロックサイズ)は、1M~16Mぐらいを指定すればよいと思います。以下では、bsオプションの記載は省略します。

4.1.2 ディスク内容を丸ごとディスクにコピーする

$ dd if=/dev/sdc of=/dev/sdb

 出力先のディスク(ここでは、/dev/sdb)は、1TB以上の容量が必要です。丸ごとコピーするので、コピーしたディスクをそのままもとの筐体に戻せば、復旧するはずです(もしかしたら、BIOSや起動フラグなどの設定が必要かもしれません)。

 1TB以上の場合には、その後、パーティションを作成、あるいは、拡張することで、余った部分を有効利用できます。

 また、dynabook内蔵のHDDは、東芝製のSSHD MQ02ABD100Hでしたので、SSDへ換装しないなら、同じハードディスクを使う方が安心です。

4.1.3 ファイルからディスクへ丸ごとコピーする

4.1.1節で説明したようにddコマンドでファイルに落としたディスク内容は、ddコマンドを使って、ハードディスクに書き出すことができます。

$ dd if=dynabook-az77-1tb-hdd.img of=/dev/sdb

ここでは、/dev/sdbが出力先のデバイスです。要するに、ddコマンドは、ファイルも、デバイスも同じように扱うことができるのです。

4.2 パーティション単位でコピーする

 ddを使えば、パーティション単位のコピーもできます。今回のディスクのパーティションは5つありますので、次のようにすれば、全てのパーティションをコピーできます。

$ dd if=/dev/sdc1 of=disk-part-1.img
$ dd if=/dev/sdc2 of=disk-part-2.img
$ dd if=/dev/sdc3 of=disk-part-3.img
$ dd if=/dev/sdc4 of=disk-part-4.img
$ dd if=/dev/sdc5 of=disk-part-5.img

 この場合、パーティションテーブルは保存されませんので、別途、gdiskを使って保存します。

$ gdisk /dev/sdc
Command (? for help): b
Enter backup filename to save: gpt-table.dat
The operation has completed successfully.

4.3 ディスク内容を個別にコピーする

 ディスクをマウントして、それぞれのファイルを見られるようにすれば、必要なファイルを選択的にコピーすることができます。

4.3.1 ディスクをマウントする

$ mkdir /mnt/tmp
$ mount /dev/sdc3 /mnt/tmp

マウントポイント(/mnt/tmp)を作成し、そこへWindowsのユーザーが通常アクセスする3番目のパーティション(この例では、/dev/sdc3)をマウントします。その後は、通常のファイル・ディレクトリと同様に、cpコマンドやrsyncコマンドなどを用いて内容をコピーします(個人的にはrsyncの方が好みです)。

$ cp -dpr /mnt/tmp/Users/tora tora_backup/ 
$ rsync -av /mnt/tmp/Users/tora/ tora_backup/

(rsyncは、ソース側の最後のディレクトリデリミタ"/"の有無で動作が異なるので要注意)

4.3.2 ファイルをマウントする

 ファイルシステムのマウントはディスクのみならず、4.1.1でディスク内容を丸ごと落としたファイルでも可能です。このファイルをマウントすることで、前節と同様にファイルをコピーできます*1

(ループバックデバイスの確認)
$ losetup -f 
/dev/loop0

(イメージファイルをループバックデバイスに関連付ける)
$ losetup /dev/loop0 dynabook-az77-1tb-hdd.img

(ループバックデバイスのパーティションを認識させる)
$ partprobe /dev/loop0

(3番目のパーティションをマウントする)
$ mkdir /mnt/tmp
$ mount /dev/loop0p3 /mnt/tmp

(コピーなど作業する)

(マウントを解除する)
$ umount /mnt/tmp

(ループバックデバイスの関連付けを解除する)
$ losetup -d /dev/loop0

 しかし、この方法でのファイルの抜き出しで、少々、トラブルがありましたので、付録Aで説明します。

5. まとめ

 昔からunix系にあるddコマンドを使って、ハードディスクのデータをコピーする方法についてまとめました。さらに、ddコマンドで落としたディスクイメージファイルをマウントする方法についても説明しまた。

 次の記事では、ダンプしたディスク内容のSSDへの書き戻しについて説明します。

(2018/8/23)

関連記事

付録A:ディスクイメージがマウントできない

 ddでコピーしたディスクイメージのloopデバイスを使ったマウントについて4.3.2節で説明しました。しかし、マウントできないというトラブルがありました。

 ここでは、そのトラブルと対処方法について説明します。

A.1 partprobeでパーティションが認識できない

 4.3.2節では、ディスクイメージとloopデバイスをlosetupで関連付けた後、partprobeでディスクイメージのパーティションを認識させます。このときに、次のエラーが発生しました。

$ losetup /dev/loop0 dynabook-az77-1tb-hdd.img
$ partprobe /dev/loop0 
Error: /dev/loop0 を読み込み中にファイルの終わりに達しました

A.2 partedでloopデバイスを調べる

partedでパーティションを調べると、partprobeと同じメッセージがでてきましたが、無視して調べると、GPTテーブルが壊れていると出てきます。不吉です。それでも、一応は、パーティションを見ることができました。

$ parted /dev/loop0
GNU Parted 3.2
/dev/loop0 を使用
GNU Parted へようこそ! コマンド一覧を見るには 'help' と入力してください。
(parted) p                                                                
エラー: /dev/loop0 を読み込み中にファイルの終わりに達しました
やりなおし(R)/Retry/無視(I)/Ignore/取消(C)/Cancel? I                      
エラー: バックアップ GPT テーブルは壊れていますが、プライマリは問題ないようなので、そちらを使います。
OK/取消(C)/Cancel? OK                                                     
モデル: Loopback デバイス (loopback)
ディスク /dev/loop0: 1000GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ:

番号  開始    終了    サイズ  ファイルシステム  名前                          フラグ
 1    1049kB  274MB   273MB   fat32             EFI system partition          boot, esp
 2    274MB   290MB   16.8MB                    Microsoft reserved partition  msftres
 3    290MB   987GB   986GB   ntfs              Basic data partition          msftdata
 4    987GB   988GB   1061MB  ntfs                                            hidden, diag
 5    988GB   1000GB  12.5GB  fat32             Basic data partition          hidden, diag

A.3 gdiskを使って修復

 gdiskを使って、loop0を見ようとすると、今度はディスクを修復するようにとのメッセージがでます。修復することにしましたが、ディスクイメージを破壊する可能性があるので、オリジナルのディスクイメージではなく、そのコピーに対して修復を行いました(バックアップ用の2TBでは、容量が足りないので、さらに2TBのディスクを用意しました)。

 パーティションテーブルの問題点や修復作業についてはわけがわからないまま、コマンドの指示に従って作業を進めました(笑)。長いですが、全部、引用しておきます。

  • バックアップGPTヘッダ(第2GPTヘッダ)が壊れているので、修復するように言われました。
$ gdisk /dev/loop0
GPT fdisk (gdisk) version 1.0.3

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.
****************************************************************************
  • それでも、パーティション情報を出力すると、一見正しそうな情報を出力しました。
Command (? for help): p
Disk /dev/loop0: 1953525167 sectors, 931.5 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): B45D2A5C-F9A4-478D-818B-D8E6280ABEA4
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 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 4642 sectors (2.3 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      1926947658   918.6 GiB   0700  Basic data partition
   4      1926948864      1929021439   1012.0 MiB  2700  
   5      1929022863      1953525134   11.7 GiB    2700  Basic data partition

  • gdiskの指示に従って、コマンド"v"(verify disk)を実行すると、3つの問題点を指摘されました。
Command (? for help): v

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.  
(→ 第2ヘッダーに書かれている自分の位置は、ディスクの最後になっていない)

Problem: Disk is too small to hold all the data!
(Disk size is 1953525167 sectors, needs to be 1953525168 sectors.)
The 'e' option on the experts' menu may fix this problem.
(→ ディスクのサイズが1セクタ足りない)

Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.
(→ MBRに書かれているパーティションが大きすぎる)

Caution: Partition 5 doesn't begin on a 8-sector boundary. This may
result in degraded performance on some modern (2009 and later) hard disks.

Consult http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/
for information on disk alignment.
(このCautionはあまり気にする必要はなさそう)

Identified 3 problems!

 パーティションテーブルのレイアウトが分からないと、何をいっているか、チンプンカンプンです。ウィキペディアによれば、パーティションテーブルは、以下の図のように配置されています。

f:id:toranosuke_blog:20180827105413p:plain:w500
パーティションテーブルのレイアウト。(wikipediaより引用)
各LBAは512バイト、各エントリは128バイト。

 2番目の問題(Disk is too small)は、ディスクサイズが1セクタ足りないとの指摘です。おそらく、ディスクの最後の1セクタ(512バイト)がディスクイメージのファイルに保存されていないことが原因と考えられます。

 ダンプされたディスクイメージのファイルサイズは、1,000,204,885,504バイト(=1,953,525,167セクタ×512バイト)です。一方、パーティションテーブルには、それよりも1つ多い1,953,525,168セクタあると、書いてあるのではないかと思います。

 第2ヘッダーの位置は、ディスクの最後と決まっているので、最後の1セクタがダンプされていないと、第2ヘッダーに書かれている位置と、ディスクイメージの最後から数えたヘッダの位置に不整合が発生します。これが第1の問題である第2ヘッダの自己ポインタが変だという検査結果となり、第2GPTヘッダは、壊れていると判断されます。

 第2GPTヘッダは壊れていますので、パーティション構成の解釈は、MBRによってなされます。MBRに記録されているセクタ数がダンプしたファイルのセクタ数よりも大きくなっているので、第3の問題点(MBRのパーティションが大きすぎる)を指摘されます。

  • experts' menuに入って、eオプションを実行。

 experts' menu のeコマンドは、「relocate backup data structures to the end of the disk」という処理です。意味をよく理解していませんが、第2GPTヘッダをディスクの最後に配置しなおす(前にずらす)ということだと思います。

Command (? for help): x
(コマンドxでexperts menuに入ります)

Expert command (? for help): e
Relocating backup data structures to the end of the disk

Expert command (? for help): p
Disk /dev/loop0: 1953525167 sectors, 931.5 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): B45D2A5C-F9A4-478D-818B-D8E6280ABEA4
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 1953525133
Partitions will be aligned on 8-sector boundaries
Total free space is 4642 sectors (2.3 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      1926947658   918.6 GiB   0700  Basic data partition
   4      1926948864      1929021439   1012.0 MiB  2700  
   5      1929022863      1953525134   11.7 GiB    2700  Basic data partition

"last usable sector" が"1,953,525,134"から1,953,525,133に一つ減りました。

  • 再度、vコマンド(verify disk)を行うと、問題点は1つなりました。

 今度は、コマンド"s"(resize partition table)を使ってパーティションテーブルサイズを4つ減らせとのこと。

 第2ヘッダを1セクタ前にずらしていますので、パーティション5の最後の1セクタと第2GPTエントリーの1セクタが重複します。この重複を解消するために、1セクタ(512バイト)の大きさ分の4エントリ(4エントリ×128バイト=512バイト)を減らす必要があるということかと思います。

Expert command (? for help): v

Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Caution: Partition 5 doesn't begin on a 8-sector boundary. This may
result in degraded performance on some modern (2009 and later) hard disks.

Consult http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/
for information on disk alignment.

Identified 1 problems!
  • expertコマンドs(resize partition table)を実行

partition table sizeを128から124に減らすと、今度はエントリーが少なすぎると警告される。

Expert command (? for help): s
Current partition table size is 128.
Enter new size (5 up, default 128): 124
Caution: The partition table size should officially be 16KB or larger,
which works out to 128 entries. In practice, smaller tables seem to
work with most OSes, but this practice is risky. I'm proceeding with
the resize, but you may want to reconsider this action and undo it.
  • partition table sizeを124,128,132と変更してみた。

 partition table sizeを124にすれば、エントリーが足らないと注意され、128以上にすると、第2パーティションテーブルが、最終パーティションとオーバーラップすると注意されます。

 使えるセクターが一つ減った影響で、パーティションテーブルがオーバーラップするか、パーティションテーブルを小さくするかの選択を迫っているということのようです。

 最終的には、パーティションテーブルサイズを124としました。エントリー数が減る影響をよく理解していませんが、大量にパーティションを切らない限り影響はないのではないかと思っています。

Expert command (? for help): v

Warning: The size of the partition table (15872 bytes) is less than the minimum
required by the GPT specification. Most OSes and tools seem to work fine on
such disks, but this is a violation of the GPT specification and so may cause
problems.

Caution: Partition 5 doesn't begin on a 8-sector boundary. This may
result in degraded performance on some modern (2009 and later) hard disks.

Consult http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/
for information on disk alignment.

No problems found. 4643 free sectors (2.3 MiB) available in 3
segments, the largest of which is 2015 (1007.5 KiB) in size.

Expert command (? for help): s
Current partition table size is 124.
Enter new size (5 up, default 128):

Warning! Secondary partition table overlaps the last partition by
1 blocks!
Try reducing the partition table size by 4 entries.
(Use the 's' item on the experts' menu.)

Expert command (? for help): s
Current partition table size is 128.
Enter new size (5 up, default 128): 132

Warning! Secondary partition table overlaps the last partition by
2 blocks!
Try reducing the partition table size by 8 entries.
(Use the 's' item on the experts' menu.)

Expert command (? for help): s
Current partition table size is 132.
Enter new size (5 up, default 128): 124
Caution: The partition table size should officially be 16KB or larger,
which works out to 128 entries. In practice, smaller tables seem to
work with most OSes, but this practice is risky. I'm proceeding with
the resize, but you may want to reconsider this action and undo it.
  • expertメニューからメインメニューに戻り、再度、検証(v)し、パーティションテーブルの修正結果の書込み(w)を行いました。
Expert command (? for help): m

Command (? for help): v

Warning: The size of the partition table (15872 bytes) is less than the minimum
required by the GPT specification. Most OSes and tools seem to work fine on
such disks, but this is a violation of the GPT specification and so may cause
problems.

Caution: Partition 5 doesn't begin on a 8-sector boundary. This may
result in degraded performance on some modern (2009 and later) hard disks.

Consult http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/
for information on disk alignment.

No problems found. 4643 free sectors (2.3 MiB) available in 3
segments, the largest of which is 2015 (1007.5 KiB) in size.

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/loop0.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
  • パーティションテーブルの再確認

 最終的に次のようなパーティションテーブルとなりました。当初"damaged" だった、GPTパーティションテーブルも"present"と正常になりました。

$ gdisk /dev/loop0
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.

Command (? for help): p
Disk /dev/loop0: 1953525167 sectors, 931.5 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): B45D2A5C-F9A4-478D-818B-D8E6280ABEA4
Partition table holds up to 124 entries
Main partition table begins at sector 2 and ends at sector 32
First usable sector is 33, last usable sector is 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 4643 sectors (2.3 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      1926947658   918.6 GiB   0700  Basic data partition
   4      1926948864      1929021439   1012.0 MiB  2700  
   5      1929022863      1953525134   11.7 GiB    2700  Basic data partition
  • 修復前から変化した点は、次の通りです。
    • パーティションテーブルのサイズ:128→124エントリー
    • メインパーティションテーブルの終了セクター:33→32
    • 使用可能な最初のセクター:34→33
    • フリースペース:4642セクター → 4643セクター

 第2ヘッダのサイズが小さくなった影響を受けて、第1ヘッダのサイズも小さくなり、利用できるセクターが1セクタ増えたということのようです。

 この修正により、partprobe /dev/loop0も正常動作するようになり、パーティションを正しく認識するようになりました。

A.4 パーティションテーブルのダンプと修正

 gdiskの修復メッセージから類推すると、以下の図に示すような現象が起こっていたと思われます。まず、ddによるダンプによって、1セクタのコピー漏れが発生し、第2GPTヘッダが消失します。その第2GPTヘッダを新規作成するために、エントリー配列の大きさを128から124に減らし、1セクタ分小さくします。これに伴って、第1GPTエントリ配列も124エントリとなり、第1エントリ配列の直後の1セクタが新規に空き領域となります。

f:id:toranosuke_blog:20180827144102p:plain

 しかし、dynabookの壊れかけている内蔵ディスク/dev/sdcを直接gdiskコマンドで、調べたところ、ddでダンプしたディスクイメージと全く同じように第2GPTヘッダが壊れていました。ddが書き漏らしたのではなく、最初からディスク末尾の1セクタ(512バイト)が欠けていたのかもしれません。また、もともとWindowsでは、パーティションテーブルを正しく書いていない、という可能性もありますが、よく分かりません。

(追記:2018/9/21)この現象は、外付けハードディスクによって、読み取ることができるセクター数が異なることが原因と判明しました。
 本稿でハードディスクのddダンプで用いたのは、Centuryの製品です。また、作業用に用いていたのは、玄人志向の製品です。この二つの製品では、ハードディスクの最後の1セクタ (512バイト) を読み取ることはできず、欠損が生じます。
 これは、その後に購入した ELUTENG のディスクケースと玄人志向・Centuryのディスクケースでは、認識するディスクサイズが異なることから気が付きました(詳しくは、 この記事を参照)。
 実際、1TBのハードディスクの末尾の1セクタをELUTENGのディスクケースを使って読み込んで、Centuryのディスクケースでddダンプしたファイルの末尾に追加すると、gdiskは正常にGPTテーブルを解釈します。

● センチュリー ● 玄人志向 ● ELUTENG

A.5 もしかしたら、ディスクイメージの末尾に512バイト追加すればよかったのかも...

 パーティションの修復が必要なのは、ディスクイメージが1セクタ分欠けていることが原因と考えられます。gdiskを使った修復では、パーティションテーブルのサイズを128エントリから124エントリに減らしましたが、それだと、GPTヘッダの仕様で要求される128エントリを確保できません。

 そうであれば、次のような方法で、ディスクイメージに512バイト追加すれば、128エントリーを確保できるのではないかと思います。

  • ddでダンプする際に必要なセクタ数を明示的に指定してコピーする。
$ dd if=/dev/sdc of=disk.img count=1953525168

 もしかしたら、オリジナルのディスクの第2ヘッダの情報が正しくコピーされるかもしれません。そうであれば、partprobeも問題なく通過するでしょう。(しかし、ddで末尾までスキップして、ダンプしたところでは、期待していた1953525168番目のセクタは読みだせませんでした)

  • ディスクの最後の1セクタだけを読みだして、既にダンプしたディスクイメージに追加する
$ dd if=/dev/sdc skip=1953525167 count=1 >> disk.img

 dynabookに入っていた壊れかけたハードディスクの全データをダンプするのは大変です。この方法では、最後の1セクタだけを読み出して、既にダンプしたファイルに追加します。

 実際に行ったところ、 skip=1953525166まではスキップできましたが、1つ増やして1953525167とすると、エラーとなりました。やはり、1953525168番目のセクタは読みだせないようです。

  • ダンプしたディスクイメージの末尾に512バイトの0値を付け加える
$ dd if=/dev/zero count=1 >> disk.img

 この方法では、第2GPTヘッダを修復する必要はあります。実際に試したところ、128エントリーを保ったままパーティションテーブルを修復することができました(付録B参照)。

付録B:ファイルに1セクタ追加して、GPTヘッダを修復

 ddコマンドでダンプしたディスクイメージは、1セクタ(512バイト)欠けているようでした。このため、512バイトの0値をファイル末尾に追加して大きくしたファイルに対して、gdisk を使って、パーティションテーブルを修復しました。これによって、エントリー数を削減することなく、仕様通りのGPTヘッダを作ることができます。

B.1 マウントできるか?

 partprobe でエラーメッセージがでますが、マウントできて、ディスク内のファイルも参照できます。

$ losetup -f
/dev/loop0
$ losetup /dev/loop0 dynabook-az77_1tb-hdd+1sector.img 
$ partprobe /dev/loop0 
Error: バックアップ GPT テーブルは壊れていますが、プライマリは問題ないようなので、そちらを使います。
$ mount /dev/loop0p3 /mnt/tmp1/
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Falling back to read-only mount because the NTFS partition is in an
unsafe state. Please resume and shutdown Windows fully (no hibernation
or fast restarting.)
$ ls  /mnt/tmp1/Users/tora/
'3D Objects'/
 AppData/
'Application Data'@
 Contacts/
 Cookies@
 Desktop/
 Documents/
 Downloads/
 Favorites/
 GoogleDrive/
(略)

 バックアップGPTテーブルは、壊れていると言われますが、マウントできました(read-onlyとなるのは、Windowsでのシャットダウンで完全シャットダウンを行っていないため)。また、ファイルも見ることができます。

B.2 パーティションテーブルの修復

 gdiskを使って第2GPTヘッダを修復しました。第1GPTヘッダを使って修復するコマンドが分からなかったので、一旦、パーティションテーブルを124エントリに縮小し、128エントリに戻すことで、第2GPTヘッダを作っています。

 リカバリーモード("r")のそれらしいコマンド (d, e, f) を試してみましたが、期待した通りの結果は得られませんでした。

 コマンドとしては、次の順序で行っています。

  • x (experts' menuに入る) → s (リサイズする) → 124を入力 → s (リサイズする) → 128を入力 → w (パーティションテーブルを書き込む) → yを入力

 作業にあたっての注意点としては、次の点が挙げられます。

  • パーティションテーブルのバックアップを取ること
     パーティションテーブルを破壊してしまったときに役立つはずです。
  • パーティション内容をよく確認すること
     特に、編集したパーティションテーブルをディスクに書き込む前には、v(検証)だけでなく、p(プリント)も出力して内容をよく確認します。

 両方ともに、さぼったので、実際に、操作を間違えて、パーティションテーブルを破壊し、ディスクイメージを使いものにならなくしてしまいました!(オリジナルコピーからやり直し)

 なお、実際のログは、以下に示す通りです。

$ gdisk /dev/loop0
GPT fdisk (gdisk) version 1.0.3

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.
****************************************************************************

Command (? for help): ?
b   back up GPT data to a file
c   change a partition's name
d   delete a partition
i   show detailed information on a partition
l   list known partition types
n   add a new partition
o   create a new empty GUID partition table (GPT)
p   print the partition table
q   quit without saving changes
r   recovery and transformation options (experts only)
s   sort partitions
t   change a partition's type code
v   verify disk
w   write table to disk and exit
x   extra functionality (experts only)
?   print this menu

Command (? for help): p
Disk /dev/loop0: 1953525168 sectors, 931.5 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): B45D2A5C-F9A4-478D-818B-D8E6280ABEA4
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 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 4642 sectors (2.3 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      1926947658   918.6 GiB   0700  Basic data partition
   4      1926948864      1929021439   1012.0 MiB  2700  
   5      1929022863      1953525134   11.7 GiB    2700  Basic data partition

Command (? for help): v
Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.

Caution: Partition 5 doesn't begin on a 8-sector boundary. This may
result in degraded performance on some modern (2009 and later) hard disks.

Consult http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/
for information on disk alignment.

Identified 1 problems!

Command (? for help): b
Enter backup filename to save: backup-partition.dat
The operation has completed successfully.

Command (? for help): x
Expert command (? for help): ?
a   set attributes
c   change partition GUID
d   display the sector alignment value
e   relocate backup data structures to the end of the disk
f   randomize disk and partition unique GUIDs
g   change disk GUID
h   recompute CHS values in protective/hybrid MBR
i   show detailed information on a partition
j   move the main partition table
l   set the sector alignment value
m   return to main menu
n   create a new protective MBR
o   print protective MBR data
p   print the partition table
q   quit without saving changes
r   recovery and transformation options (experts only)
s   resize partition table
t   transpose two partition table entries
u   replicate partition table on new device
v   verify disk
w   write table to disk and exit
z   zap (destroy) GPT data structures and exit
?   print this menu

Expert command (? for help): s
Current partition table size is 128.
Enter new size (5 up, default 128): 124
Caution: The partition table size should officially be 16KB or larger,
which works out to 128 entries. In practice, smaller tables seem to
work with most OSes, but this practice is risky. I'm proceeding with
the resize, but you may want to reconsider this action and undo it.


Expert command (? for help): v
Warning: The size of the partition table (15872 bytes) is less than the minimum
required by the GPT specification. Most OSes and tools seem to work fine on
such disks, but this is a violation of the GPT specification and so may cause
problems.

Caution: Partition 5 doesn't begin on a 8-sector boundary. This may
result in degraded performance on some modern (2009 and later) hard disks.

Consult http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/
for information on disk alignment.

No problems found. 4644 free sectors (2.3 MiB) available in 4
segments, the largest of which is 2015 (1007.5 KiB) in size.

Expert command (? for help): s
Current partition table size is 124.
Enter new size (5 up, default 128): 128
Expert command (? for help): v
Caution: Partition 5 doesn't begin on a 8-sector boundary. This may
result in degraded performance on some modern (2009 and later) hard disks.

Consult http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/
for information on disk alignment.

No problems found. 4642 free sectors (2.3 MiB) available in 3
segments, the largest of which is 2014 (1007.0 KiB) in size.

Expert command (? for help): p
Disk /dev/loop0: 1953525168 sectors, 931.5 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): B45D2A5C-F9A4-478D-818B-D8E6280ABEA4
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 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 4642 sectors (2.3 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      1926947658   918.6 GiB   0700  Basic data partition
   4      1926948864      1929021439   1012.0 MiB  2700  
   5      1929022863      1953525134   11.7 GiB    2700  Basic data partition

Expert command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/loop0.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

付録C:gdiskのコマンド一覧

  • gdiskのコマンド一覧
Command (? for help): ?
b   back up GPT data to a file
c   change a partition's name
d   delete a partition
i   show detailed information on a partition
l   list known partition types
n   add a new partition
o   create a new empty GUID partition table (GPT)
p   print the partition table
q   quit without saving changes
r   recovery and transformation options (experts only)
s   sort partitions
t   change a partition's type code
v   verify disk
w   write table to disk and exit
x   extra functionality (experts only)
?   print this menu
  • gdiskのexpertコマンドの一覧
Expert command (? for help): ?
a    set attributes
c    change partition GUID
d    display the sector alignment value
e    relocate backup data structures to the end of the disk
f    randomize disk and partition unique GUIDs
g    change disk GUID
h    recompute CHS values in protective/hybrid MBR
i    show detailed information on a partition
j    move the main partition table
l    set the sector alignment value
m    return to main menu
n    create a new protective MBR
o    print protective MBR data
p    print the partition table
q    quit without saving changes
r    recovery and transformation options (experts only)
s    resize partition table
t    transpose two partition table entries
u    replicate partition table on new device
v    verify disk
w    write table to disk and exit
z    zap (destroy) GPT data structures and exit
?    print this menu
  • gdiskのrecovery/transformationコマンドの一覧
Recovery/transformation command (? for help): ?
b   use backup GPT header (rebuilding main)
c   load backup partition table from disk (rebuilding main)
d   use main GPT header (rebuilding backup)
e   load main partition table from disk (rebuilding backup)
f   load MBR and build fresh GPT from it
g   convert GPT into MBR and exit
h   make hybrid MBR
i   show detailed information on a partition
l   load partition data from a backup file
m   return to main menu
o   print protective MBR data
p   print the partition table
q   quit without saving changes
t   transform BSD disklabel partition
v   verify disk
w   write table to disk and exit
x   extra functionality (experts only)
?   print this menu

Dynabook AZ77のSSDへの換装 (2) HDD/SSDの入れ替え

【概要】
 dynabook AZ77を分解し、HDD/SSDを入れ替えを写真付きで説明します。底蓋さえ、開けられれば、HDDとSSDの入れ替えは簡単です。

1. はじめに

 我が家のメインマシンDynabook AZ77のHDDが壊れました。購入が2015年の10月頃なので3年弱の寿命でした。

 この故障を機にHDDをSSDへ切り替えることしました。先の記事では、データのバックアップについて書きましたが、今回の記事では、底蓋を外して、HDD/SDDを入れ替える作業について報告します。

2. サムスンの500GBのSSDを購入した

2.1 HDDの大きさの確認

 まずは、交換するHDDのサイズを調べました。通常は、2.5インチ型SATAです。しかし、内蔵ディスクが、1.8型HHDやM.2規格なのに、2.5型のSSDを購入したりすると、悲しい事態になります。

 まずは、製品仕様で確認しようと思いましたが、書いてありませんでした。他の型番のdynabookのSSD換装の記事を読むと2.5型だったので、たぶん、AZ77も、2.5型だろうということで、2.5型SATAのSSDを購入することにしました。

 考えてみれば、本体を開けて中身を確認してから、購入すれば、間違えはありませんね(笑)。

2.2 サムスンの500GBのSSDを購入

 dynabook AZ77のHDDは、SSDとハイブリッドのHDDの1TBでした。懐の具合が許せば、同じ容量としたいところですが、半分の500GBの容量としました。なお、1TBのHDDの内容を500GBのSSDに押し込もうとするので、後でいろいろとトラブルの原因になる(実際になった!)ので、同じ容量以上にしておいた方が安心です。

 価格コムで500GBクラスのSSDを調べると、売れ筋や安さで上位に挙がってくるのは、次の3機種(無名ブランドは除く)。

 チェックした項目は、厚さ、価格、ブランド、保証期間で、5年保証が目立つように書いてあったサムソンにしました(発注後、インテルも5年保証だと気が付きました。同じ条件なら、インテルの方が好みなのですが、キャンセルも面倒なので、そのままサムスンを発注。crucialは3年保証)。

 価格は、アマゾンでもほぼ同額で購入できるので、アマゾンからの購入です。購入当時は、13,973円でしたが、2018年8月22日現在では、12,684円(500GB)、25,800円(1TB)、49,421(2TB)、103,800円(4TB)となっています(最新価格は、ここ)。お金に少々余裕があれば、1TBが欲しいところです。

3. 筐体の分解とHDDとSSDの交換

 基本的には、①ネジを外して、②底の蓋をパカっと開いて、③HDDの交換です。このうち、②のパカっと開けるのが壊しそうでびくびくしながら行う作業になります。

3.1 ネジを外す

f:id:toranosuke_blog:20180822113612j:plain:w500
このパソコンを分解します。

f:id:toranosuke_blog:20180822113718j:plain:w500
据え置きで使っていたので、裏側の吸気口は埃だらけ。

f:id:toranosuke_blog:20180822113836j:plain:w500
バッテリーを外す。妙にコツがいる。

f:id:toranosuke_blog:20180822114316j:plain:w500
底面のネジを外す。全部で17個(本当は、18個外す。後述)

3.2 パカっと開く

f:id:toranosuke_blog:20180822114608j:plain:w500
本体側と底面側に隙間を作って、徐々に外していく。

 爪を使って素手でも作業はできますが、専用の工具があるのでしょうね。ここが、もっとも神経を使うところです。下手に蓋を開けようとすれば、カバーの爪や内部部品などを壊しそうなので、いつも苦労します。

f:id:toranosuke_blog:20180822114912j:plain:w500
そのまま開こうとすると、ブルーレイドライブが引っかかる。
ここで、強引に開けようとすると、本体を壊します。

f:id:toranosuke_blog:20190711122329j:plain:w500
ブルーレイドライブを固定しているネジを外す。

f:id:toranosuke_blog:20190711122851j:plain:w500
ドライブを外すと、ドライブに隠れていた18個目のネジが現れる。このネジを外す。

f:id:toranosuke_blog:20180822115534j:plain:w500
無時、蓋が外れました。

 写真の左上がファン、それに太い銅管で繋がっているのがCPU、その右側がメモリ、手前の青いのがHDDです。こんな銅管で熱を運んでいるとは思いませんでした。宙に浮かせてはいるようですが、付近に熱が籠りそうです。

3.3 古いHDDを抜き出す

 蓋が取れれば、後は、HDDをSSDに交換するだけです。

f:id:toranosuke_blog:20180822121634j:plain:w300 f:id:toranosuke_blog:20180822121650j:plain:w300
f:id:toranosuke_blog:20180822121729j:plain:w300 f:id:toranosuke_blog:20180822121801j:plain:w300
f:id:toranosuke_blog:20180822121944j:plain:w300 f:id:toranosuke_blog:20180822122004j:plain:w300
ゴム製のマウンタをつまみ上げて、HDDを抜き出す。

 HDDは、東芝製のSSHD MQ02ABD100Hでした。壊れた1TBのHDDの内容を丸ごとコピーして、復旧させるなら、このハードディスクが安心です。

3.4 新しいSSDを挿す

 クリアインストールする場合には、購入したものをそのまま交換します。

f:id:toranosuke_blog:20180822132231j:plain:w300 f:id:toranosuke_blog:20180822132327j:plain:w300
新しく入れるSSDは、Samsung 860EVOの500GB。

f:id:toranosuke_blog:20180822132705j:plain:w300 f:id:toranosuke_blog:20180822132726j:plain:w300
ゴム製のマウンタを取り付けて、元の場所に挿入する。

3.5 BIOSで確認する

 後は、底蓋を閉じて、バッテリーを戻して、終了です。

f:id:toranosuke_blog:20180822140216j:plain:w500
BIOSでディスクを確認。(BIOSに入るためには、起動時にF2連打)

4. おわりに

 無事、SSDへの交換が完了しました。

 下手に蓋を開けようとすれば、内部部品やカバーの爪を壊しそうなので、いつも苦労します。それさえ、問題がなければ、後は簡単です。

 次は中身の復旧です。

(2018/8/22)
(2019/7/11) 18個目のネジの場所が分かりにくかったので、写真を追加、本文を修正しました。

関連記事