Tips: grub2とgrub-legacyの扱い方(様々な再セットアップ方法等)

(2015-7-21)grub2に関する古い情報を大幅に削除しました。思い切って古い情報を切ったので、初期のgrub2を採用している古い環境においては本ページの内容が最適でない場合もあります。
Linux Mint 13(等)の方、ごめんなさい

そもそもこのページは6年前、ネット上にgrub2の情報が乏しくて、grub2に関して多くの誤った情報を目にし、「このまま放置すればマルチブート手法が混乱する」「自分がgrub2の情報を提供するしかない」と思って作成したものです。

6年経ち、grub2もかなり洗練され使いやすくなり、必須の情報も格段に少なくなりました。

---

grub2ももちろんgrub-legacyと同様、PBRにセットアップすることができ、マルチブート環境を管理のし易い２段階ブートに統一することができます。MBRにセットアップするマルチブートマネージャには従来同様、MBM※がお薦めです。
※MBMはUEFIに対応していないのでUEFIマザボの場合はLegacyサポートを有効にしておく必要があります。また2Tバイト以下のハードディスク、SSDである必要があります。
grub2はUEFI時代は必須になります。だけど開発者の考え方がちょっと変←今のところこのままずっとみたい

マルチブート環境を構築する場合全般に通じるお勧めの手法

マルチブートを念頭に置く場合、ここにも記述していますが、OSのインストールは、事前にLive OS上等でgpartedやfdisk等で(マルチブート用の)パーティションテーブルを作成した後に始めることをお勧めします。

そうすればWindowsのインストーラに(BitLockerを使わない場合に)パーティションの浪費とも言える「System Reserved」を作られなくて済みますし、Debian等やUbnutu等のインストール中に問題なく論理パーティションのPBRにgrub2をセットアップすることが出来ます。この場合Debian等やUbuntu等のインストール時にハードディスクの使い方を選択する際は、常に最後の(3番目の、一番下の)選択肢を選択することになります。

grub2

２段階ブート(マルチブート)関連でgrub2について最低限必要な情報

（１）(Linux)OSインストール後にgrub2のセットアップ先をPBRに移す際の構文

# grub-install  --force  /dev/hoge

加えて、この作業(Debian,Ubuntu系の場合)

※ --forceを付けなくてはならない理由

（２）(Linux)OSの引っ越し時やレストアやレスキュー時等に、他のOS上でgrub2をPBRにセットアップする際の構文

# grub-install  --force  --root-directory=(/dev/hogeのマウントポイント)  /dev/hoge

(2015-7-26)バカな間違いを見つけたので修正しました。

※ --forceを付けなくてはならない理由

（３）２段階ブート時、grub2のメニューから不要なエントリを削除する作業

/etc/default/grub に GRUB_DISABLE_OS_PROBER=true を追記した後、update-grub を実行する

grub2をマルチブートマネージャとして使用しない(替りにMBM等を使用する)場合は、grub.cfgに余計なエントリーが追加されないように、/etc/default/grubにGRUB_DISABLE_OS_PROBER=trueを追記しておくことをお薦めします。私はもちろんそのようにしています。ただしレスキュー作業時に一時的にこの設定を無効した方がいいケースもあります。

（４）(Debian, Ubuntu系)OSのインストーラ画面で

OSをインストールしたりgrub2をセットアップするパーティションを自分で選べるように、一見インストーラが“最も勧めないように見える”(高度な知識が必要です等と警告される、大抵一番下の)選択肢を選ぶべきです。

その為にパーティションテーブルを事前に作成しておくことをおすすめします。Live OS上で作業しておけばいいでしょう。

Windows(8, 8.1や10も含む)系, Debian系, Ubuntu系 このいずれをインストールする場合においても、（1）事前にパーティションを作成し、（2）MBMインストール手段※1を準備しておくと、後が楽※2だと思います。

