Tips: ハードディスク操作のまとめ

Last-modified: 2015-08-23 (日) 19:01:41

(2015-8-23)特に新しいネタではありませんが少しTipsを：USBメモリや(micro)SDカードとかを買うと、初期状態で開始セクタが8192の1パーティションに切ってあることが多いと思います。これは# fdisk -H 64 -S 32 -u=cylinders /dev/hoge で開始シリンダ番号を5とした場合にあたります。そのデバイスに自分で新規にパーティションを切る(マルチパーティション化する等の)場合もこれに準じて下さい。8192=64*32*4なので、このデバイスの場合、全てのパーティションの開始シリンダ番号は# fdisk -H 64 -S 32 -u=cylinders で作業する際、4で割り切れる値+1にすべきです。無駄な読み書きを減らしてパフォーマンスや寿命を保つ為に必要なTipsです。
(2015-8-1)既に他のページに書いていますが、Windows 10も少なくとも従来型(MBR形式、Legacy)パーティションテーブルを使用する場合においてブートに関してWindows 8.1以前と異なる点はありません。
次に前に少し書いたことのあるクセの強いEaseUSの無料製品(Partition Master, Todo Backup)について私なりの利用のルールを書いておきます。（１）同社製品を使う場合、(従来型)パーティションテーブルのH値, S値 は(255,63)と(64,32)の2種類に限定する（２）(255,63)を用いる場合は「SSDに最適化する」欄があればそこにチェックを付けない、(64,32)を用いる場合は「SSDに最適化する」にチェックを付ける　です。
間違え易い点は、(64,32)のバックアップ元をバックアップしたファイルを同じパーティションにレストアする際であっても明示的に「SSDに最適化する」にチェックを付けないといけないことです。
(2013-2-5)Windows 8に関しては、少なくとも従来型のパーティションテーブルを使用した場合にはWindows 7以前と根本的な違いはないことは確認していますが、特にここに書けるほどの検証はまだおこなっておりません。
(2012-10-14)本ページに関して、アップツーデートしたい、と思っていることをメモしておきます。
SSDに引越しする場合に“用意した方が好ましい”、“ファイルシステムを理解するツール”として、“曲がりなりにも”おすすめできるのは今のところ「Acronis True Image」（だけ）です。「EaseUS Todo Backup」に一応「optimize ssd」機能はありますが、私の満足するものでは全くありません。「EaseUS Todo Backup」はパーティションテーブルを決まった形式に勝手に書き換えてしまう問題が一向に修正されません。
(2012-10-23)アップツーデートしたい、と思っていることの追記です。下で“Windows上ではrobocopyが定番”と書いているところがありますが、ここんとこ私はrobocopyじゃなくてEzExpExを使用しています。
あと、このページの熱心な読者なら当然のことと理解して頂けると思いますが、私はAFTのHDDにXPをインストールする場合でもAlign Utilityを使用したりしません。事前にアライメント調整が必要ないようにパーティションを切っておくからです。
しかしせっかく事前に作成したパーティションを無視してしまう国内大メーカーのリカバリーCDがあったりします。そんな場合の修正作業に私が使用するのが「Acronis True Image」です。

初出 2006-8-18
最終更新 2014-5-9
(2013-2-28)XP、VistaマシンでSSDを、内容を保持したままリフレッシュする手法を追加しました。
(2009-5-6)SSDを使用する際の重要なTipsを追加しました。
(2010-5-15)Windows 7に関する記述内容を修正しました。
 

(2007-9-11) 寄せられたメール等で閲覧者の方々が何を求めているかがわかってきましたので、再構成します。
タイトルを「ハードディスク操作のまとめ」としていますが、以前からこのページでも「ハードディスク操作」関連の話題を扱っています。よろしければご覧下さい。さらにはこちらも　←マルチブートするなら

 

本ページの内容を柔軟に理解する為に、
ネットワーク越しのバックアップテクニックを知っておくことを推奨します。

タイトルに"まとめ"とありますが、他の方のページに書いてありそうなことは載せていませんので、今のところ項目は少ないです。

[tip]XP、VistaマシンでSSDを、内容を保持したままリフレッシュする手法(Windows 7が必要)

多分ご承知のとおり、XP, Vistaはtrim非対応なので、SSDの運用に適していません。少々難があると言ってもいいかもしれません。

 

このような環境でも、(1)当該パーティションの空き領域を常に比較的大きく保つ(例えば最低でも常に10Gバイトの空きを確保する)、(2)定期的(例えば数ヶ月毎)に空き領域をWindows 7を用いてリフレッシュする、という手法をとることで、事実上全く問題なく運用可能です。

 

なんか一般には、「XPでSSDを使うなら、定期的に『Secure Erase』の使用が欠かせない」という“常識”が罷り通っているようですが、「Secure Erase」の使用はあまりにハードルが高すぎると思います。それに対して、この項で紹介する手法ははるかに簡単に、短時間に(頻繁に)実行可能です。

 

ここでの「空き領域をWindows 7を用いてリフレッシュ」とは、空き領域をテンポラリーなファイルで一旦埋め、それをWindows 7上で削除する作業のことです。これによって空き領域がtrim命令発行により開放され、SSD内のNANDフラッシュの使用領域の偏りを是正することができます。

 

空き領域に一時的にファイルを作成し、ゼロ埋めするvbsスクリプト
ダウンロード　fileFillZero.vbs　　このvbsファイルの中身はこのページに2006年から掲載、ここでは1行だけコメントアウト

 

XPやVistaと同一マシンにWindows 7や8をマルチブートでインストールしている場合はただ単に、そうしたOS上で上掲のようなスクリプトを実行するだけで済みますが、そうじゃない場合には代わりに、Windows 7のPE上で上掲のようなスクリプトを実行すればいいでしょう。そこで、

 

Windows 7・PE(32bit)のwimにスクリプティング環境を追加するバッチファイル(WinPe-tch Direct用)
ダウンロード　fileadd-scripting-environment.bat　　2013-2-28初出
使用する為にはAIK 3.0をインストールしておく必要があります。

 

Windows 7・PE上でSSDのリフレッシュ作業時に実行すべきバッチファイル
ダウンロード　filefill.bat　　2013-2-28初出
中身は「cscript.exe FillZero.vbs」と1行書いてあるだけです。

 

