解き放たれしソフトウェア

GNU/LinuxなどFLOSSについて書いてみるつもり

Windows を MBR・非GPT から UEFI・GPT に、データ削除なしに移行する方法

WindowsMBR から UEFI に、再インストールや復元作業なしに移行することに成功したので、メモ書きをします。 理解したうえで自己責任でやるべきなので、具体的なコマンドの詳細説明は書きません。

BitLocker を用いている場合はどうやったらいいか知りません。ブートが多段構造になっているからです。以下は、BitLocker 暗号化していないという前提です。

UEFI / GPT インストールWindowsパーティション構成

マイクロソフト予約済みパーティションって何?

BitLocker で 暗号化済のシステムをブートする際の踏み台です。暗号化されたパーティションからいきなり起動は不可能なので。 BitLocker の導入予定があるならば、置いておきましょう。

方針

  1. もしも GNU/Linux 環境がなければ、GParted Live などのライブディスクを作成します。 おそらく、SystemRescueCdClonezilla などでもかまわないでしょう。
  2. フルバックアップを行う
  3. システム修復ディスクまたはインストールメディア(書込可能DVDまたはUSBフラッシュメモリ)を作成する
  4. ディスクを GPT に変換する
  5. (無ければ)ディスク上に空き領域をつくる(既存パーティションの縮小)
  6. EFI システムパーティション(ESP)を作成する
  7. マイクロソフト予約済パーティションMicrosoft Reserved Partition ; MRP)を作成する
  8. ESP に Windowsブートローダを書き込む

上記1と2は、 WIndows 上で行います。コントロールパネルの、バックアップ(Windows7)のところでやります。

3~6は、システム修復ディスクまたはインストールメディアで起動しても可能ですが、GNU/Linux上でも可能で、その方がやりやすいと思います。なぜなら、 GUI もある&インターネット接続して調べながらでもやれるから。 GParted Live などの、パーティション編集用のディストリビューション(ライブイメージ)で起動するとよいかもしれません。

3の GPT への変換は GPT fdisk (gdisk)で行います。

4~6は、 GParted でも可能です(ただし、2は NTFS 編集用のソフトウェアも入っている必要がありますが、 GParted Live などではまずデフォルトで導入済でしょう)。

7は、システム修復ディスクまたはインストールメディアから起動してコマンドラインでやります。

フルバックアップ

フルバックアップしましょうWindows 標準の機能であります。ただし、 Windows 7 時代からの旧来の方式でやります。

同じディスクにある他のパーティションも、バックアップしておいたほうがよいです。 私は責任もちません。 GParted Live などで起動してパーティションごと他のディスクにコピーするなどしてもよいと思います。

システム修復ディスクまたはインストールメディアの作成

フルバックアップと同じところで、修復ディスクもつくれます

インストールメディアを作成する方法もあります。 その場合は、書込可能な空の DVD か、4GB以上の空の USB フラッシュメモリが要ります。 方法はマイクロソフトのウェブサイトに行ってください。

既にインストールメディアを買って持っているというならば、それを使う手もあります。

高速スタートアップを切り、完全シャットダウンする

とはいえ、「シャットダウン」でなく「再起動」なら済みますが。

あと、繰り返しますが、 BitLocker 使っていないのが前提です。

GPT への変換

GPT への変換をすると、 MBR が消えます。一旦はこのディスクからはブート不能な状態になります。 だから、バックアップしましたよね?

GParted Liveなどの GNU/Linux のライブディスクで起動します。

sudo gdisk -l で、 Windows の入っているディスクのブロックデバイス名を特定してください。たとえば /dev/sdb1 ならば、sudo gdisk /dev/sdb で入り、 w (書込むコマンドだけ)で GPT に変換されます。

空き領域をつくる

後記の、 ESP や MRP を作成するための領域が必要だからです。 容量は、 ESP が 100MB 以上、 MRP が 128MB 以上が目安ですから、その合計分を用意します。私としては、 256MB がおすすめです。

空き領域がなければ、システムパーティションを縮小するなりしてつくります。 GParted だと平易です。時間はそこそこかかります。

状況によっては Windows RE (修復作業用のパーティション)がつくられていることがありますから、不要ならば消して領域を空けるということも考えられます。 修復用ディスクなりインストールメディアなりがあれば代わりになりますので、Windows RE を削除してもどうにかなります。

EFI システムパーティションをつくる

100MB 以上の大きさパーティションをつくります。(きりがいいので、128MB がおすすめです。)

フォーマットは FAT32 です(ESP は FAT32 と決まっています)。

パーティションに適当なラベルをつけます。(Windows のデフォルトでは、 “System” のようです。)

パーティションのフラグを “esp” に設定します。

マイクロソフト予約済パーティション(MRP)をつくる