※1 MBMはUEFIに対応していないのでUEFIマザボの場合はLegacyサポートを有効にしておく必要があります。またブートに関連するハードディスクは2Tバイト以下のサイズである必要があります。
※2「Windowsを新規インストールした際にインストーラがMBRを上書き」しても平気になります。

（５）RHEL系(CentOS)等での注意点

インストーラがgrub2のPBRへのセットアップをサポートしていないRHEL系(CentOS等)で、grub2を手動でPBRにセットアップした後の運用法に関して少しこちらに記述しました。

Debian系でgrub2のgrub-pcパッケージが正しく更新される為に確認しておくべきこと

Ubuntuだと9.10以降に採用されたgrub2は、一般的になった頃には既に開発停止になっていたgrub-legacyとは異なり、今後もどんどん開発が進み、各ディストリから次々とアップデート・パッケージがリリースされることが想定されます。grub2パッケージのアップデートにはgrub2の再セットアップが伴います。再セットアップが正しくおこなわれる為には、grub2の正しいセットアップ先デバイスが、Ubuntu9.10以降の場合、Debconfデータベースに正しく登録されている必要があります。もちろんその登録はUbuntuのインストール時におこなわれます。しかし、インストール後にgrub2のセットアップ先をMBRからPBRに変更したとか、インストールが正常に完了せずに修復した後で使用している等の場合には、自らその(再)登録をおこなってやる必要があります。
ダウンロード　update_debconf_grub-pc_install_devices.sh　Ubuntu 9.10以降専用(2010-5-31更新)Debianではまだ確認していないので一応Ubuntu専用としていますが、この辺りの仕様がDebianとUbuntuで異なるということはないと思うので、多分Debianでも使えると思います。もちろんFedoraでは使用できないと思います。Fedoraでも何らかの手段でgrub2インストール先デバイスの情報を保存する仕様が既に決定していると思われますが、まだ調べていません。
grub2を/bootを含むパーティション(/とか/bootのパーティション)のPBRにセットアップしている環境・専用(決め打ち)です。(私が非常に推奨しない)１段階ブートにしている人は使用しないで下さい。

使い方
1. 現在の設定値を見る

# /パス/update_debconf_grub-pc_install_devices.sh  -v

2. 普通の環境で普通に設定する(現在起動中のOSの、/bootを含むパーティションのUUIDを設定)

# /パス/update_debconf_grub-pc_install_devices.sh  # 引数なし

　更新前にはユーザに確認を求めます。Enterを押すだけでは更新はおこなわれません。
3. ブートデバイス(/bootや/) がraid1デバイスの場合に設定する

# /パス/update_debconf_grub-pc_install_devices.sh  -d  /dev/sda1(例)  # 生デバイス名を指定する

4. chroot環境で設定する

# ./update_debconf_grub-pc_install_devices.sh  -u  hoge-fuga  # UUIDを直接指定する

　長いUUIDを引数で指定するのは難しいので、chroot前に、設定したいUUIDだけを書き込んだファイルを作成しておくといいと思います。そして、

# ./update_debconf_grub-pc_install_devices.sh  -u  `cat hoge`

　みたいな感じで使用すればいいと思います。

※本スクリプト(ツール)を実行する環境のDebconfデータベースしか参照・更新できません。他のOS上からはchrootしないと参照・更新できません。
grub-pcパッケージがアップデート時に参照する、Debconfデータベース(Windowsでのレジストリみたいなもの)の該当部(grub2インストール先デバイス)に、UUID形式で現在のブートデバイスを書きこみます。標準では該当部にはUbuntu 9.10だと生のデバイス名、Ubuntu 10.04だとid(by-id)形式で書き込むことになっていますが、HDDの接続順を変更したり、HDDの引越しをおこなったりする場合にも問題の生じない、最も柔軟性が高い形式はUUID形式です。従って私はUUID形式で書き込むことをお薦めしますし、本スクリプトでもUUID形式で書き込みをおこないます。先に書いたようにUUID形式は9.10, 10.04の双方で標準ではないんですが、私の方では双方でUUID形式での動作確認が済んでいます。
[update_debconf_grub-pc_install_devices.sh]