「SSDのリフレッシュ機能を持ったWindows 7・PE(32bit)」の作り方(概要)

  1. Windows 7(32bit)上でAIK 3.0をインストールしておきます。
  2. 「WinPe-tch Direct」を解凍します。
  3. pe_d.exeと同じディレクトリにこの項掲載の3ファイル、add-scripting-environment.bat、FillZero.vbs、fill.batを置きます。
  4. 「WinPe-tch Direct」を管理者権限で実行し、wim作成前に作成プロセスを一旦停止(そういう設定があります)させます。
  5. add-scripting-environment.batを管理者権限で、pe_d.exeと同じディレクトリで実行します。
    ※このまま作成プロセスを再開すると、mountディレクトリ直下にWindowsディレクトリが残ったままになります。これは実は不要です。対応策は様々あります。適宜処置してください。Windowsの一般的な知識の問題なので詳しい説明は省略します。
 

「SSDのリフレッシュ機能を持ったWindows 7・PE」上でのSSDリフレッシュ作業
「WinPe-tch Direct」でPEを作成した場合、コマンドプロンプト起動用の専用ボタンがあるので、それをクリックし、「fill」＋「Enter」するだけです。
(2014-4-14追記(訂正)久しぶりにこの節の手法を実践しているPC(XP, Linux, 7のPE、のマルチブート)のPEを立ち上げてSSDのリフレッシュ作業をおこなってみたところ、正しいコマンドは「fill」＋「Enter」じゃなくて「FillZero.vbs」＋「Enter」でした。「fill.bat」は不要でした。

 

補足
Windows 7登場当初、「trim命令はIDE接続では働かない(発行されない)」等の噂が流れたことがありましたが、これは(少なくとも私が現在確認する限り)事実ではありません。この項で紹介している手法はIDE接続のSSD(IDE-mSATA変換アダプタ+mSATA・SSD等の環境も含む)でも実施可能です。現実に私自身がそのような環境で運用しています。

 

この項で紹介している手法で、XPやVistaでも事実上、問題なくSSDの運用が可能なのですが、もちろんtrim対応のOSでの運用と較べてSSDにかかる負荷が同じではありません。こうした環境で少しでもSSDの寿命を伸ばしたい人は、大きなファイルの削除や大量のファイル削除を、上記のPE上からおこなうようにすればいいでしょう。ただし、そんな涙ぐましい努力をするよりも普通は、常日頃ラムディスクを適切に使用する方がはるかに寿命の延長効果は大きいでしょう。

 

「この項の手法にはWindows 7が必要」と掲げているのですが、厳密にはWindows 7は必要ない可能性が高いと思われます。まずXPのfsutil.exeはWindows 7カーネル上で動くでしょう。また、PEへのスクリプティング環境の追加は、add-scripting-environment.batのようにAIKインストール済みの環境を利用しなくても、直接cabファイルからdimコマンドを抽出することで可能だと思われます。私はPEに関する知識が乏しいので安易にWindows 7を利用する手法を紹介しています。

 

Windows 8のPEはNX、SSE2が必須なので古いPCでは動作しないケースが多いようです。
(2013-4-20追記)
Windows 8に、W8用のADKではなくW7用のAIK3.0をインストールし、この項の手法でPEを作成して動作確認してみましたが、W8とW7のfsutil.exeに互換性がないらしく、FillZero.vbsの11行目でエラー終了となりました。

[tip](こんなのがありました)論理4kバイト/セクタ(AFT)のHDDを論理512バイト/セクタのUSB3.0/2.0接続(レガシー仕様)HDDに変換するアダプタ

(2014-5-9)この件、恥ずかしながらどのような環境で確認したのか、失念してしまいました。再確認をおこなうまで消させて頂きます。

[tip]UEFIブートのWindowsを同一ハードディスク上にコピー……

(2013-4-6初出)
この項のUEFI版(GPT版)といった趣のものを実現する手法を短時間(手持ちの環境じゃなかったので)、探ってみました(完成してません。途中経過の報告です)。

 

先に書いておきますが、得られた結果は事前の予想通りで、わかっている人にとって目新しいものは何もありません。ただし一応ここに記述しておけば、中には価値を感じとる方も出てくるくらいの内容だとは思います。

 
 

とりあえずはおこなった手順を箇条書きするだけにしておきます。

 
  1. EaseUS Partition Masterを用い、Windows 8 64bitのCドライブ・パーティションを前詰めで半分以下のサイズに縮小(後ろに未使用領域ができる)
  2. Acronis True Image試用版を用い、同パーティションを別HDDにバックアップ
  3. Acronis True Image試用版のブータブルCDを用い、バックファップを前述の未使用領域にレストア
  4. EaseUS Partition Masterを用い、レストアで作成されたパーティションにドライブレターを付与
  5. EasyBCDを用い、ブート時に使用するwinload.efiをCドライブのものから、新しいパーティションのものに切り替える
 

上記手順実行後にブートすると、新しいパーティションからブートした上で元のCドライブがCドライブになります。

 

もちろん本当の目的は、新しいドライブがCドライブになることです。そうならないのは、レストアで作成されたパーティション内のレジストリファイルが新たな環境に合った内容に書き換えられていない為です。

 

同様の問題をMBRパーティション＆レガシー・ブートの場合は、直接レジストリファイルを書き換えるのではなく、「NTシグニチャのクリア」をおこなうことで解決していました。多分、「MicrosoftはGPTの場合にも同様の仕様を用意しているのではないか？」と想像しています。それを誰かに見つけ出してもらいたいところです。私自身はここしばらくはこの課題を調査する予定はありません。

ハードディスクの引越し

Windowsシステムパーティションを含むハードディスク丸ごと引越す簡単な方法

旧HDDと新HDDを１台のPCに同時に接続して直接のコピーをおこなう場合や、一旦旧HDDのデータをネットワーク越しに保存しておき、その後に新HDDにネットワーク越しにデータを書き込む場合等、様々な手法が考えられますが、ここに記す基本は普遍です。自分の環境に合わせて適宜読み替えて下さい。

 

「新HDDの容量 ≧ 旧HDDの容量」が成立する場合、メーカー、型番に関係なく

# dd if=/dev/sda of=/dev/sdb bs=1M

みたいな操作で丸ごとの引越しがおこなえます。(デバイス名や、手法は適宜読み替えて下さい。)
この操作で、全ブートローダ、パーティションテーブル、全パーティションの中身、NTシグニチャ等、全てがコピーされます。
HDDデュプリケーターや多くのHDDクローンソフトの内部でやっていることと同じです。

 

この操作後、新HDDを旧HDDを常用していた際と同様に接続すれば、新HDDを旧HDDと同様に使用できます。
(但し勿論この方法では「新HDDの容量 ＞ 旧HDDの容量」の場合に新HDDの一部が使用されていませんので、後で何らかの修正を施すべきでしょう。)
(2010-1-2追記)旧HDDにSUSE Linux(openSUSE等)が含まれていた場合、多少の追加作業が必要となることはSUSEユーザであれば気付くことでしょう。パーティションの識別には/dev/disk/by-id/･･･形式ではなくUUIDを利用することをお薦めします。

 

お薦めはしませんが、「新HDDの容量 ＜ 旧HDDの容量」の場合でもこの方法が全く役に立たないわけではありません。どんな場合に意味があるのかわかる方は実践してもいいと思います。

 

蛇足かもしれませんが、上に示した構文は、内臓ハードディスク(PATA,SATAを問わず)からUSB接続ハードディスク、あるいはその逆方向の作業の場合にも使用できます。ただしコピー先からのOS起動にはちょっとした追加作業が必要な場合があります。

 

(2007-12-12追記) 上のddコマンド使用例に、「bs=1M」と、ブロックサイズの指定を追記しました。ddコマンドでギガバイトクラスのディスク領域を操作する際は処理速度向上の為に通常はブロックサイズの指定をおこないます。当サイトの他のページでもddコマンドの使用例を載せていますが、説明する上でブロックサイズ指定が必要な場合以外は記述していません。適宜自分で補って使用して下さい。この章は普段unix、Linux使いではない人も読むことが多いと思うので書いておいたほうがいいと思って追記しました。「bs=1M」は私が日頃使う値です。
(2008-1-9追記) このやり方はWintel(x86) PCだけではなく、PPC Mac でも使えます。例えばPPC MacでPPC版knoppix-MiBを起動し、Macのハードディスク全体をddとsshででWintel PCのLinuxサーバにバックアップすることができます(参考)。そのMacのハードディスクが壊れた場合は、Wintel PCのLinuxサーバ上で、保存していたディスクイメージを新しいハードディスクに書き込み、そのディスクを壊れたディスクの代わりにPPC Macに取り付ければ復旧完了となります。ただしPPC Mac上でこのやり方をするとベリファイができません。あと、もちろんバックアップ直前に一旦ゼロ埋め(関連:Windowsでのゼロ埋め)しておくと圧縮率が稼げます。OS Xなら簡単にゼロ埋めできます。

Windowsシステムパーティション別のハードディスクに引っ越す場合のポイント

「Windowsシステムパーティション」だと特定している理由は、この移行が条件的に最も厳しいからです。ddやfdisk等、GNUのツールのみで(単純なイメージのコピーによって)引っ越す場合、新HDDの当該パーティションは旧HDDの当該パーティションと全く同じ開始位置、大きさにする必要があります。

※: 後でPBR修復(正確にはPBRレストア)やfixbootで修正することを前提にすれば開始位置はずらすことができます。

 

具体的には、
旧HDDのパーティションテーブルをfdiskコマンドで見たときに

Disk /dev/sda: 40.0 GB, 40007761920 bytes
64 heads, 32 sectors/track, 38154 cylinders
Units = シリンダ数 of 2048 * 512 = 1048576 bytes
デバイス Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1       19074    19531760    7  HPFS/NTFS
                    ・

と、↑こんな感じであったなら、

新HDDのパーティションテーブルをfdiskコマンドで見たときに

Disk /dev/sda: 251.0 GB, 251000193024 bytes
64 heads, 32 sectors/track, 239372 cylinders
Units = シリンダ数 of 2048 * 512 = 1048576 bytes
デバイス Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1       19074    19531760    7  HPFS/NTFS
                    ・

と、↑こんな感じである必要があるわけです。(ハードディスクの容量以外は皆同じ)
※: この説明では旧HDDと新HDDのデバイス名が同じになっていますが、作業方法によっては作業中のデバイス名が両者で異なる場合があります。


旧HDDと新HDDで「heads」と「sectors/track」の値を合わせるために、新HDDに対してfdiskコマンドを起動する際にオプションを加える必要がある場合があります。
例

# fdisk -H 64 -S 32 /dev/sda

※: -H、-Sオプションの使用に際してハードディスクのメーカー名、型番を考慮する必要はありません。

リカバリ領域を生かしたまま、今より大容量のハードディスクに引っ越しする場合

リカバリ領域の仕様は各社によって様々ですが、(1)実はファイルシステムとしてFATかFAT32かNTFSのいずれかを使用したパーティションになっていて、(2)Windowsに自動的にマウントされないようにそのパーティションIDをパーティション本来のものから別のものに変更している、という共通点があります。

 

それぞれの場合に即した方法はここに書きませんが、このページおよび当サイトの様々なページに書かれた方法を駆使すれば、古いHDDの末尾にあったリカバリ領域も、新しい大容量HDDの末尾にリカバリ機能を保ったまま引越しさせることが可能です。

fdiskの使い方Tips

上で触れましたが、fdiskコマンドを-H、-Sオプション付きで起動しなければならない場合があります。

 

※: fdiskコマンドは、、パーティションテーブルから得た情報を最優先に扱って「heads」と「sectors/track」の値を推測します。一旦一つでもパーティションを作成した後は-H、-Sオプションを指定する必要はありません。(パーティションの境界が統一されていない場合は除く)

 

「heads」と「sectors/track」の値は、
「255,63」、「16,63」、「64,32」の組み合わせが使用されることが多いと思いますが、
使いたければ(一部のマザーボードを除けば)「16,32」、「32,16」、「16,16」、「32,32」等も使用できます。
但し「32,16」、「16,16」ではMBRと第一パーティション開始位置と間のスペースが小さくなり過ぎ、MBMを使用することが出来ません。MBM以外のツールにも使用できないものがあるでしょう。

 

このあたりの参考資料となる私の作成したシェルスクリプト

 

※: 太線部の補足がこのページのもう少し下の方にあります。

SSDを使用する際の重要なTips

SSDは内部的にはHDDと異なり、セクタ単位ではなくページ単位でしか書き込みがおこなえません。ページサイズは「セクタサイズ Ｘ 整数(いまのところ4～128程度)」バイトです。消去もブロック単位でしかおこなえず、ブロックサイズはページサイズの整数倍です。従って「heads」と「sectors/track」の値としてHDD用の標準的な値である「255,63(2のべき乗の約数になりえない数)」を採用してSSDを使用すると、書き込みサイズとページ境界やブロック境界とが一致せず、もともと非効率なSSDへの書き込みに更に常に無駄な書き込みが必要となり、パフォーマンスが低下してしまいます。

 

SSDの場合は出来る限り「heads」と「sectors/track」の値として「64,32(あるいはそれに類する値)」を使用するべきでしょう。
つまり# fdisk -H 64 -S 32 /dev/sd？を実行すべきです。Vista，7以外のOS(XPやLinux等)を新規インストールする前なんかに特に推奨します。Vistaや7の場合もインストーラに勝手にパーティションを作成されないように、事前に# fdisk -H 64 -S 32 /dev/sd？でパーティションを作成しておくことをお薦めします。

 

「255,63」以外の値を採用すると「255,63」に決めてかかっている一部のOS(Solarisなんか)で問題が生じたりするのでそれなりに注意が必要です。

 

Windows Vista，7では、新規にパーティションテーブルを確保する際に標準で「255,63」とは異なる値が使用されるという情報もありますが、現在Windows VistaがプリインストールされているPCでは様々な事情から「255,63」が採用されていると思います。そんな場合にHDDからSSDへの引越しをおこなう際は丸ごとの引越しはおこなわずに、SSDには新規にパーティションテーブルを作成することを推奨します。その場合データの移行はddコマンドではおこなえず、ファイルシステムを理解するツール・OSを使っておこなう必要があります。この場合のNTFS(※1)システムパーティションの移行にはバックアップ用のソフト等を使い(※2)、NTFSデータパーティションの移行(※3)にはWindowsのエクスプローラ(※4)を使用すればいいでしょう。
このような場合にMBRをどう移行するかですが、当サイト内には多くのこれに関したページがあります。ここ，ここ，ここ等。もしWindowsしか、それも一つしかインストールしていない環境の移行であればここの情報なんかが役に立つかもしれません。

  • ※1 Linuxのext3パーティションの場合にこのような移行は特に難しくありませんが、ブートパーティションの場合には移行先の環境にブートローダをインストールする必要があります。この辺りについてはこことかここに情報(やり方)が載っています。
  • ※2 一旦ddコマンドで従来のH,Sのままで丸ごとコピーした後にパーティションソフトを使って新しいH,Sに更新することもできます。
  • ※3 Administratorしかユーザがいないシステムパーティションなんかの場合には起動していなければエクスプローラでコピーがおこなえます。
  • ※4「フォルダの更新時間が変わってしまうのが気になる人はrobocopyを使う」というのが定番ですが、私のやり方ではエクスプローラでコピー後、シェルスクリプトでコピー元から"更新時間だけを"コピーします。


※誤解のないように念のため書いておきますが、上記のデメリットを許容できれば別に丸ごとの引越しをやっても問題ありません。
(2010-12-12追記)ある程度熟練者には言うまでもないことなんですが、私はフラッシュデバイスの場合、H,Sの値の指定に加えて、必ず第一パーティションを二番目の(論理)シリンダから開始させています。この手法自体は他の利点のためにハードディスクにおいても私が昔から実践している方法ですが、フラッシュデバイスの場合にも役に立ちます。
ちなみに、ここに書いたやり方を実践するとfdiskの使い心地が悪くなります。私の場合はfdisk歴・十数年なので平気ですが。
(2013-2-5追記)直上の2010-12-12の追記の内容を大幅に削除しました。削除した部分は記述直後から「間違ってるぽいな」と思っていましたが「どうせマニアックすぎて99.9％の人は読まないから」と放置していました。申し訳ありません。
あと、最近、Ubuntu 12.04 LTSのfdiskを使用したところ、デフォルトで二番目のシリンダから第一パーティションを開始する仕様に変更されていることに気づきました。まあ当然の変更でしょう。私が十数年前から実践している手法をようやく取り入れてくれたという感じです。直上の「ここに書いたやり方を実践するとfdiskの使い心地が悪くなります」との記述は、最新のfdiskコマンドの場合には当てはまらないことになります。

Windowsを同一ハードディスク上にコピーしてマルチブートを実現する方法

(2009-7-9)サイト開設以来「イメージでパーティション間コピーをおこなうことを考慮したハードディスク使用法」というコーナーでしたが、もっと具体的な内容に改めます。

 

マルチブートの方法自体はマルチブートするなら２段階ブート方式に統一しようにありますので、ここではWindowsシステムドライブを、動作する状態を保ったままコピーする方法を既述します。この方式は２段階ブートを採用することを前提としています。

 

OSのインストール順・再インストールが自由なマルチブートの方法の(簡素な)リニューアル版といった感じです。

 

(2009-12-5追記)所詮下記の方法は熟練者のみがおこなうニッチな方法だと思います。Windows複数を含んだマルチブート環境を構築する場合、殆どの方は構築したいWindowsの数だけ実際にWindowsのインストール作業をおこなうと思います。その場合のとても大事なポイントをお伝えしておきます。Windowsのインストーラーを立ち上げる前に、これから新しくWindowsシステムをインストールするパーティションをアクティブにして下さい。Windowsを一環境インストールする度に忘れずにです。こうすることによって各Windowsのブート環境が独立し、管理がし易くなります。これはライセンス・ポリシー上マルチブートに非協力的なマイクロソフトが長年決して教えないことです。そのマイクロソフトの意に添って提灯ライターの書いた七面倒くさいWindowsのマルチブート方法が長年一般的とされてきました。私自身は十年以上前から２段階ブートに統一してきましたが、世間ではその手法がなかなか一般的にならないので、とうとう３年前に自分でこのページを作ったわけです。
パーティションをアクティブにする方法は様々あります。MBMがインストールされている場合はMBMでも可能です。MBMのメニュー画面で今からインストールしたい基本パーティションを選び[Enter]すればそのパーティションははアクティブになります。もちろんそこにはまだOSは入っていないでしょうから起動できないエラーになります。でもそれでいいんです。そのまま次にWindowsのインストーラーを立ち上げればいいんです。
「Vista以降、Windowsのブート形式が変わったからWindows同士のマルチブートのやり方も変えなくちゃいけない」との認識が多いようですが、実際には、上に書いたことを守り、必然的にMBM等を使うことになれば、BCDの編集もboot.iniの編集も必要ありません(ただし下の裏技では必要です)。

概要

新しいハードディスクにパーティションを確保するところから初め、Windowsを１度だけインストールし、あとはそれを２回コピーして同じ構成のWindowsが３つのマルチブート環境を実現する例を示します。環境構築後はブートさせたパーティションがその都度Cドライブとなります。

 

ここに紹介する手法で構築した環境は、各パーティションのブート環境が独立しています。
従って例えばコピー元パーティションをゼロ埋めしてもコピー先パーティションのWindowsは何事もなかったように起動します。

(1) Windowsマルチブート用パーティションの確保

（Linux上の作業）

 

ここではWindowsやWindows PE以外のOSを使ってWindowsシステムパーティションをコピーする方法を示したいと思います。となると普通に考えればUNIX、Linux系汎用のddコマンドによるイメージ形式のコピーとなります。イメージ形式でのパーティションのコピーでは、コピー元・コピー先となるパーティションの大きさを一致させることが必須です。

 

普通にfdiskコマンドを使って第１パーティションと第２パーティションで同じシリンダ数を指定して同じ大きさを確保しようとすると意に反して第１パーティションと第２パーティションでは異なった大きさが確保されてしまいます。

 

この原因は第１シリンダの先頭数十セクタが、MBRとそれに続く領域用に確保されてしまっているので、第１パーティションの大きさが「１シリンダの大きさｘシリンダ数」よりも小さいからです。
※このあたりの参考資料となる私の作成したシェルスクリプト

 

この問題を回避して第２(以降)のパーティションと完全に同じ大きさの第１パーティションを確保する為に、第１パーティションを第２シリンダから開始するように指定します。

 

一例ですが、こんな感じにパーティションを確保します。

# LANG=C fdisk -l /dev/sda
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x43c6caee
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1    *          2        2297    18442620    7  HPFS/NTFS
/dev/sda2            2298        4593    18442620    7  HPFS/NTFS
/dev/sda3            4594        6889    18442620    7  HPFS/NTFS
/dev/sda4            6890       60801   433048140    5  Extended
/dev/sda5            6890        7053     1317298+  82  Linux swap / Solaris
/dev/sda6            7054        8456    11269566   83  Linux
/dev/sda7            8457       60801   420461181    7  HPFS/NTFS

・第１～第３パーティションの大きさが完全に同じです。
・第１パーティションにはWindowsのインストーラを使ってWindowsをインストールし、それを第２・第３パーティションにコピーする予定です。
・(この章の内容に直接関係ありませんが)第４パーティションは拡張パーティションで、第５以降はその中の論理パーティションです。
第１パーティションを第２シリンダから開始させています。
fdiskコマンドのインターフェースで第１パーティションを第２シリンダから開始するように指定すると、それ以降のパーティションの追加時にfdiskコマンドは使われていない第１シリンダを何とか使わせようとしつこくデフォルト表示してきますが、それを都度無視する必要があります。
第１パーティションをアクティブに指定しています。

 

Debianのように標準のインストーラではfdiskのインターフェースを隠して表示する場合、上に書いたようなパーティション割りをおこなう為には、[CTL]+[ALT]+[F？]でコンソールに一旦下りて、手動でfdiskコマンドを使用する必要があります。他のディストリにもこのような操作が必要なものがあります。

 

※以降で説明しますが、上記のようにパーティションを確保すると第１パーティションから第２パーティションへddコマンドでコピーがおこなえます。その後ちゃんと第２パーティションから正しく全データを読み出せます。ただしコピーしただけの状態では、コピー先のPBRは壊れたとみなされる状態なのでそのままではブートはできません。この問題の対処には以降の手順が大切です。

(2) Windowsのインストール

(1)で第１パーティションをアクティブにしたのでWindowsのインストーラは第１パーティションをCドライブとして認識します。そのCドライブにWindowsをインストールして下さい。もしアクティブなパーティションを第３パーティションとしたなら第３パーティションにインストールして下さい。

(3) 残りのパーティションのフォーマット

（Windows上の作業）

 

Windowsをインストールしていない２つのパーティションを、(2)でインストール済みのWindows上でNTFSフォーマットして下さい。

 

(2009-12-26追記)PBRのWindowsの種類別の互換性についてですが、厳密に検証してから書こうと思っていたのですが、面倒なので省略し、知っている範囲で、必ずお伝えしなければならない大切なことを書きます。
NTFSのPBRは同じ位置・大きさのパーティションであってもWindowsの種類が違えば異なる場合があります(多分Vistaのときに変更されたと思います。このことは一般的に「NTFSのバージョンが違う」と表現されます)。従って本手順のように正しいPBRを得る目的でフォーマットをおこなう場合、「フォーマットする側のOSはコピー先でブートさせようとしているOSと同じ種類のOSである必要があります」。つまり例えば第一パーティションにVistaとか7, 第二パーティションにXPがインストールされていて、第二パーティションのXPを第三パーティションにコピーしようとする場合、第三パーティションのフォーマットを第一パーティションのVistaとか7でおこなってはいけません。第二パーティションのXPでおこなわなければなりません。

(4) 残りのパーティションのPBRのバックアップ

（Linux上の作業）

 

(3)でフォーマットした各パーティションの先頭セクタ(PBR)と末尾のセクタ(PBRのバックアップ)をバックアップします。

 

NTFSパーティションの先頭セクタ(PBR)のバックアップをこんな感じでおこないます。

# dd if=/dev/sda2 of=/somewhere/sda2-pbr-bkup.img count=1

もちろんコピー先として確保した２つのパーティションの両方でおこなって下さい。

次にNTFSパーティションの末尾のセクタ(PBRのバックアップ)のバックアップをこんな感じでおこないます。

# /somewhere/extract-backuped-pbr.sh /dev/sda2

もちろんコピー先として確保した２つのパーティションの両方でおこなって下さい。
この際、画面に出力されるskipsectorsの値をメモっておいて下さい。
extract-backuped-pbr.shはここにあります

 

※自分の作業環境に合わせて適宜デバイス名は読み替えて下さい。

 

参考(サイト内関連ページ)：強力な(?)NTFSのPBR修復法

(5) パーティションのコピー

（Linux上の作業）

 
# dd if=/dev/sda1 of=/dev/sda2
# dd if=/dev/sda1 of=/dev/sda3

※自分の作業環境に合わせて適宜デバイス名は読み替えて下さい

(6) コピー先パーティションのPBRレストア

（Linux上の作業）

 
# dd if=/somewhere/sda2-pbr-bkup.img of=/dev/sda2
# dd if=/somewhere/sda3-pbr-bkup.img of=/dev/sda3
# dd if=dd if=/somewhere/backuped-sda2-pbr.img of=/dev/sda2　seek=「(4)のskipsectorsの値」
# dd if=dd if=/somewhere/backuped-sda3-pbr.img of=/dev/sda3　seek=「(4)のskipsectorsの値」

※自分の作業環境に合わせて適宜デバイス名は読み替えて下さい
※もちろん当該NTFSファイルシステムに障害がなければ、パーティションの先頭セクタ(PBR)と末尾のセクタに差異はありませんから作業する内容は適宜変更して下さい。

(7) BCDもしくはboot.iniの修正やNTシグニチャのクリア等

Windows 7, Vista, Server 2008 の場合

【BCDの修正(修正、再構成)】
少々複雑な手順を踏みますので途中まで読んで早合点して作業しないようご注意願います。
位置をずらしたパーティション用のBCDを生成する作業は面倒です。
順番を間違うと(5)の作業からやり直しとなる作業も含まれます。

 

1. (Windows上の作業)
コピー元パーティションのWindowsにEasyBCDをインストールします。

 

[Diagsnostic Center]ボタンを押します。
hduse_1_s.png

 

[Reset BCD Storage]を選び、[Rescue my System!]ボタンを押します。
hduse_2_s.png

 

BCDを修正したいパーティションが割り当てられているドライブを選び、[OK]ボタンを押します。
この際選ぶドライブは必ずC:以外の筈です。
hduse_3_s.png
※:この処理中にMBRのブートローダがWindows純正のもので上書きされています。
この時点ではまだ我々の目的とする状態にまでBCDは修正されていません。
現在起動しているOSが、修正したいパーティションのBootManagerを介して起動する状態になっています。

 

このまま現在起動しているOSを再起動します(ブート時にメニューが出ないことでMBRが上書きされたことが確認できると思います)。この時点でのコピー元OSの起動は一見省略できそうな気がしますが、絶対に省略できません。

 

起動後「ディスクの管理」画面を参照すると、先ほどBCDを修正したパーティションがブートパーティションになっていることが確認できると思います。

 

もしコピー元パーティションに「ボリュームネーム」を付けていた場合はこの時点ではコピー元・コピー先共に同じ「ボリュームネーム」となっています。この時点でコピー先パーティションの方の「ボリュームネーム」を何らか別のものに変更しておくことをお薦めします。
BCDはまだ我々の目的とする状態に完全に到達したわけではありませんが、かなり近づきました。

 

2. (Linux上等での作業)
ここでマルチブートマネージャー(MBM等)を再インストールしましょう。
私ならPXEブートのMinimum Ubuntuを使って素早くMBMを再インストールします。
この時点ではコピー元のパーティション、BCDを修正したパーティションのどちらのパーティションから起動してもコピー元のWindowsが起動する状態となっています。

 

3. (Linux上等での作業)
次にNTシグニチャをクリアする必要があります。
私ならMBMを再インストールする際にMinimum Ubuntu上で一緒にやってしまいます。
またこの時点でコピー元パーティションがアクティブであることを確認して下さい。

 

4. (Windowsインストールディスク上での作業)
次はコピー元パーティションの「スタートアップ(環境の)修復」です。
Windowsインストールディスクもしくは作成済みであればWindowsインストールUSBメモリを使用しておこなって下さい。
この作業の前にコピー先パーティションのPBRをクリアしておくことをお薦めします。これをやっておけばコピー元パーティションのブートメニューに勝手にコピー先パーティションのエントリーが追加されることを防げるからです。この作業がここでは省略することが可能なのは、コピー元パーティションがコピー先パーティションよりハードディスクの先頭に近いからです。逆の場合には省略は不可能でです。←このケースは後で出てきます。無駄に追加されてしまったエントリーは後でEasyBCD等で削除して下さい。このような場合、削除すべきなのは大抵上側のエントリーになると思います。

 

「スタートアップ修復」のやり方ですが、勝手にブートメニューに要らないエントリーが追加されることを防ぐ為に、出来れば以下のようなやり方をおこなって下さい。ただしこれをおこなってもここでは一つ無駄なエントリーが追加されてしまいます。上の緑字の作業をやっておけば無駄なエントリーが追加されません。

 

システム回復オプション
Windows インストールを検出しています。

　　　　　　↓

システム回復オプション
スタートアップ オプションに問題が見つかりました。
修復を適用してコンピューターを再起動しますか？
　　　　修復して再起動するしない

で、[しない]を選び、
　　　　　　↓
次に[次へ]を選び、
　　　　　　↓
次に[スタートアップ修復]を選び、その先へ進めて下さい。

 
 

再起動時にコピー元パーティションが正しく起動出来るか確認して下さい。

 

5. (Linux上等での作業)
次にコピー先パーティションのスタートアップ修復をおこないたいのですが、その作業をする前に、一時的にコピー元パーティションをシステム回復ユーティリティから認識できなくする必要があります。これが上の緑字の部分に書いた逆のケースです。

こんな感じの作業をおこなう必要があります。

# dd if=/dev/sda1  count=1  of=sda1-pbr.img　　# コピー元のPBRバックアップ
# dd if=/dev/zero  count=1  of=/dev/sda1　　# PBRを一時的に壊す(ゼロクリアする)

この作業はコピー先パーティションよりハードディスクの先頭側にあるWindowsのシステムパーティション全てでおこなう必要があります。つまり今回の例で言えば、/dev/sda3を修復したい場合は/dev/sda1と/dev/sda2のPBRを一時的にクリアする必要があります。

 

6. (Linux上等での作業)
次にコピー先パーティションをアクティブにします。

 

7. (Windowsインストールディスク上での作業)
次にコピー先パーティションの「スタートアップ修復」をおこないます。
再びここの要領でおこなって下さい。
この作業をNTシグニチャをクリアする前にやってしまうと(5)からやり直しになります。

 

8. (Linux上等での作業)
次に先ほどPBRをクリアしたパーティションを元に戻します。

＃dd if=sda1-pbr.img  of=/dev/sda1

もちろんこの作業は先ほどPBRクリアしたパーティション全てでおこなう必要があります。

 

これで作業は終了です。
先に書きましたが、このように構築した環境では、各パーティションのブート環境が独立しています。
従って例えばコピー元パーティションをゼロ埋めしてもコピー先パーティションのWindowsは何事もなかったように起動します。

 

※:このように位置をずらせたパーティション用のBCDを生成する作業は面倒です。もし既に正しいBCDファイルをバックアップして持っていた場合は、上記の面倒な作業をやらずに済みます。代わりに当該パーティションの\Boot\BCDをバックアップしていたファイルで上書きすればいいだけです。ただしもちろんNTシグニチャをクリアした場合は「スタートアップ修復」をおこなう必要があります。

Windows XP, 2000, NT, Server 2003 の場合

【boot.iniの修正】
1. (Linux上もしくはWindows上の作業)
コピー先パーティション内のboot.iniの「partition(X)」部分(2個所)を書き換えます。

 

※次の工程が終わるまではまだコピー先パーティションをブートさせないで下さい。この時点ではコピー先パーティションをシステムドライブとすることはできません。

 

2. (Linux上またはその他OS上の作業)
次にこのツールなんかを使って、NTシグニチャをクリアして下さい。
NTシグニチャをクリアする方法は他にも多くあります。

 

これで作業は終了です。

 

MBM等を使ってコピー先パーティションをブートさせると、コピー先パーティションがCドライブ(システムドライブ)となってWindowsが立ち上がります。

 

先に書きましたが、このように構築した環境では、各パーティションのブート環境が独立しています。
従って例えばコピー元パーティションをゼロ埋めしてもコピー先パーティションのWindowsは何事もなかったように起動します。

Windiws 7 がシリンダ境界を無視してパーティションを作成することが誤解されている件について

パーティションテーブルの仕様が誤解されていることが原因となって、
「Windows 7 が全面的にシリンダ境界を無視したパーティションの割り当てをおこなう」と誤解されている面があると思います。もしこの誤解が誤解でなく事実であったなら、様々な過去のツールやOSとの互換性に問題が生じる可能性があります。
(2010-5-15追記)今回、以前におこなった調査をやり直しました。結果、以降の以前の記述内容に様々な修正が生じています。

 

実際にWindows 7 インストーラーがシリンダ境界を無視したパーティションの割り当てをおこなうのは、

「『新規にパーティションテーブル(もしくはパーティション)を作成する』場合に、
　『(サイズが丁度100Mバイト)のブート用パーティション』を作成する際 だけ」

ではないかと思われます。(ごく軽い調査なのでこのような場合だけだと確認がとれていませんが)
(2010-5-15追記)↑上記は誤っていることがわかりました。

「Windows 7 インストーラーはいかなる場合にもシリンダ境界に従ってパーティションを作成するが、
H(ヘッド)・S(セクタ)・パラメータとしてSSDにマッチした値を使用する為、旧来のツール類が対応しき
れなくて、『シリンダ境界を無視している』と誤表示する場合が多い」

ということらしいことがわかりました。

 

まあとにかく、
誤解を解きたいので、以下を見て(読んで)下さい。
(2010-5-15追記)修正後の新しい内容を読んでも、やはり誤解は解けます。
以降、"追記"との記述を一部省略します。ただしどこを修正したかは大体わかるように書きます。

 

今回前回と今回、調査の(というか誤解を解く)為、ゼロ埋めして既存のパーティションテーブルを削除し、ほぼ買ってきたばかりの新品と同様の状態に戻した40GバイトのハードディスクにWindows 7 のインストールをおこないました。

 

私が事前にパーティションを作成せずにWindows 7をインストールするのはこれが始めてでした。
事前にパーティションを作成しておいてインストール先にそのパーティションを指定すれば、Windows 7インストーラーがその境界に従うこと、もちろんシリンダ境界を無視しないこと、は過去に何度も確認済みです。

 

デフォルトに従ってインストールしました。結果、自動的に、小・大、２つのパーティションが作成され、小が"System Reserved"とボリュームネームが付けられた、ブート時だけ使用されるパーティションとなり、大がシステムパーティションとなりました。

 

インストール後、そのハーディスクのパーティションテーブルをLinuxのfdiskコマンドで見てました。

# fdisk -l /dev/sdb
ディスク /dev/sdb: 40.0 GB, 40007761920 バイト
ヘッド 64, セクタ 32, シリンダ 38154
Units = シリンダ数 of 2048 * 512 = 1048576 バイト
Disk identifier: 0xc44f5e4a
デバイス ブート     始点        終点    ブロック   Id システム
/dev/sdb1   *           2         101      102400    7  HPFS/NTFS
パーティション 1 は、シリンダ境界で終わっていません。
/dev/sdb2             102       38153    38965248    7  HPFS/NTFS
パーティション 2 は、シリンダ境界で終わっていません。

↑多くの人は(使用するツール(ソフト)は様々でしょうけど)このような表示を見て、「Windows 7 は全面的にシリンダ境界を無視したパーティションの割り当てをおこなう」と誤解しているんだと思います。でもパーティションテーブルの仕様を知っていれば別の考えも浮かぶ筈です。
(2010-5-10追記)上の画面出力に対して、このように解説するのは間違ってないのですが..

 

(知っている人には言わずもがなですが、)
fdiskや様々なGUIのパーティションテーブルを参照するツールは、シリンダのサイズをパーティションの位置から推定して表示しているだけです。ですから第一パーティションが変なパーティション開始位置から始まっていると、第二以降のパーティションが全てきっちりとシリンダ境界を守っていても、「全てのパーティションがシリンダ境界を守っていない」と誤って解釈して表示することがおこりえるわけです。ここで取り上げたケースもまさしくそのような状態です。
(2010-5-10追記)上の画面出力に対して、このように解説するのは間違ってないのですが、「シリンダ境界を守っていない」とのメッセージはfdiskコマンドの誤表示でした。

 

このような場合はパーティションテーブルを参照するツール(ソフト)に正しいシリンダサイズを教えてやればいいわけです。(2010-5-10追記)結果的にこの作業は必要なかったわけです。

# fdisk -l -H 255 -S 63 /dev/sdb
ディスク /dev/sdb: 40.0 GB, 40007761920 バイト
ヘッド 255, セクタ 63, シリンダ 4864
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
Disk identifier: 0xc44f5e4a
デバイス ブート     始点        終点    ブロック   Id システム
/dev/sdb1   *           1          13      102400    7  HPFS/NTFS
パーティション 1 は、シリンダ境界で終わっていません。
/dev/sdb2              13        4864    38965248    7  HPFS/NTFS

最も標準的なシリンダサイズ(ヘッダ=255, セクタ=63)を指定してやると、第一パーティションは相変わらずシリンダ境界に従っていないと出力されますが、第二パーティションはシリンダ境界に従っていると出力されました。
(2010-5-15追記)この画面では「パーティション2がシリンダ境界を守っている」ことになっていますが、これもfdiskコマンドの誤表示でした。

 

第一パーティションのサイズは104857600バイト、2進数で数えて丁度100Mバイトでした。これは以前から私が上に書いているSSDに適したシリンダサイズ(ヘッダ=64,セクタ=32)で丁度切りのいい100シリンダのサイズです。
インストール先がハードディスクなのに、第一パーティション(＝ブート用の小パーティション)だけは、わざわざシリンダ境界を無視してSSDに最適なシリンダサイズで作成しています。この理由を推測すると、このパーティション(="System Reserved"パーティション)は従来のWindows OS(Windows NT,2000,2003 Server)が利用することはないのである程度互換性への考慮を無視できること、ハードディスク・SSDを問わず、固定サイズにすることによってレストア等が簡略化できることなどが考えられます。
(2010-5-15追記)今回あらためて確認したところ、最初のfdiskの出力画面でfdiskコマンドが第一パーティションがシリンダ境界に従っていないと出力したのはfdiskコマンドの不具合です。fdiskに-uオプションを付けて得た生のセクタ位置を自分の手で計算してみると、シリンダ境界に従っているとの結果が出ますし、拙作のスクリプトでチェックしてみても、確かにシリンダ境界に従っている結果が出力されます。
以下は-uオプションを付けた場合の出力です。

# fdisk -lu -H 64 -S 32 /dev/sda
Disk /dev/sda: 40.0 GB, 40007761920 bytes
64 heads, 32 sectors/track, 38154 cylinders, total 78140160 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x8bd1d09f
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS
Partition 1 does not end on cylinder boundary.
/dev/sda2          206848    78137343    38965248    7  HPFS/NTFS
Partition 2 does not end on cylinder boundary.

先に書いたようにシリンダ境界に従っていないとの出力は間違いです。

2048/(64*32) = 1
((206847-2048)+1)/(64*32) = 100
206848/(64*32) = 101
((78137343-206848)+1)/(64*32) = 38052

この計算結果を見れば一目瞭然です。
全てきれいに割り切れています。

 

以上のことからWindows 7 インストーラーの仕様を以下のように類推しておきます。

  • インスール先として事前に作成しておいたパーティションをを指定した場合は、そのパーティションをそのまま使用する。
  • インストーラが新規にパーティションテーブルを作成する場合は、
    • "System Reserved"パーティション(ブート用の小パーティション, UNIXでの/bootを別パーティションとした場合に類似)は常にSSDに最適化したシリンダサイズ(ヘッダ=64,セクタ=32)で作成する
    • システムドライブ用のパーティションは、インストール先がSSDの場合はSSDに最適化したシリンダサイズ(ヘッダ=64,セクタ=32)で作成し、インストール先がハードディスクの場合はハードディスク用として通常用いられるシリンダサイズで作成する
    • (2010-5-10追記：上2行の修正版)インストール先がHDD,SSDのどちらであっても(※)SSDにマッチしたH(ヘッド)・S（セクタ)・パラメータでパーティションを作成する。"System Reserved"パーティション(ブート用の小パーティション, UNIXでの/bootを別パーティションとした場合に類似)、システムドライブ用のパーティション、共にSSDにマッチしたH・S・パラメータでパーティションが作成される
 