BitLocker を利用するときに使うパーティションです。BitLocker を金輪際つかわないのならば不要です。

つくるならば、128MB つくっておけば、前記 ESP と足して 256MB できりがいいです。

MRP にフォーマット形式はありません。

パーティションのフラグを “msftres” に設定します。

Windowsブートローダをインストール

システム修復ディスクまたはインストールメディアで再起動し、コマンドプロンプトに入ります。

  1. 言語、時刻、通貨、キーボード、入力方式を選択
  2. コンピューターの修復
  3. 修復したいオペレーティング システムを選択
  4. システム回復オプションを選択
  5. コマンド プロンプトを選択

以下、DOS/Windowscase insensitive なので、コマンドは大文字でも小文字でも構いません。

  1. DISKPART を実行します。
  2. LIST DISK で、該当する Windows のインストールされているディスクの番号を見つけます。
  3. SELECT DISK n で当該ディスクを選択します(例えば1番なら、SELECT DISK 1
  4. LIST PARTITIONパーティション一覧。ESP のパーティション番号と 、Windows 本体の入っているパーティション番号を把握します。
  5. SELECT PARTITION n で、ESPのパーティションを選択します(例えば0番なら SELECT PARTITION 0
  6. ASSIGN LETTER=S などとして、とりあえず空いている適当なドライブ記号を割り当てます(左記の例では S: ドライブになる)
  7. SELECT PARTITION n で、 Windows 本体のパーティションを選択します
  8. 例えば Windows のドライブが C: だったら ASSIGN LETTER=C
  9. EXIT で DISKPART を終了します、これで通常のコマンドプロンプトに戻ります。
  10. BCDBOOT で、 ESP にブートローダを書き込みます。たとえば、Windows 本体が C:\WINDOWS にあり、 ESP が S: ドライブならば、 BCDBOOT C:\WINDOWS /S S: /F UEFI で ESP に書き込みます
  11. EXIT で終了。マシンを再起動

参考

UEFI インストールの Windows には、 MBR を書き込まないほうがよい

結論

UEFI 方式でインストールした Windows のディスクにマスターブートレコード(MBR) を書き込む*1と、高速スタートアップやハイブリッドスリープ、ハイバネーション(休止状態)の動作がおかしくなる可能性が大。 例えば GRUBMBR に書き込む*2とおかしくなります。

原因

  • Windows は、UEFI インストールの場合でも、有効な MBR があればMBRから起動しようとします
  • 初回起動(クリーンブート)では、メインボード(M/B)上のファームウェアは、EFI システムパーティション(ESP)内のブートイメージを起動するので支障は起こりません
  • 他方で、高速スタートアップやハイブリッドスリープによる電源断、ハイバネーションの場合には、M/B の ACPI 電源管理機能を利用して休止・復帰を行うため、ESP からのブートと異なる挙動をとることが少なくありません(その方が復帰が早い)
  • よって、休止からの復帰の場合だけ、有効な MBR を読み込んで復帰しようとしてしまい、MBRブートローダが始動。正常な復帰がなされなくなります
  • そこで例えば GRUB をインストールしていたら、 GRUB の画面が出てきてしまいます。GRUB の設定に GNU/Linux ディストリビューションの起動項目1つのみしかないと、問答無用で GNU/Linux が起動されるかもしれません

以下、訥々と話が長いです

MBR 方式って何?

OS を起動する際に、M/B の ファームウェアBIOS)は、OS を直接起動するわけではありません(そもそも、どこに OS があるかを検知不可能です)。 そこで、接続されているディスクの先頭に実行可能バイナリ(ブートローダ)を書き込んでおき、M/B はそのバイナリを探して実行します。

MBR ではなく UEFI (旧称・ EFI) にするメリット

  • MBR はディスクの先頭と決まっていますから、マルウェアの格好の目標です。
  • MBR は1つのディスクに一箇所しかないので、同じディスクに複数の OS をインストールする場合には、 MBR の取り合いが発生しやすいです(特に Windowsプロプライエタリなのでしょっちゅう奪おうとする)。UEFI では、専用のパーティションEFI システムパーティション)にブートイメージを保存しますので、複数のブートイメージの共存が可能です。UEFI 対応 M/B では、ブートイメージを選んで起動させます。

GPT 方式

従来は原則として、一つのディスク上には基本(プライマリ)パーティションと拡張パーティションをあわせて4つしかつくれませんでした。5つ以上のパーティションをつくりたいのなら、拡張パーティション内に論理パーティションをつくります。

従来は、 2 テラバイト(TiB)を超えるディスク領域を扱えませんでした。

Intel は、64 bitアーキテクチャ(IA64)をつくった際に、こうした制約にはとても困ったので(ハイスペックなマシン能力が活用しえない)、 EFI と GPT への移行を提唱しました。