#!/bin/bash -e

export LANG=C

echon() {
	printf "%s" "$@"
}
yesno()
{
	msg="$1"
	def="$2"
	while true ; do
	echon "$msg"
	read answer
	if [ "$answer" ] ; then
		case "$answer" in
		y|Y|yes|YES)
			return 0
			;;
		n|N|no|NO)
			return 1
			;;
		*)
			echo " "
			echo "Error: Invalid response, expected \"yes\" or \"no\"."
			continue
			;;
		esac
	else
		return $def
	fi
	done
}

usage()
{
echo "usage: $0 [OPTION]"
echo
echo "    -d target_device    specify target partition by device file name"
echo "    -u uuid(preferred)  specify UUID directly"
echo "    -v                  get current value"
echo "    -h                  print this message and exit"
echo
exit
}

exec_db()
{
tempfile=$(mktemp)
chmod +x "${tempfile}"
cat>${tempfile}<<EOT
#!/bin/bash -e
. /usr/share/debconf/confmodule
db_go
EOT
if ! ${VIEWMODE}; then
cat>>${tempfile}<<EOT
db_set grub-pc/install_devices "/dev/disk/by-uuid/${target_device_uuid}"
EOT
fi
cat>>${tempfile}<<EOT
db_get grub-pc/install_devices
db_stop
EOT
if ! ${VIEWMODE}; then
cat>>${tempfile}<<EOT
echo "Updated successfully."
EOT
fi
cat>>${tempfile}<<EOT
echo 2>&1 "grub-pc/install_devices: \${RET}"
rm "\${0}"
EOT
exec "${tempfile}"
}

test `id -u` -ne 0 && echo "Run as root." && exit 1
arg_target_device=;arg_uuid=;VIEWMODE=false
while getopts "d:u:vh" opt; do
  case $opt in
    \?) OPT_ERROR=1; usage;;
    d) arg_target_device="$OPTARG";; # Optional argument: -d /dev/??
    u) arg_uuid="$OPTARG";;          # Optional argument: -u ?????
    v) VIEWMODE=true;;               # Optional argument: -v(Get current value)
    h) usage;;
  esac