※HDDにSSDに適したH・S・パラメータを使用しても性能や寿命が劣化することはありません。ただしここに書いたように、SSDに適したH・S・パラメータは従来あまり使われてこなかった値なので、一部のOSとの互換性がとれないデメリットがあります。

 

(2010-2-6追記)関連する外部のページを紹介しておきます。
Windows 7 - 100MBのパーティション（システムで予約済み）を消す方法
この方と私は興味を持つ分野が重なっているらしく、こちらのページにも別のリンクを張っています。

(おまけ)MBRのバックアップ

※: デバイス、ファイル名は適宜読み替えて下さい。

dd if=/dev/sda of=hoge.img count=1 [bs=512]
 

マルチブートするなら２段階ブートに統一して、MBMを使用しましょう。MBMは、WindowsがインストールするMicrosoft謹製のMBR用ブートローダやgrubのchainloader機能の上位互換となる高機能なブートローダです。

(おまけ)NTシグニチャのバックアップ

※: デバイス、ファイル名は適宜読み替えて下さい。
バックアップ

dd if=/dev/sda of=hoge.img bs=1 skip=440 count=4

レストア

dd if=hoge.img of=/dev/sda bs=1 seek=440 [count=4]# 超がつくほど注意が必要

※: クリアはこのページに載せています。