MBR と GPT との関係

原則としては、 MBR・非GPTか、UEFI・GPTかの二者択一です。 Windows でもこの二者択一でしかインストール不可能で、WindowsMBR・非GPT か UEFI・GPTかのどちらかだと決め打ちしています

GPT のディスクでは、"Protective MBR" 方式が導入されます。ディスクを GPT 非対応の M/B に接続した際には、最初の4つまでのパーティションが有効なパーティションとして見えます。MBR にはブートローダを入れず、いわば、ダミーになります。

よって、UEFI・GPT方式で Windows を正常にインストールしている状況では、Protective MBR でしかありええず、 MBR にはブートローダが入っていません

しかし、GPT ディスクに 使える MBRを書き込むことは理論的には可能です。例えば、GPT ディスクの MBR 領域に GRUB をインストールすることは可能です。 GNU/Linux では、UEFIMBR の両方にブートローダが入っていても、 UEFI からブートしますので、差し支えありません。

Windows は、MBR に有効なブートローダが入っていると、そこからブートしようとします

さて、初回起動時(クリーンブート時)には、マシンの制御権は M/B のファームウェアに一身専属ですから、 ESP から正常にブートします。 しかし、休止状態からの復帰は、通常の電源オンではなくて、ACPI による電源管理により中断しています。まるでサスペンドの電源切れた版のような挙動をする(した方がよい)ため、クリーンブートと異なるスタートアップが起こります。 このとき、 Windows は、MBR を読み出すようです。(ただし、M/B によってはもしかすると、そうならないこともあるかもしれません。)

UEFI ではない 旧来の MBR オンリーで Windows でマルチブートだったら?

  • どの OS も MBRブートローダから起動させるしかありません。つまり、どの OS も MBR 方式でインストールするはずです。だから、ブートローダの設定でマルチブートにしますよね?
  • そこで例えば GRUB をインストールしていたら、もしも復帰時に GRUB の画面が出てきたら、 Windows を選んでブートすればよいでしょう

この旧来の MBR 方式のマルチブート環境の場合は、ことあるごとに WindowsMBR を書き換えようとするので、また別の支障があります。Windows Update などで MBR を書き換えるようなパッチの適用がされると、MBR が上書きされて GRUB 消えます

だから従前は、そもそも Windows をインストールしたディスクに他の OS をインストールしないのが最善策でした。

しかし、このブートレコード取り合い問題は、 UEFIに移行すれば解消します。

結局、どうすればいいの?

すべての OS を UEFI・GPT 方式でインストールしてください。 ESP にそれぞれのブートローダをインストールして、M/B のファームウェアの設定で起動対象を選びましょう。

ハイブリッド MBR は、ディスクを UEFI 非対応マシンにつなぎ替える可能性があるときには便利ですが、 GNU/Linux しかインストールしていないようなディスクの場合のみにとどめるべきです。 Windows にハイブリッド MBR を使うには、かなりの戦略が必要です。

http://www.rodsbooks.com/gdisk/hybrid.html の “OSes' Reactions to Hybrid MBRs” の Windows の項目にも、Windows のデフォルトの起動が MBR であることが書いてあります。ハイブリッド MBR ではかなり厄介なのがわかります。

もしも Windows のディスクの MBRGRUB を書き込んでしまったら?

Protective MBR を再度書き込み直します。 おそらく、 GPT fdisk を用いれば可能です。

“x extra functionality (experts only)” → “n create a new protective MBR

参考: http://www.rodsbooks.com/gdisk/walkthrough.html

*1:ハイブリッド MBR

*2:例えば grub-install –target=i386-pc する

GNU/Linux で使えるバックアップ用ソフトウェア

昨日から今日の昼頃まで季節外れの気温で、「もう春本番?!」と思うくらいだった不気味な天気でした。 近年は気候が異常なのが顕著で、対応と抑制が喫緊の死活問題だなと思います。

精密機器は温度と湿度が重要で、HDDは温度が高すぎても低すぎても壊れやすいようですし、SSDは湿度に弱いそうです。

私もHDDの故障には何度も遭遇しています。 異音で事前に察知したこともありますし、S.M.A.R.T. で気がついたこともあります。ちなみに、 S.M.A.R.T. の調査には smartmontoolsが便利です。 しかし、制御回路上の半導体の急死で事前に察知し得なかったこともあります(昔の、富士通の 5400 rpm のやつとか……)。

HDDは扱い方次第で5年も10年も保つ可能性がありますが、SSDは使い続けていると書換耐性が落ちて確実に使えなくなります。

いずれにせよ、バックアップは重要です。消えたら原状回復不可能なものはバックアップすることです。 GNU/Linuxでは /etc/homeのバックアップが挙げられますが、Gentoo だと /var/lib/portage/world のほかに /var/db/pkg のバックアップも挙げられます。