done
${VIEWMODE} && exec_db
if test -n "${arg_target_device}" && test -n "${arg_uuid}"; then
echo "Warning: uuid has been given. target_device will be ignored."
fi
target_device=
if test -n "${arg_uuid}"; then
testline=$(echo "${arg_uuid}"|tr -d [:alnum:]|tr -d \-)
test -n "${testline}" && echo "Error, Invalid argument." && exit 1
target_device_uuid=${arg_uuid}
else
if test -n "${arg_target_device}"; then
if test ! -e "${arg_target_device}"; then
echo "Error, ${arg_target_device} does not exist." && exit 1
else
target_device=${arg_target_device}
fi
else
target_device=`mount|grep "on /boot "|cut -d" " -f1`
test -z "${target_device}" && target_device=`mount|grep "on / "|cut -d" " -f1`
fi
line=`blkid|grep "${target_device}:"`
line=${line#*UUID\=\"*}
line=${line%%\"*}
testline=$(echo "${line}"|tr -d [:alnum:]|tr -d \-)
test -n "${testline}" && echo "Error, Can't get UUID." && exit 1
target_device_uuid=${line}
fi
echo "target_device: ${target_device}"
echo "target_device_uuid: ${target_device_uuid}"
echo "The debconf database will be updated."
yesno "Proceed? yes or no [n] " 1 && exec_db

ちょっと問題な、grub2開発者の考え方

grub2をPBRにセットアップしようとすると以下の警告文が表示されます。

このような警告を出すgrub2開発者の考えは、このページを設けている私の考えとは真っ向から対立します。
grub2開発者は、grub2をMBRにセットアップして「grub2が(マルチブートの)全OSのブートを司る」ことを至上と考えているのだと見えます。これは「自分達が開発したソフトウェアが広範囲に使われること」が「ユーザの使い勝手」よりも優先するという本末転倒な考え方だと思います。

grub2開発者の考えと私の考えにはそれぞれ長所・短所がありますが、実際には上の警告文に逆らってこのページの考え方を実践してgrub(grub2,grub-legacy)をPBRにセットアップし、MBRにはもっと欠点の少ないマルチブートマネージャーをインストールした方が遙かに利便性が高いと思います。これはかねてから私が主張していることです。

少し考えるだけで、「grubが(マルチブートの)全OSのブートを司る」手法の破綻が見えると思います。たとえばLinuxを複数インストールした場合、「メインのLinux」以外のLinuxでカーネルアップデートをおこなってもそれが「メインのLinux」で使用する設定ファイル(grub2ではgrub.cfg, grub-legacyではmenu.lst)に反映されないという問題が生じます。またWindowsを後からインストールしたり、再インストールしたりするとMBRは上書きされ、grubは起動しなくなりますし、今まで連携していたgrubディレクトリが存在するパーティションがどれなのかもわからなくなってしまいます。このページに従って２段階ブートに統一すればこのような問題から開放されます。

grub2,grub-legacyをPBRにセットアップした場合の短所は、PBRはMBR(正確にはMBRとそれに続く領域)に比べて狭く、ファイルシステムドライバを格納することができない為、grubディレクトリ中の特定のファイル(grub2ではcore.img,grub-legacyではstage2)の物理的位置が変わった場合にgrubの再セットアップが必要になることです。上に掲載の警告文が言わんとすることはこの辺りです。
しかしこのページで記しているような数々の長所がありますので、grubをPBRにセットアップすることを強くお薦めします。

(念の為削除せず置いておきます)Ubuntu 10.10インストーラの実態

エラー発生時等の例外ケースの除けばだいたいこんな感じです。

• 既存のNTFS領域を縮小してLinuxをインストールする領域を作り出したい場合は「他のOSと共存させてインストールする」を選択し、且つ「拡張パーティショニングツール」を利用しない手法を選択すればいいと思います。ただしこの場合は必ず１段階ブートになってしまいますので、インストール後に２段階ブートに変更することを強くお勧めします。本ページには１段階ブートから２段階ブートに変更する方法を載せていますのでそれをご利用下さい。
• それ以外の場合は「拡張パーティショニングツール」を利用し、且つブートローダをPBRにインストール(grub用語ではセットアップ)することをお勧めします。

(念の為削除せず置いておきます)Ubuntu 9.10, 10.04インストーラの実態

(2010-5-18追記)「それぞれ別のものとしてインストールし、起動時にどれを起動するか選択」をを選択した場合の具体的な問題のひとつは、インストーラが拡張パーティションのIDを5(Extended)と書き込むことです。それ自体は悪くない筈なんですが、現状のgrub-setupが正しく動作する為にはIDをf(W95 Ext'd (LBA))等にする必要があります。これはgrub2側のバグ(仕様の問題だとは言えないレベル)だと思いますが、簡単に気づく問題ですからインストーラ側で回避しておいて欲しいものです。

以下は上表に記したバグと比べると該当ケースは少ないと思いますが、一応、気に留めて頂きたいと思います。

拡張ボタンを押すと表示されるブートローダ(grub2)のインストール先指定画面についてですが、9.04以前と同様にテキストボックスにキーボードで入力して指定することもできます。しかしドロップダウンリストから選択して指定することをお薦めします。9.10以降、「ブートローダのインストール先を指定した筈なのにブートローダが(正しく)インストールされなかった」というトラブルの情報を多く目にします。しかし私は何度もUbuntu 9.10をインストールしましたが、そのようなトラブルに遭ったことがありません。その違いは私の想像するところでは、この画面での指定の仕方に大きく少し起因するのではと想像します。grub-legacyとgrub2ではパーティションの表記法が変更されたにも関わらず、古いインストラクションに従ってインストールしてしまった方にトラブルが多発発生しているのではないかと思います。ドロップダウンリストから選択して指定すれば、一緒に表示されるOS名等の付加情報と照合できるので間違いが防げます。←ただし、上表にあるように、ドロップダウンリストからPBRを選択する方法が全く問題なく使えるのは、今のところ「手動でパーティションを設定する」という選択枝を選んだ場合だけだったりします。

データ持ち運び用 USBメモリなんかにLive OSを仕込む場合等に便利な grub2のloopマウント機能

(2015-7-26追記)
私の推奨する2段階ブート等に直接は関係ないんですが、常備(携帯)するUSBメモリにLive OS(古い言い方だとOneCD Linux)を仕込んでおくことは、Linuxerだけでなく、Windowsだけでマルチブートする人にとっても、とても役立つ可能性があります。grub2のloopbackマウント機能(マウントを幾重にも重ねることができる機能)は、そういう用途(Live OSをUSBメモリに仕込む用途)を少し助ける機能にもなります。具体的に言うとloopbackマウント機能のお陰でカーネルとイニシャルラムディスクをisoファイルから取り出しておく必要がありません。すっきり管理ができます。

具体例を、手短に記述します。

USBメモリはMBR形式パーティションテーブルを持つものとします(普通そうなってます)。
USBメモリは全域が1パーティションで確保されているものとします(普通そうなってます)。
USBメモリのパーティションはFAT32でフォーマットされているものとします(大概そうなってます)。

上記の状況で、特に変わった使い方をしていないとすると、USBメモリ上のパーティションは(Live OSを含む)Linux上で/dev/sd[x]1と認識されます。
[x]の箇所にはaとかbとかcとかdとかが入ります。# fdisk -l などのコマンドで確認できます。

grub2は以下のような作業でUSBメモリにインストールします。(Live OSを含む)Linux上の作業です。

MBRにインストールする場合はこんな感じです。

# grub-install --root-directory=(/dev/sd[x]1のマウントポイント)  /dev/sd[x]

この場合最後は必ず数字以外の文字、aとかbとかcとかdとかです。

参考までにPBRにインストールする場合は

# grub-install --force --root-directory=(/dev/sd[x]1のマウントポイント)  /dev/sd[x]1

PBRにインストールした場合はMBRにブートローダが必要です。
Debian,Ubuntu系だとmbrパッケージをインストールして# install-mbr /dev/sd[x] コマンドを実行したり、MBMをインストールすることでMBRにブートローダが入ります。私だとまず殆どの場合、MBMをインストールします。複数のディスクやSSDやUSBメモリが接続されいることをその場で確認できますし、その他様々便利な機能があるからです。
Windows上でもdiskpartでMBRにブートローダをインストールすることができます。その場合及びinstall-mbrを使用した場合は/dev/sd[x]1をアクティブに設定する作業も必要です。
※USBメモリに複数のLive OSじゃないLinuxをインストールすることもあるでしょうからPBRへのセットアップの方法も記述しておきました。

grub.cfg(の原型)はこんな感じで作成します。

# grub-mkconfig -o (/dev/sd[x]1のマウントポイント)/boot/grub/grub.cfg

あとは、Live OSのisoを配置し、適宜grub.cfgを編集します。
grub.cfg(の原型)の適切な場所に、以下のような記述を挿入します。

menuentry "Live OS 1" {
	set iso_path='boot/konalinux-3.0-mate_i386.iso'
	loopback	loop /$iso_path
	linux	(loop)/live/vmlinuz boot=live fromiso=/dev/disk/by-uuid/4BFB-4F96/$iso_path \
quiet splash noeject locales=ja_JP.UTF-8 timezone=Asia/Tokyo
	initrd	(loop)/live/initrd.img
	boot
}

このような記述はDebian,Ubuntu系Live OSでかなり共通に使えます。ただしこの中の「live/vmlinux」や「live/initrd.img」の箇所はisoによって異なる場合もあります。isoの中のファイルパスを# isoinfo -lR -i hoge.isoで見ることで確認できますが、より確実を期す場合はisoをloopマウントしてisolinux.cfgの中の記述まで確認するべきでしょう。
また、set iso_path='boot/konalinux-3.0-mate_i386.iso'の部分をset iso_path='/boot/konalinux-3.0-mate_i386.iso'のように記述してはいけません。先頭にスラッシュを記述すれば絶対パスと等しくなるのでつい記述したくなるんですが、駄目です。ここに記述するパスの先頭にスラッシュがあると必然的に後の行の記述からスラッシュが省かれますが、こうすると正しく動作しません。つまり「loopback loop $iso_path」との記述は駄目です。内部処理する関数の制限です。
あと、fromiso=？？の箇所に、替りにfindiso=hoge.isoと記述することも可能は可能なんですが、お勧めしません。findisoを記述すると認識順にハードディスクやUSBメモリのパーティションをマウントしてisoファイルを検索しようとします。時間がかかりますし、isoが配置されたパーティションを見つける前に他のパーティションのマウントに失敗する危険性※もあります。上記例のようにfromiso(もしくはisofrom)を使用し、UUIDで目的のパーティションを指定する記述法が最もお勧めです。この記述法だと無駄なマウント処理や検索処理がないので問題が発生する可能性を低く抑えることができます。
※ハイバーネートされていたりしてマウントできない場合がある。

grub-legacy(grub ver. 0.97)

以下のコンテンツは当サイト内の別のページからコピーあるいは移動したものです。今のところ別のページに一部同一の内容が存在します。

grub-legacy(grub ver. 0.97)のセットアップ(grubのPBRへのセットアップ法)

もしマルチブート環境を構築するなら、是非このページに目を通してみて下さい。

---

(2008-1-17ちょっとだけ更新)usbで接続されているデバイスへのgrubのセットアップは何か特別ではないかとの先入観を持たれている方が多いようです。でも実際には内蔵HDDに対してセットアップする場合と何らと言っていいほど変わりません。usbデバイスは、Linux USB対応OS起動中はドライバーによってscsiデバイスとしてエミュレーションされ、scsi HDDと同様に扱うことができます。OS起動時は(USBブートできるPCであれば)BIOSによってHDDとしてエミュレーションされています。これが意味することは、grubで「USBブート」する為に「USB対応grub」なんてものは(どんなOSであっても)必要ないということです(少し詳しい説明)。そもそもgrubのみならず世の殆どのPC用ブートローダにUSBブート対応は必要ありません。通常使われる意味でのUSBブートとはBIOSの機能によっておこなうものだからです。ブートローダ自体がUSBブートに対応しなければならないケースとはブート革命／USBのブートローダのようにUSBブート未対応のBIOSを持ったPC上で疑似USBブートを実現させる用途のような特殊な場合だけです。要は難しく考える必要はないということです。grubセットアップ時とブート時でHDDの順番が変わる場合があることだけには注意が必要です。(あえてmapには言及しません)
私の場合、こんな感じです。
自分の環境に適宜合わせて下さい。
※以下の(hd1,0)とは、作業をおこなったPCにとっての２番目のハードディスクの１番目のパーティションを意味します。リムーバルなUSBハードディスクもしくはUSBメモリが２番目のハードディスクとして認識されているということになります。(hd1,0)との表記についての詳しい説明はこちら

１段階ブートの場合、

# grub
    GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]

grub> root (hd1,0)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd1)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd1)"...  15 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd1) (hd1)1+15 p
 (hd1,0)/boot/grub/stage2 /boot/grub/grub.conf"...