(2008-12-30)ここに大切な注意点を載せてあります。

(補足）パーティションはシリンダ単位で確保しましょう

(当たり前過ぎることを書いていたので一部割愛しました。)

 

シリンダ境界に拘束されずにパーティションを確保できてしまうツールがあります。
出来る限りLinuxでパーティションの確保をおこなうようにしましょう。私なんかはあらゆるOS(Windows各種, Linux各種, 等)をインストールする際、そのインストーラでパーティションを確保することはまずありません。必ずといっていいほど事前にLinuxのfdiskでパーティションを確保しておきます。必然的にOSのインストールプロセスでははカスタム設定(熟練者向け,エキスパート向け設定, 等)を選択することになります。マルチブートを志向するならそれは当然のことです。ここの読者の方にもマルチブートを志向するならそうするのが当然だと認識していて欲しいと思います。

 

Linuxについて言えば、現在ではfdiskのインターフェースを隠すインストーラが殆どですが、私の知る限り、どのディストリのインストーラでも必ずシリンダ単位でパーティションを確保するようです。それでもコンソールに下りて自分でfdiskコマンドを使用することを推奨します。

※: たとえばDebianのインストーラ標準では、拡張領域を100Gバイト確保してとりあえずそのうち50Gバイトだけ論理パーティションで使用するというやり方ができません。拡張領域全体の大きさが50Gバイトだとパーティションテーブルに書き込んでしまいます。fdiskを直接使用するとこのような状態を避けることが出来ますし、またこのような状態はfdiskを使わないと解消できません。

 

ご要望、ご意見、質問を下のフォームにどうぞ
（でもここより、掲示板や書き込みフォームのページに書いて頂いた方が気づき易いと思います。）

  • HDDのCHSは通常BIOS呼び出しで得られた値が使用されると思います。fdiskで一時的に変更してもその時だけしか意味は無いかと思いますが… -- シリンダ境界? 2010-10-05 (火) 10:14:25
  • 最初の文はいわばDOS時代の知識です。今のOSはHDDの読み書きにCHSの値は使いません。BIOS経由で取得したCHSの値はもちろん、パーティションテーブルの状態から推測したCHSの値も使いません。fdiskに-H、-Sオプションを与える意味は、
    1)(-uオプションを与えない場合に)与えられたH,S値で現在のパーティションテーブルの状態を表示する。
    2)新規にパーティションテーブルを作成する場合に与えられたH,S値にマッチしたパーティションテーブルが作成される＝論理シリンダサイズをカスタマイズできる。
    です。 -- disklessfun? 2010-10-05 (火) 22:29:32