バックアップの方法

さて、バックアップの方法の問題です。

ディスクイメージごと

例えば、パーティションのイメージごとバックアップをするという方法もあります。 しかし、不必要なものまで入るのでサイズが巨大になります。 参考: ArchWiki

rsync

rsync を使うとディレクトリをまるごとコピー可能なので構造的に簡単で、変更されたファイルだけを同期させられます。 しかし、 rsync 自体には、一つのファイルにまとめたり圧縮したりする機能がありません。 参考: ArchWiki

自力

手作業で、 tar でアーカイブし(一つのファイルにまとめ)たり、gzip などで圧縮したりすることがあります。 圧縮形式は、gzipGNU のスタンダードですが、 lzip がバックアップに向いていると思われ、plzipを使えば並列処理が可能なのでマルチコアCPUなどでは速くなります。

ここで「バックアップ用に向いている」と言ったのは、万が一にもバックアップファイルが壊れた場合にも復原可能性があるということです。 圧縮率だけをみれば xz が高く、圧縮速度では lz4 が速いです。xz は圧縮率が高いので、 Linux カーネルソースコードの配布にも用いられています。

しかしともあれ、手作業だと大変です。しかも、変更された部分を検知して追加バックアップをする(インクリメンタルバックアップ)というのが困難です。

バックアップ専用ソフトウェア

そこで、アーカイブや圧縮に対応したバックアップ用ソフトウェアを使うと容易になります。

また、バックアップ先をどこに保存するかということが問題です。

手元のHDDやBD-Rにでもバックアップするのなら物理セキュリティの話ですが、災害に非常に脆弱だという欠点があります。紛失しても大変ですが、火災などで破損したら全滅です。

インターネット上の、Dropbox とか MEGA とか Amazon Web Service S3 とか Google Cloud Storage とか、さくらのレンタルサーバ スタンダードプランで scp とか、もしかすると マイクロソフト OneDrive とか Azureという人も居るかもしれず頭の痛いところです。 転送は TLS で暗号化されても、バックアップ先のサービスに全幅の信頼を置くのか、そもそもパスワードとか秘密鍵とかそのまま保存してはいけません。

いずれにせよ、暗号化は重要です。

つまり、インクリメンタルバックアップ対応で、圧縮と暗号化が可能なバックアップソフトウェアが良いということがいえます。 それを見つけるのに ArchWikiには、便利な表があります。

また、バックアップしたけど必要なときになって戻せるのか、想像してみますと、ちゃんとメンテナンスが活発に続いているソフトウェアでないといけません。

そこで私がここで採り上げるのは、duplicityBorgBackup です。 いずれも、圧縮対応、暗号化対応、メンテナンスが現在も活発です。

duplicity

duplicity は、圧縮は gzip 、暗号化は GnuPG です。つまり、tar/gz/gpg の3つを通したファイルが出力されます。 この特徴は利点でもあり欠点でもあります。 gzipGNU の標準的な圧縮ソフトウェアです。しかし圧縮率はそう高くありません。取り立てて速いわけでもありません。 GnuPG は、公開鍵暗号方式で、強力だと一般的にはいえます。しかし、利用可能にするまでの設定作業が別途に必要です。また、秘密鍵の保管が必要で、盗まれないように取扱注意でもあります。

Dupulicity の強みは、多くのオンラインストレージに対応していることDUPLICITY(1) manual page

それと、GUI フロントエンドもつくられています。(あまりおすすめはしませんが)

BorgBackup

BorgBackup、簡単には「Borg」ですが、

Borg の特徴は、リポジトリを作成してそこに追加していくところです。そのため、複雑で習得するまで苦労すると思います。 また、ローカルに保存するか、SSH で転送するかの2つにしか対応していません。他のオンラインストレージには対応していません(自力でアップロードすればいいのですが、手間省けてませんし)。

もうひとつ、重大な特徴は、保存先のシステムにも Borg をインストールすること(サーバ・クライアント方式)。 それが不可能な場合には、sshfs でマウントしてローカルのファイルシステムのように扱うという代替策が提案されています。 Borg - Quick Start - Remote repositories この点を考えると、さくらのレンタルサーバSSHログインを利用してバックアップするのにも難ありかもしれません。(「さくらのVPS 1G」(HDD 100GB)にでもすればいいんですが…)

結論

オンラインストレージを活用するなら duplicity。Google Cloud Storage とか AWS S3 とか Dropbox とか等々使えます しかし圧縮が gzip しかない。暗号化が GnuPG なのは利点にも欠点にもなります

Borg は、圧縮率重視にも、圧縮速度重視にも設定可能。共通鍵方式なので扱いやすい。しかしリモート保存が SSH のみ。リポジトリ式は便利だが、習得までに苦労が要ります