succeeded
Done.

grub>quit

※setup (hd1)は母艦PCにとっての２番目のハードディスクのMBRにgrubのstage1をセットアップする(書き込む)ことを意味します。作業時にUSBハードディスクもしくはUSBメモリが何番目のハードディスクと認識されていようとUSBブートに直接関係はありません。

↓※以下の作業を始めておこなう方は、それまでに確実に２段階ブートが何かを理解し、自分でMBM等のMBR専用のブートローダをインストールする必要があることを理解してから作業にとりかかって下さい。
２段階ブートの場合、
２段階ブートの場合、たとえばこのように、

# grub
grub> root (hd1,0)　　←rootで指定するのはmenu.lst(grub.conf),stage2等の場所
grub> setup (hd1,0)　　←setupで指定するのはgrub(grubのstage1)の書き込み先

setupで指定するデバイスをハードディスク(の先頭)ではなくパーティション(の先頭)とします。
上は母艦上の作業としてのサンプルですが、
普通にLinuxをブートし、そのOS上でブートの方式を１段階ブートから２段階ブートに変更する場合であれば、たとえば、

# grub
grub> root (hd0,0)　　←rootで指定するのはmenu.lst(grub.conf),stage2等の場所
grub> setup (hd0,0)　　←setupで指定するのはgrub(grubのstage1)の書き込み先

こんな感じになります。もちろん詳細は適宜自身の環境に合わせて下さい。

マルチブート環境の場合、↑このように、grubをPBR(パーティションの先頭セクタ)にセットアップすることを強く推奨します。

grub-legacy(grub ver. 0.97)の、レスキュー時等の(ブートした環境とは別の環境への)セットアップ

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

---

新しいHDDにシステム全体をレストアしたり(grubのセットアップ先がMBR,PBRの場合共通)、別の領域にOSを引越したり(同MBR,PBRの場合共通)、stage2ファイルを上書きしたり(同PBRの場合)した際にはgrubの再セットアップが必要となります。MBRにセットアップする場合はgrubコマンドを使ってgrubのstage1をMBRに、stage1.5を２番目以降のセクタにコピーし、さらにそこにstage2がどこにあるのかをを書き入れることです。PBRにセットアップする場合はgrubコマンドを使ってgrubのstage1をPBRにコピーし、さらにそこにstage2の位置を書き入れることです。この場合に気をつけなければならないのはレストアする側のOS(OneCD Linux等)のgrubコマンドと、レストアされた側の/boot/grub中のファイル群とが、整合性がとれている(簡単に言って出所が同じなら整合性はとれています)必要があるということです。でも普通、両者共同じディストリの同じバージョンでもない限り整合性はとれていません。通常私は、レストアする側とレストアされた側のgrubの整合性はとれていないことを前提に対応をおこなっています。その手順を簡単に説明します。

1. grubの再セットアップ前に、レストアされた側の/boot/grubディレクトリを、レストアされた側のファイルシステム上にバックアップしておきます
2. レストアされた側の/boot/grubディレクトリ内のstage1、必要なstage1.5、stage2を、レストアする側から同名のファイルをコピーして上書きします
3. (勿論レストアする側の)grubコマンドでgrubをセットアップします(参考)
4. レストアされた側のOSを起動後、バックアップしておいたgrubディレクトリからファイルをコピーして、先に上書きしてしまったファイル群を元に戻すか、boot/grubディレクトリ全体をバックアップしておいたものと入れ替えることで、/boot/grubをバックアップ前と同じ状態に戻します
5. (勿論レストアされた側のOS上で、)grubを再セットアップします(参考)

※grubをPBRにセットアップした場合はstage1.5は使われません。
※ディストリビューションによる設定ファイル名の違いも頭に入れておいたほうが望ましいです。特に、上に書いた手順を自分なりにアレンジしたい場合には不可欠な知識だと思います。

grub-legacyでのハードディスクの表現

SATAのPCでは特殊な設定をしていない限り、以下の表の対応が成立します。
grub2とgrub1ではハードディスクの表現が異なります。

※ハードディスクにはUSBメモリやUSB接続のSDカードやUSBアダプタを介したCF等も含みます。内蔵・外付けの区別はありません。
現在は各ハードディスクにパーティションを最高16個作成できます。ただしそのうち１個は拡張領域となるのでファイルシステムとして確保できる数は最大15となります。

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

• 貴殿に同意　grub2 で痛い目にあった。 -- naka? 2012-11-19 (月) 06:08:19
• ”grub2 の場合はこちら” で --force を使う手 目からうろこ 有難うございました。 -- Leo? 2014-05-17 (土) 22:25:12
• Debian8とArchlinuxをデュアルブートにしたく検索していたところHPにたどり着きましたが -- kkuma? 2015-08-25 (火) 11:55:36
• あら改行出来なかったすいません。それで現状で一段ブートになっているものを2段にしたいにですが例が多すぎてどうすれば良いか良く分かりません。 -- kkuma? 2015-08-25 (火) 11:57:59
• まず現状把握です。HDDもしくはSSDはMSDOS形式の(fdiskコマンドでパーティションの割り具合が参照できる)パーティションテーブルですよね。それが前提です。次に、Debian8、Archlinuxのどちらが“削除したら、もう一方も起動できなくなるOS”ですか？　大概grub2の画面で先頭に表示されるOSです。作業は“そのOSと違う方のOS”から始めます。その“違う方の”OS上から、そのOSの/bootが含まれるパーティションのPBRにgrub2をセットアップして下さい。エラーが起きていないかよく画面を監視していて下さい。場合によってはコマンド実行直後にecho $?をおこない、0が表示されるか確認して下さい。次にOSを切り替えて下さい。つまり“削除したら、もう一方も起動できなくなるOS”の方に切り替えて下さい。そして、先のOSと同じようにそのOSの/bootが含まれるパーティションのPBRにgrub2をセットアップして下さい。そしてMBMをインストールして下さい。以上です。これで一方のOSを削除しても(例えばゼロ埋めしても)もう一方のOSには何の影響も及ぼさない２段階ブートが実現している筈です。Debian8に関してはupdate_debconf_grub-pc_install_devices.shを実行しておくことをお勧めします。 -- disklessfun? 2015-08-25 (火) 21:06:52
• 詳細な情報にとても助かっています。もしご存知でしたら教えていただきたいのですが・・・。最新のManjaro Linux 15.09ではinitrdを２つ指定するようです。Manjaro Linux自身のupdate-grubは成功しますが、他のパーティションにインストールしてあるディストリビューション（Ubuntu, Debian)のupdate-grubではManjaro Linuxのinitrdが正しく指定されないようです。os-proberのスクリプトを見てみましたが、initrdを一つしか検知できないのかもしれませんが、そのような仕様でしょうか？ -- ks? 2015-11-20 (金) 11:49:43
• grub-mkconfigのソースは解析していないのですが、Mnjaro以外の(普通の)Linuxのgrub-mkconfigが、「一つのカーネルに対応するinitedが2個」だと気づかない(認識しない)のは当然だと思います。何十年間もカーネル1個に対してラムディスク1個の関係なので、それを前提として作りこんでしまっても世界中の誰も「配慮の行き届いていないプログラムだ」と責めたりしないでしょうから。 -- disklessfun? 2015-11-20 (金) 20:48:42
• そうですね、grub2はいずれソースコードの改良が追いついて行かないのではと感じています。先ほど、Manjaro Linuxを再インストールして別パーティションのディストリビューションからupdate-grubしたら、起動できる方のinitrdを一つですが選びました。うーん・・・。 -- ks? 2015-11-21 (土) 00:09:03
• この問題の影響範囲はあくまでもgrub-mkconfigが生成するテキストファイルのみにとどまります。いろいろ工夫できるでしょう。また今のところはManjaro Linuxをrescue Linuxにすればそう困ることもないでしょう。 -- disklessfun? 2015-11-21 (土) 00:45:01