システム奮闘記：その71

ブートローダー(GRUB)の話

(2008年7月27日に掲載)

注意書き

  GRUBには、GRUB-LegacyとGRUB2の2つ存在します。
  GRUB-0.X系はGRUB-Legacyと呼ばれ、GRUB-1.X系はGRUB2と呼ばれています。

  ここではCentOS5.1で初期設定でインストールされているのが
grub-0.97である事から、GRUB-Legacyの話を書いています。


  RedHat7.3やRedHat9.0を使っていた私。
  ブートローダーはLILOを使っていた。

  だが、OpenSuseやCentOSに手を出してから厄介な問題が発生した。

  カーネル再構築ができへん

  なのだ (--;;

  私は、Linux-2.4系の再構築はできるが、Linux-2.6系のオプションは
さっぱりわからない。
  Linux2.4系を入れても良いのだが・・・

  GRUBの設定がわからないのらー！！

  だった (--;;

  ブートローダーがLILOからGRUBになってから、カーネルの再構築ができないという
困った事が起こったのだ。
  GRUBの勉強をせねばアカンなぁと思ったのだが、正直に暴露をすると・・・

  LILOの知識も、ええ加減なのらー！！

  そうなのです。LILOの設定は、本の丸写しと見よう見真似で覚えたため、
キチンとした知識はないのだ。
  そんな状態で、カーネル再構築をした後、適当に設定を行って

  /sbin/lilo -v

  を行っていたのだった。

  要するに・・・

  ブートローダーの事が全くわかってへんのらー！

  つまり何もわかっていない事がバレバレなのだ。
  そこで「これは勉強せねば」と思い、今回の話になりました (^^)

ブートローダーって何やねん?
  LILO、GRUBといっても、そもそもブートローダが何かわかっていないと
お話にならない。

  ブートローダーが何なのかを知らずに、設定ファイルを眺めても

  チンプンカンプンなのらー！！

  そこでブートローダーが何かを調べる事にした。
  すると以下の事を行うプログラムだという。

ブートローダーとは何か?
コンピューターの起動直後に動作し、OSをディスクから読み込み、 OSを起動させるプログラム。起動ディスクのマスターブートレコーダー(MBR)の領域に保管されている。

ブートローダーとは何か?

コンピューターの起動直後に動作し、OSをディスクから読み込み、
OSを起動させるプログラム。
起動ディスクのマスターブートレコーダー(MBR)の領域に
保管されている。


  ここでハードディスクに関する復習を行う事にした。ほとんど忘れている (^^;;
  一体、マスターブートレコード(MBR)の領域はどこなのか。

ハードディスクの領域

マスターブートレコードとは、ハードディスクの最初の1セクタの領域だ。
AT互換機の場合、1セクタは512バイトなので、512バイトの容量がある。

この領域内に、ブートローダーと呼ばれるプログラムが入っているのだ。
このプログラムが、OSを読み込み、OSを起動させているのだ。


  これを知った時・・・

  私は間違えた知識を持っていたのらー！！

  だった。

  実は、今まで、OSが起動するまでの仕組みは以下のように思っていた。

今まで思っていたOSが起動するまでの仕組み

パソコンの電源を入れると、BIOS内部に格納されている
プログラムが読み込まれ、実行される。
それによりハードディスクなど周辺機器を認識できるようになり
OSを読み込めるようになる。


  図式化すると、以下のような事を思い描いていた。

今まで思っていたOSが起動するまでの仕組み

パソコンの電源を入れる事によって、CPUはBIOSの中に格納されている
プログラムを読みだしにいく。そしてプログラムを起動させる。

BIOSの中には、基本的な周辺機器のドライバが入っているので、
それらが働き、周辺機器(ハードディスクやモニタ等)を認識し
パソコン全体が動ける状態にする。

ハードディスクを認識できるため、ハードディスクにあるOSを
読み込み、OSを起動させる。


  だが、今回の事で初めて・・・

  BIOSとOS起動の間に、ブートローダーが働く

  事を知ったのだった。

  つまり正しくは以下の流れで、OSが起動する仕組みになっているのだ。

OSが起動するまでの仕組み

パソコンの電源を入れると、BIOS内部に格納されている
プログラムが読み込まれ、実行される。
それによりハードディスクなど周辺機器を認識できるようになる。

そしてハードディスクの先頭セクタに格納されている
ブートローダーというプログラムを読み込む。
そのプログラムには、呼び出したいOSを保管している
ハードディスクの位置が記録されているため、
OSの呼び出し位置を知る事ができる。

そして、ようやくOSを読み込めるようになる。


  より詳しく見るため図式化すると、以下の通りになる。

OSが起動するまでの仕組みを図式化すると

パソコンの電源を入れる事によって、CPUはBIOSの中に格納されている
プログラムを読みだしにいく。そしてプログラムを起動させる。

BIOSの中には、基本的な周辺機器のドライバが入っているので、
それらが働き、周辺機器(ハードディスクやモニタ等)を認識し
パソコン全体が動ける状態にする。

ハードディスクを認識可能になった所で、ハードディスクの
先頭セクタ上の領域のマスターブートレコード(MBR)に格納されている
プログラム(ブートレコーダー)を読み込む。

ブートレコードには、呼び出したいOSが保管されている
ハードディスクの位置が記録されているので、
呼び出したいOSを読み込む事が可能になる。

そして、呼び出したいOSを読み込み、OSが起動される。


  この時、初めてブートローダーが何かを知った。

ブートローダーの名称について
書籍やネットなどで調べていると、マスターブートレコードに格納されている、OSを起動させるプログラムの名称だが、ブートローダー以外にもいくつかあった。マスターブートレコードやブートストラップローダーだ。用語が統一されていないという記述もあった。ややこしい (--;; このページではブートローダーを使います。

ブートローダーの名称について

書籍やネットなどで調べていると、マスターブートレコードに
格納されている、OSを起動させるプログラムの名称だが、
ブートローダー以外にもいくつかあった。

マスターブートレコードやブートストラップローダーだ。
用語が統一されていないという記述もあった。ややこしい (--;;

このページではブートローダーを使います。


LILOとGRUBの違いについて

  ブートローダーが何かがわかった。
  ところで、私が知っているブートローダーといえば、LILOとGRUBだ。
  一体、この2つは何が違うのか?

  GRUBの方が便利という声を聞く。
  LILOの場合、設定ファイルを書き換えた後

  /sbin/lilo

  のコマンドを使わないと設定が反映されない上、
起動時にカーネルを読み込まないという問題がある。

  しかし、GRUBの場合は、設定ファイルを変更するだけで、
何も触らなくても設定内容は反映されるという。

  表にすると以下の通りだ。

LILOとGRUBの違い
LILO	設定ファイル/etc/lilo.confの変更だけでなく /sbin/liloのコマンドを使わないと設定が反映されない上、起動時にカーネルを読み込まず何も立ち上がらない。
GRUB	設定ファイル/boot/grub/grub.confを変更するだけで変更内容が反映される。


  ここで思った。

  なんでLILOは /sbin/lilo コマンドが必要やねん！

  考えてみれば、当然の疑問なのだ。
  調べてみると、以下の事がわかった。

  LILOの場合、/sbin/liloのコマンドを使って
カーネルイメージのあるハードディスクのセクタ位置を
マスタブートローダー(MBR)に記録させているというのだ。

/sbin/lilo コマンドの役目

/sbin/liloのコマンドを使って、マスタブートローダー(MBR)にカーネルイメージのあるセクタ位置を記録させているのだ。


  マスタブートローダー(MBR)にカーネルイメージの場所を記録させる事で
マスターブートローダーから、呼び出したいカーネルを起動させる時

  もし、/sbin/liloのコマンドを使わないと以下のようになる。

/sbin/liloのコマンドを使わない場合

マスタブートレコードにカーネルイメージを保管している
ハードディスクのセクタ位置がないため、どこからカーネルイメージを
読み込めば良いのかわからず、Linuxが起動できないという
状態に陥るのだ。


  カーネルイメージを保管しているハードディスクのセクタ位置が変わると
Linuxが呼び出せなくなるため、以下の事も厳禁なのだ。

mvを使ってカーネルイメージを移動

mvやcpなどを使ってカーネルイメージを移動させると、
保管している場所(ハードディスクのセクタ位置)が変わってしまう。
そのため、一度、mvで違うディレクトリやファイル名にし、
それから元に戻しても、セクタ位置が変更してしまったのでは
Linuxが立ち上がらなくなるのだ。


  マスターブートレコードに、カーネルイメージを保管している
ハードディスクのセクタ位置を記録させる必要がある。

  これで/sbin/liloコマンドを使う理由がわかった。

  この手間がないのが、GRUBなので、GRUBが普及しているという話だ。

  本当なら、ここで「LILOの場合はマスターブートローダーに
カーネルイメージのセクタ位置を記録する必要があるに、
GRUBはその必要がないのは何故か?」という疑問を持つべきなのだが、
この時は「そうなの」だった。

  この話については後述しています。

GRUBの設定について

  まずは、設定ファイル /boot/grub/grub.conf を見てみる事にした。

設定ファイル(/boot/grub/grub.conf)
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-53.EL) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img


  これを1つづつ紐解いていく必要がある。
  Webサイトなどを見て、自分の目で確かめて行く事にした。

メニューを隠す
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-53.EL) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img
赤い部分は、ブートローダーが起動した後、呼び出したいOSを選択するメニュー画面を隠す命令だ。


  ふと気づいた。
  そういえば、CentOS4.4やCentOS5.1で、起動時のブートメニューを
見た事がないなぁ。

  Linux2.6系になってからカーネル再構築を行う事をしなかった上、
しかも、GRUBなので、複数のカーネルを選択する機会もない。
  なので、気がつかずにいた。

  どんなOS選択のメニューなのか見てみるため、メニューを隠す設定を
無効にする事にした。

OSを選択するメニューを隠す命令を無効にする
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz #hiddenmenu title CentOS (2.6.18-53.EL) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img
OSを選択するメニューを隠す命令を無効にしてみた。ちなみに「#」はコメント行の印なのだ。そのため不要な命令も「#」で無効にもできる。

OSを選択するメニューを隠す命令を無効にする

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title CentOS (2.6.18-53.EL)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.EL.img

OSを選択するメニューを隠す命令を無効にしてみた。

ちなみに「#」はコメント行の印なのだ。
そのため不要な命令も「#」で無効にもできる。


  すると、OSを選択するメニュー画面が出てきた。

OSを選択するメニュー画面が出てくる

選択できるOSが1つだけなので、選択の余地はないのだが初めて見るCentOSでの、ブート時のOS選択メニューだ。


  次に、以下の2つの設定の意味を見ていく。

メニューに関する設定
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz #hiddenmenu title CentOS (2.6.18-53.EL) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img
青い部分だが、なんとメニュー画面には制限時間がある。その制限時間の設定(秒)を指定するのだ。 timeout=5は、制限時間5秒を意味する。赤い部分は、メニューの制限時間が過ぎた後、自動的に立ち上げるOS(何番目のOS)を指定する部分だ。 N番目のOSを立ち上げたい場合は「N-1」を指定する。 default=0は、1番目のOSをメニューの制限時間後に、自動的に起動させるという意味だ。

メニューに関する設定

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title CentOS (2.6.18-53.EL)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.EL.img

青い部分だが、なんとメニュー画面には制限時間がある。
その制限時間の設定(秒)を指定するのだ。
timeout=5は、制限時間5秒を意味する。

赤い部分は、メニューの制限時間が過ぎた後、
自動的に立ち上げるOS(何番目のOS)を指定する部分だ。
N番目のOSを立ち上げたい場合は「N-1」を指定する。
default=0は、1番目のOSをメニューの制限時間後に、
自動的に起動させるという意味だ。


  なんで制限時間を設けているのかは、意図がわからない。
  でも、停電などでサーバーが落ちた後、自動的に立ち上がる際、


  次は以下の部分の設定を見てみる。

赤い部分は画像に関するものだが
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz #hiddenmenu title CentOS (2.6.18-53.EL) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img
赤い部分に「xpm」という画像に関する拡張子のファイルだから画像に関する設定のようだ。

赤い部分は画像に関するものだが

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title CentOS (2.6.18-53.EL)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.EL.img

赤い部分に「xpm」という画像に関する拡張子のファイルだから
画像に関する設定のようだ。


  一体、何なのか調べてみると、ブートメニューの背景画の設定なのだ。
  スプラッシュ画像なのだが・・・

  スプラッシュって何やねん?

  カタカナでは意味がわからんので、早速、英和辞典で調べてみる。

スプラッシュ(splash)の意味
【名】水しぶき、ザブンという音、金、銭、女【他動詞】散らす、ぬらす、(記事や広告で)目立たせる、書き立てる【自動詞】(水しぶきが)はねる


  いくつか意味があるのだが、メニュー画面に「デーン」と表示させるので

  背景画像やで！

  の意味合いで使っているようだ。

  /boot/grub ディレクトリに格納されている背景画像(splash.xpm.gz)。
  gzipで圧縮されているので解凍して、どんな絵か見てみる事にした。

  すると以下の絵だった。

背景画像(splash.xpm.gz)を見てみる

メニュー画面の壁紙だった。起動時に表示される画像は、プログラムの中に組み込まれていると思い込んでいたが、ここでは違っていた。


  さて、背景の画像を外してみると、どんな画面になるのだろうか。
  早速、実験する事にした。まずは背景画像の設定を外す所から。

赤い部分は画像に関するものだが
default=0 timeout=5 #splashimage=(hd0,0)/grub/splash.xpm.gz #hiddenmenu title CentOS (2.6.18-53.EL) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img
背景画像の設定を無効にしてみる。


  そして再起動させてみる。
  どんな画面が出てくるかなぁと思ったら、以下の画面がでてきた。

背景画像の設定を無効にすると

メニュー画面での背景画像がなくなった。でも、個人的には悪くはないと思ったりする。


  では、背景の画像を差し替えたら、背景画像は変わるのか。
  実験してみる事にした。

  Linuxなのでペンギンの画像を用意した方が良いので、
GPLになっているLinuxのマスコット「Tux」を用意して、以下の加工をした。

用意した画像(Tux)

3段腹のペンギンの「tux」

スプラッシュ画像で使えるのは14色以下の画像で
しかも640x480の大きさの画像だという。

もちろん、この画像はメニュー画面の画像の条件を
満たしていないのだが、条件を満たすための細工を
知らなかったため、このまま使ってみる事にした。


  これをgimpでxpm型式に変換した。
  そして、grub.confを以下のように変更した。

画像を差し替えてみる
default=0 timeout=50 splashimage=(hd0,0)/grub/penguin.xpm.gz #hiddenmenu title CentOS (2.6.18-53.EL) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img

画像を差し替えてみる

default=0
timeout=50
splashimage=(hd0,0)/grub/penguin.xpm.gz
#hiddenmenu
title CentOS (2.6.18-53.EL)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.EL.img


  早速、リブートしてみた。
  すると以下の結果になった。

ペンギンの画像が背景になった

メニュー画面に使える画像の条件である
画像の大きさが640x480で、14色以下を満たしていないため、
上のような表示になった。
一応、ペンギンの画像である事はわかるのだが・・・。


  うーん、14色以下で640x480の大きさにするにはどうすれば良いか。
  そんな時、画像変換の「convert」コマンドがある事を知った。

「convert」コマンドを使ってみる
[suga@server ~]$ convert -geometry 640x480 -color 10 tux.bmp penguin.xpm
640x480の大きさの画像で、色は10色にした。変換前の画像は「tux.bmp」で、変換後は「penguin.xpm」にした。ファイルの拡張子で自動的に画像データの種類を判別してくれる。

「convert」コマンドを使ってみる

[suga@server ~]$ convert -geometry 640x480 -color 10 tux.bmp penguin.xpm

640x480の大きさの画像で、色は10色にした。
変換前の画像は「tux.bmp」で、変換後は「penguin.xpm」にした。
ファイルの拡張子で自動的に画像データの種類を判別してくれる。


  「convert」コマンドで、条件を満たした画像を使ってみた。
  すると・・・

  表示は成功なのだ！！

  だった。

綺麗なペンギンの画像が背景になった

下半分が真っ黒ですが、走査線の影響のためです。実際に人間の目では綺麗に見えました。


  これで、ブートのメニュー画面の背景画像を、好きな画像に
変更できるようになった。


  次に、複数のOSをブートする時の設定を見てみる。

設定ファイル(/boot/grub/grub.conf)
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-53) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img
赤い部分は、メニューが画面に表示される「起動したいOS」の表記を設定する。 LILOとの違いは空白文字が使えるのだ。実際、上の例でも「CentOS」と「(2.6.18-53)」の間には 1コマ、空白文字が入っているのだ。

設定ファイル(/boot/grub/grub.conf)

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-53)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.EL.img

赤い部分は、メニューが画面に表示される「起動したいOS」の
表記を設定する。

LILOとの違いは空白文字が使えるのだ。
実際、上の例でも「CentOS」と「(2.6.18-53)」の間には
1コマ、空白文字が入っているのだ。


  さて、複数のOSを起動させる時は「title」部分からはじまり、
読み込むOSを指定したりする。

  そこで、複数のOSを設定するつもりで、「title」の部分だけを変更した物を
追加してみる事にした。

設定ファイル(/boot/grub/grub.conf)
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-53) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img title Acho!!! root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img
赤い部分は初期設定青い部分は、titleを「Acho!!!」にした。カンフー映画を連想しそうなのだ。それ以外の読み込みたいOSは、上と同じにした。複数のOSを入れる手間は省いた手抜きなのだ (^^;;

設定ファイル(/boot/grub/grub.conf)

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-53)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.EL.img

title Acho!!!
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.EL.img

赤い部分は初期設定

青い部分は、titleを「Acho!!!」にした。
カンフー映画を連想しそうなのだ。
それ以外の読み込みたいOSは、上と同じにした。
複数のOSを入れる手間は省いた手抜きなのだ (^^;;


  ブートしなおしてみる。
  すると以下の画面が出てきた。

ブートのメニュー画面

選択肢ができるようになった。もちろん「Acho!!!」が反映されている。


  もちろんメニュー画面の背景画像を省いた場合は
以下のように表示される。

ブートのメニュー画面

同じように選択肢が出てきた。



  さて、ブート時にパスワードが設定できるという。
  「password」というコマンドを使えば良いという。
  なので、早速、以下の設定を行ってみた。

設定ファイル(/boot/grub/grub.conf)
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu password test title CentOS (2.6.18-53.EL) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img
赤い部分はパスワードの設定。パスワードは「test」にしてみた。

設定ファイル(/boot/grub/grub.conf)

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
password test
title CentOS (2.6.18-53.EL)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.EL.img

赤い部分はパスワードの設定。
パスワードは「test」にしてみた。


  早速、ブートをしてみるが

  うまくいかへん （ＴＴ）

  だった。
  もしかして、呼び出したいOSの設定の部分の後ろにつけるのではと思い
以下のように変更してみた。

設定ファイル(/boot/grub/grub.conf)
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-53.EL) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img password test
赤い部分はパスワードの設定。パスワードは「test」にしてみた。

設定ファイル(/boot/grub/grub.conf)

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-53.EL)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.EL.img
        password test

赤い部分はパスワードの設定。
パスワードは「test」にしてみた。


  すると・・・

   パスワードを求めてきた (^^)

パスワードを求める様子

パスワードを入力する時は「*」で隠されるため
後ろから誰かに画面を見られてもバレない。

まぁ、キーボードを見られては、どうしようもないけど (^^;;


  だが、このままではセキュリティーとしては甘いままだ。
  GRUBの設定ファイルである/boot/grub/grub.conf では、
平文でパスワードを設定しているからだ。

  CentOS4.4、5.1で見る限り、grub.confの権限を見てみると
管理者のrootのみ、読み書き可能になっているので、一般ユーザーから
平文のパスワードを見られる心配はないのだが、root権限を奪取された場合は
完全に丸見えとなる。

  よりパスワードを安全にするため、MD5という不可逆暗号化を使って、
パスワードを暗号化して設定する方法がある。

  まずは、grubコマンドを使って、MD5の不可逆暗号を使って
暗号化パスワードを算出する。

grubコマンドを使って MD5の暗号化パスワードの生成
grub> md5crypt Password: **** Encrypted: $1$pHvrb$h7ac0n0t/LTz6i2HQSiKB0 grub>
青い部分がMD5の暗号化を生成するための命令。そして暗号化したいパスワードを入力する。ピンクの部分が算出された暗号化パスワード。
設定ファイル(/boot/grub/grub.conf)
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-53.EL) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img password --md5 $1$pHvrb$h7ac0n0t/LTz6i2HQSiKB0
passwordの後ろに「--md5」のオプションをつけてその後ろに暗号化したパスワードを記述する。これによって、サーバーを起動させた後、パスワードが簡単にバレる事はなくなる。もちろん、シラミ潰しでパスワードを調べる方法もあるがそれは横に置いておく (^^)


  パスワードの話はこの辺で終わらせます。


  さて、OSを呼び出す設定部分を見ていく事にした。

設定ファイル(/boot/grub/grub.conf)

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-53.EL)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.EL.img

赤い部分は、カーネルイメージが格納されている場所を
GRUBに知らせるための記述。

「hd0,0」の表記は、1番目のハードディスクの
1番目のパーティションに格納されているという意味になる。

これがフロッピーディスクなら「fd0,0」だったりする。


  ここで思った。

  なんでハードディスクが「hd0,0」やねん！

  ハードディスクのデバイス名は、IDEの場合は「hda」だったり
SCSIは「sda」だったりする。

  そう、ハードディスクの場合、デバイス名は以下のようになっている。

IDEハードディスクの場合
(Linuxの場合)

頭の「hd」は「Hard Disk」の略だと思う。
そして一番目のディスクは「a」、2番目のディスクは「b」
といった感じで、アルファベッドで番号が振られる。


  これでハードディスクそのものを表す事ができるのだが、
ディスクパーティションをしているため、同じハードディスクでも
領域を分けている。
  そのため、パーティションを区別するため、以下のような
番号の振り方をしている。

IDEハードディスクの場合 (Linuxの場合)

数字でパーティションの番号を割り振っている。 1番目は「1」、2番目は「2」といった感じだ。


  なので、dfコマンドを使ってハードディスクの様子を見てみると
以下のように表示されるのだ。

dfコマンドを使うと
suga@jitaku[~/test]% df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 47300056 2678268 42180312 6% / /dev/hda3 46140116 2931796 40826684 7% /home /dev/hda1 20472816 8391600 12081216 41% /win

dfコマンドを使うと

suga@jitaku[~/test]% df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda2             47300056   2678268  42180312   6% /
/dev/hda3             46140116   2931796  40826684   7% /home
/dev/hda1             20472816   8391600  12081216  41% /win


  次にSCSIのハードディスクの場合を見てみる。

SCSIハードディスクの場合
(Linuxの場合)

頭の「sd」は「SCSI Disk」の略だと思う。
そして一番目のディスクは「a」、2番目のディスクは「b」
といった感じで、アルファベッドで番号が振られる。

SCSIハードディスクの場合 (Linuxの場合)

数字でパーティションの番号を割り振っている。 1番目は「1」、2番目は「2」といった感じだ。



  では、一体、「hd0,0」といった表記は、どういう意味を表すのだろうか。
  調べてみると以下の事が前提だった。

  IDEとSCSIを区別しない！

  ハードディスクの形態を無視して、純粋(?)に順番で識別するという。

  それを前提に見ていくと、「hd0,0」の意味合いは以下の事だった。

「hd0,0」の意味合い

頭の「hd」は、Hard Diskの略だと思う。数字はハードディスクの番号と、パーティションの番号だ。番号の開始は「0」からになっているのに注意!


  なので、図にすると以下のようになる。

「hd0,0」の意味合い

図のようにハードディスクの番号、パーティションの番号が割り振られる。番号は「0」から始まる。


  うーん、こんな表記法があったとは知らなかった。
  もしかして、GRUB独特の表記法かもしれない。

  実際に、grub.confの設定と、dfで見た結果を比較してみる

設定ファイル(/boot/grub/grub.conf)
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS-4 i386 (2.6.9-42.EL) root (hd0,0) kernel /vmlinuz-2.6.9-42.EL ro root=LABEL=/1 rhgb quiet initrd /initrd-2.6.9-42.EL.img
dfコマンドの結果
[root@server]# df Filesystem 1K-ブロック使用使用可使用% マウント位置 /dev/sda5 27213884 5591824 20239672 22% / /dev/sda1 248895 5015 231030 3% /boot none 517300 0 517300 0% /dev/shm /dev/sda2 171347196 6537032 156106148 5% /home /dev/sda3 40313996 1306244 36959868 4% /usr/local [root@server]#
grub.confの設定で、カーネルイメージを保管しているハードディスクの場所を(hd0,0)としている。 1番目のディスクで、1番目のバーティションに保管されている事を示している。実際、dfコマンドで確認した結果、1番目のディスクで、 1番目のバーティションになっている事がわかる。



  次に、起動させたいOSの読み込みだが、Linuxを起動させたい場合は、
どのカーネルイメージを読み込むのかを設定する必要がある。

設定ファイル(/boot/grub/grub.conf)

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-53.EL)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.EL.img

赤い部分が読み込むカーネルイメージのファイルだ。
青い部分はオプションだ。


  オプションを調べてみる。

オプション
ro	マウントしたディレクトリを読み込み可能にする設定。「rw」にすれば読み書き可能になる
root=XXX	カーネル起動時に、どのデバイスをルートディレクトリにするのかを指定する (例) root=/dev/hda1 「root=LABEL=/」の場合、「LABEL=/」は/etc/fstabに記述されている

オプション

マウントしたディレクトリを
読み込み可能にする設定。
「rw」にすれば読み書き可能になる

root=XXX

カーネル起動時に、どのデバイスを
ルートディレクトリにするのかを指定する

(例) root=/dev/hda1

「root=LABEL=/」の場合、「LABEL=/」は/etc/fstabに
記述されている


  しかし、2つのオプションの意味がわからない。

わからない2つのオプション
rhgb
quiet


  Webで設定内容を探すが見つからない。
  GRUBのサイトのマニュアルを見る事にした。
  http://www.gnu.org/software/grub/manual/grub.html

  嫌々、英語を読んだのだが・・・

  どこにも書いてへん （ＴＴ）

  それでも諦めずに探してみるとIBMのサイトで見つかった。
  すると以下の意味がある事を知った。

オプション
rhgb	起動画面がGUIにする
quiet	起動時の詳しいメッセージを省略する。「quiet」は「静か」なので、上手な表現だと思う。


  そこで「rhgb」を付けた場合の起動画面と、付けていない場合の
起動画面を比較してみた。

「rhgb」のオプション有(GUIで起動)

「rhgb」のオプション無


  「rhgb」のオプションは、RedHat系のみで使えるオプションかもしれない。
  だが、他のディストリビューションで試していないので、
断定はできないのだが (^^;;


  ところで、ふと気づいた。
  カーネルイメージのオプションは

  GRUBのオプションと関係あらへんやん！

  だった。

  つまり、Linuxカーネルが起動する時に使うためのオプションなので、
いくらGRUBのマニュアルを見ても載っていないはずだった。

  ブートローダーに依存しないオプションなので、逆にいえば、
LILOを使った場合でも、このオプションは使えるというのだ。

  納得できた (^^)


  次にinitrdイメージを読み込む場合の設定だ。

設定ファイル(/boot/grub/grub.conf)
default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-53.EL) root (hd0,0) kernel /vmlinuz-2.6.18-53.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.18-53.EL.img
赤い部分がinitrdイメージのファイルを読み込むための設定だ。


  ここで思った。

  一体、initrdイメージって何やねん?

  今までカーネル再構築した時、initrdイメージファイルは
取り込まなかったのだが、支障はなかった。
  だが、知らないまま「大丈夫であろう」と放置するのは良くないので
調べる事にした。

  initrdイメージファイルの話ですが、書き出すと収拾がつかないので
今回は割愛しました。
　詳しくは「initrdファイルって何?」(システム奮闘記:その72)を
ご覧下さい。

GRUBの仕組み

  一通りGRUBの設定ファイルについては理解できた。

  だが、疑問が出てきた。


  LILOの場合、/etc/lilo.conf の設定ファイルの内容を反映させるために
/sbin/liloコマンドを使う。

  それは、設定ファイルの内容と、カーネルイメージのセクタ位置を
マスターブードローダー(MBR)という領域に記録させるためだった。

  もし、カーネルイメージの移動やカーネル再構築の後に、
/sbin/liloコマンドを使う事を怠ると、再起動の際、
カーネルイメージのセクタ位置がわからないため、カーネルが
起動できなくなる問題が起こるのだ。

  カーネルイメージのセクタ位置を記録する理由だが、
ブートローダーを起動させた時、以下の問題があるからだ。

ファイルシステムが認識できない

ブートローダーのLILOには、ファイルシステムが認識できない。
そのため、設定ファイルの/etc/lilo.conf はもちろんの事、
読み込むカーネルイメージの場所もわからない状態のため、
読み込む事ができなくなる問題が発生する。


  ファイルシステムは、データファイルが、ハードディスクのどのセクタ位置に
保管されているのかを管理しているプログラムなのだ。
  管理データもハードディスクに保管されている。

  だが、ファイルシステムのプログラムがない場合、ハードディスクの
どのセクタ位置にカーネルイメージ等が保管されているのかは
全くわからないのだ。

  そこで以下のような対処の仕方をしているのだ。

セクタ位置を記録しておく

マスターブートレコード(MBR)の領域に、カーネルイメージのセクタ位置を保管する事で、カーネルイメージを読み込む事ができる。


  もし、カーネルイメージのセクタ位置が変更しても、
/sbin/liloコマンドを怠ると以下の問題が発生する。

セクタ位置が変わると

もし、mvやカーネル再構築で、カーネルイメージのセクタ位置が
変わったにも関わらず、/sbin/liloコマンドを怠ると

マスターブートレコード(MBR)の領域に記録すべきカーネルイメージの
セクタ位置が変更しないため、カーネルイメージを読み込む事が
できなくなるのだ。


  だが、GRUBは、設定ファイルの中身を変更した後、何もしなくても
設定内容が反映される。

セクタ位置が変更になっても問題なし

GRUBの場合、設定ファイルを変更したり、mvなどで
カーネルイメージのセクタ位置を変更した後に、何もしなくても
問題なくカーネルを起動させる事ができる。


  なので
  
  一体、なんでやねん?

  と疑問に思う。


  調べていくと以下の記述に出くわす。

出くわした記述の内容
GRUBは様々なファイルシステムを理解して、カーネルのファイル名を読み込む事ができる高度なブートローダーだ。


  つまり、GRUBはファイルシステムを認識できるため、ハードディスク内の
ファイルを、ファイル名で読み込む事ができるのだという。

  それで/boot/grub/grub.confの設定ファイルを変更した後に
何もしなくても良い理由がわかった。


  実際に、GRUBがファイルシステムを認識しているのかどうかを確かめたくなる。
  どうやって確かめれば良いのか。単純な発想に行き着く。

  オープンソースなのでソースコードを読めばええやん！

  ソースコードを解読できるだけの実力なんてあるわけないのに、
なんて、安直で短絡的な発想をしてしまうのだと自分でも感心する。

  早速、CentOS5.1で使われているGRUBのバージョンをダウンロードする。

  grub-0.97.tar.gz

  なのだ。ダウンロードして展開する。
  ソースコードのディレクトリーを眺めていると、ある発見があった。

stage2のディレクトリを見て

suga@server[~/src/grub-0.97/stage2]% ls
Makefile.am  console.c         fsys_fat.c       hercules.h     pc_slice.h   start.S
Makefile.in  defs.h            fsys_ffs.c       i386-elf.h     pxeloader.S  start_eltorito.S
apic.h       dir.h             fsys_iso9660.c   imgact_aout.h  serial.c     term.h
apm.S        disk_inode.h      fsys_jfs.c       iso9660.h      serial.h     terminfo.c
asm.S        disk_inode_ffs.h  fsys_minix.c     jfs.h          setjmp.S     terminfo.h
bios.c       disk_io.c         fsys_reiserfs.c  mb_header.h    shared.h     tparm.c
boot.c       fat.h             fsys_ufs2.c      mb_info.h      size_test*   tparm.h
builtins.c   filesys.h         fsys_vstafs.c    md5.c          smp-imps.c   ufs2.h
char_io.c    freebsd.h         fsys_xfs.c       md5.h          smp-imps.h   vstafs.h
cmdline.c    fs.h              gunzip.c         nbi.h          stage1_5.c   xfs.h
common.c     fsys_ext2fs.c     hercules.c       nbloader.S     stage2.c
suga@server[~/src/grub-0.97/stage2]%

赤い部分はファイルシステムに関するソース。
Linuxで標準的に使われるファイルシステムなどがある。


  これを見た時

  だからGRUBはファイルシステムを認識できるのか！

  と思った。

  ファイルシステムが認識できれば、わざわざハードディスクの
セクタ位置を記録しなくても、ファイル名(絶対パス)だけで、
どこに保管されているのかが特定できる。
  なので、設定ファイルの「/boot/grub/grub.conf」を読み込む事ができる。

  ふと、GRUBの設定関係のファイルのディレクトリを見てみる。
  (あくまでも、CentOS4.4、5.1の話です)

/boot/grubディレクトリ
(あくまでも、CentOS4.4、5.1の話です)

[root@server]# ls -l
合計 180
-rw-r--r-- 1 root root    197  7月 15 15:58 default
-rw-r--r-- 1 root root     30  7月 15 15:58 device.map
-rw-r--r-- 1 root root   7552  7月 15 15:58 e2fs_stage1_5
-rw-r--r-- 1 root root   7424  7月 15 15:58 fat_stage1_5
-rw-r--r-- 1 root root   6688  7月 15 15:58 ffs_stage1_5
-rw-r--r-- 1 root root   6720  7月 15 15:58 iso9660_stage1_5
-rw-r--r-- 1 root root   8192  7月 15 15:58 jfs_stage1_5
-rw-r--r-- 1 root root   6848  7月 15 15:58 minix_stage1_5
-rw-r--r-- 1 root root   9216  7月 15 15:58 reiserfs_stage1_5
-rw-r--r-- 1 root root    512  7月 15 15:58 stage1
-rw-r--r-- 1 root root 100490  7月 15 15:58 stage2
-rw-r--r-- 1 root root   7040  7月 15 15:58 ufs2_stage1_5
-rw-r--r-- 1 root root   6240  7月 15 15:58 vstafs_stage1_5
-rw-r--r-- 1 root root   8840  7月 15 15:58 xfs_stage1_5
[root@server]#

実行ファイルのような形で、各ファイルシステムを読み込む
プログラムが格納されている。



  さて、GRUBのブートローダーについて調べていくと、BIOS起動の後から
カーネル起動までの間に、2つのプログラムが動くという。

  stage1とstage2なのだ。

/boot/grubディレクトリ
(あくまでも、CentOS4.4、5.1の話です)

[root@server]# ls -l
合計 180
-rw-r--r-- 1 root root    197  7月 15 15:58 default
-rw-r--r-- 1 root root     30  7月 15 15:58 device.map
-rw-r--r-- 1 root root   7552  7月 15 15:58 e2fs_stage1_5
-rw-r--r-- 1 root root   7424  7月 15 15:58 fat_stage1_5
-rw-r--r-- 1 root root   6688  7月 15 15:58 ffs_stage1_5
-rw-r--r-- 1 root root   6720  7月 15 15:58 iso9660_stage1_5
-rw-r--r-- 1 root root   8192  7月 15 15:58 jfs_stage1_5
-rw-r--r-- 1 root root   6848  7月 15 15:58 minix_stage1_5
-rw-r--r-- 1 root root   9216  7月 15 15:58 reiserfs_stage1_5
-rw-r--r-- 1 root root    512  7月 15 15:58 stage1
-rw-r--r-- 1 root root 100490  7月 15 15:58 stage2
-rw-r--r-- 1 root root   7040  7月 15 15:58 ufs2_stage1_5
-rw-r--r-- 1 root root   6240  7月 15 15:58 vstafs_stage1_5
-rw-r--r-- 1 root root   8840  7月 15 15:58 xfs_stage1_5
[root@server]#

stage1とstage2の実行ファイルがある。
これらがBIOSが起動した後、カーネルが起動するまでの間に
起動するプログラムなのだ。


  プログラムソースを見てみる。

grub-0.97を展開したディレクトリ

suga@server[~/src/grub-0.97]% ls
AUTHORS      Makefile.in   compile*       docs/           stage1/
BUGS         NEWS          config.guess*  grub/           stage2/
COPYING      README        config.h.in    install-sh*     util/
ChangeLog    THANKS        config.sub*    lib/
INSTALL      TODO          configure*     missing*
MAINTENANCE  acinclude.m4  configure.ac   mkinstalldirs*
Makefile.am  aclocal.m4    depcomp*       netboot/
suga@server[~/src/grub-0.97]%

「stage1」と「stage2」のソースコードが格納された
ディレクトリがある。



  調べていくと、GRUBの場合、2段階の過程を経て、カーネルを読み込む
仕組みになっているのだ。

GRUBを使ったOS起動までの流れ

stage1

第一段階としてstage1のプログラムを稼働させる。
このプログラムはハードディスクの先頭セクタである
マスターブートレコードに保管されている。

役目はstage2というプログラムを読み込むのみで
stage2が置かれているセクタの位置を記録している

stage2

第二段階として、stage2のプログラムが稼働する。

Linuxなどに使われる複数のファイルシステムに対応できるため、
ハードディスクの中身を認識できる。
そのため、grub.confを読み込む事ができる。

そして、メニュー画面で選択されたOSを起動させる。


  これを簡単な図すると以下のようになる。

GRUBの働き


  stage1のプログラムは、ハードディスクの先頭セクタである
マスターブートレコード(MBR)に保管されている。

stage1のプログラムの格納場所

マスターブートレコードの領域は、1セクタのため、
512バイトしかない。
そのため、高度なプログラムを載せる事ができないため
単に、stage2を読み込むだけのプログラムになっている。

/boot/grubディレクトリ
(あくまでも、CentOS4.4、5.1の話です)

[root@server]# ls -l
合計 180
-rw-r--r-- 1 root root    197  7月 15 15:58 default
-rw-r--r-- 1 root root     30  7月 15 15:58 device.map
-rw-r--r-- 1 root root   7552  7月 15 15:58 e2fs_stage1_5
-rw-r--r-- 1 root root   7424  7月 15 15:58 fat_stage1_5
-rw-r--r-- 1 root root   6688  7月 15 15:58 ffs_stage1_5
-rw-r--r-- 1 root root   6720  7月 15 15:58 iso9660_stage1_5
-rw-r--r-- 1 root root   8192  7月 15 15:58 jfs_stage1_5
-rw-r--r-- 1 root root   6848  7月 15 15:58 minix_stage1_5
-rw-r--r-- 1 root root   9216  7月 15 15:58 reiserfs_stage1_5
-rw-r--r-- 1 root root    512  7月 15 15:58 stage1
-rw-r--r-- 1 root root 100490  7月 15 15:58 stage2
-rw-r--r-- 1 root root   7040  7月 15 15:58 ufs2_stage1_5
-rw-r--r-- 1 root root   6240  7月 15 15:58 vstafs_stage1_5
-rw-r--r-- 1 root root   8840  7月 15 15:58 xfs_stage1_5
[root@server]#

stage1のファイルの大きさは、ハードディスクの先頭のセクタである
マスターブートレコードの512バイトに納まる大きさだ。


  ところで、第2段階のプログラム「stage2」のセクタ位置がわからないと
stage2のプログラムが呼び出せない。
  そのため、stage1にはstage2のセクタ位置を保管する機能がある。

stage1は「stage2」のセクタ位置を保管している


  そのため、stage1のプログラムは、第2段階のプログラム「stage2」を
呼び出す事ができる。

stage1はstage2のセクタ位置を記録している

stage1は、stage2のセクタ位置を記録しているため、ファイルシステムが認識できなくても、stage2を読み込む事ができる。


  そして、stage1が呼び出したstage2のプログラムは、いくつかの
ファイルシステムを認識できる。

stage2はファイルシステムを認識できる

GRUBのブートローダーで、第2段階のプログラムであるstage2はいくつかのファイルシステムを認識できる。


  そのため、stage2は設定ファイルの grub.conf や
カーネルイメージをファイル名を使って読み込む事ができる。

stage2はファイル名で取り込める

stage2は、ファイルシステムを認識できる事から、ファイル名で
ハードディスク内にあるデータを探す事ができる。
そのためカーネルイメージや設定ファイルをファイル名で
読み込む事が可能になるのだ。


  これで設定ファイル grub.conf を変更した後、
何もしなくても変更した内容が反映される理由がわかった (^^)


  ところで、stage1は、stage2のセクタ位置を記録している。
  そのため以下の事をしたら、ブートできなくなるというのだ。

こんな事をするとブートできなくなる


  LILOでは、カーネルイメージを移動させたりして、セクタ位置を変えると
起動できなくなる話だが、GRUBではstage2のプログラムのセクタ位置を
変えるとブートできなくなるというのだ。

  では、論より証拠で実験してみる事にした。

ディスクパーティションの様子
[root@server]# df Filesystem 1K-ブロック使用使用可使用% マウント位置 /dev/sda2 234389980 4232016 218059416 2% / /dev/sda1 101086 16343 79524 18% /boot tmpfs 1033776 0 1033776 0% /dev/shm [root@server]#
/bootディレクトリと、それ以外ではパーティションの位置の違いがある。そこで以下のように移動させた。
stage2のプログラムの移動
[root@server]# pwd /boot/grub [root@server]# mv stage2 / [root@server]# mv /stage2 .
赤い部分でstage2の実行ファイルを、別のパーティションへ移動させる。そして青い部分で、元のディレクトリーに戻すのだが、最初のセクタ位置に移動するとは限らない。もし、違うセクタ位置に置かれた場合、ブートできない事が示せる。


  早速、再起動をかけてみた。すると・・・

  やっぱりブートができへんのらー！！

  だった。
  論より証拠。自分の目で確かめたので堂々と言えるのだ (^^)

マスターブートレコード(MBR)の仕組み

  概略としてGRUBの仕組みがわかったのだが、もう一歩踏み込んで
マスターブートレコード(MBR)そのものを見てみる事にした。

  色々調べてみると以下のサイトを発見した。
  http://caspar.hazymoon.jp/OpenBSD/arch/i386/stand/mbr/mbr_structure.html
  http://nobumasa-web.hp.infoseek.co.jp/boot/boot.html


  512バイトの領域のマスタブートレコードは以下の構造になっているという。

マスタブートレコード(MBR)の構造

512バイトの領域の中の最初の446バイトはOSを呼び出すための
ブートレコーダーのプログラムの領域

4つのパーティションテーブルがある。個々に16バイトある。
これは、そのパーティションの中に保管されている
OSのカーネルイメージのディスク上の位置を記録するための領域だ。

最後にシグネチャーという2バイトの領域だ。


  詳しく見ていく。
  まずはシグネチャー領域から。

シグネチャー領域

シグネチャー領域には「0xaa55」という値が入っている。
もし、この値が入っていない場合、このディスクは
ブートできないという仕組みになっている。

このブートレコーダーが正当な物であるという印で
その値が「0xaa55」だという。


  論より証拠で、実際に「0xaa55」の値が入っているのかどうかを
確かめてみる事にした。

  ハードディスクのセクタの先頭の512バイトのイメージを
取り出すには以下のコマンドを使う。

セクタの先頭の512バイトのイメージを取り出す

[root@server]# dd if=/dev/sda of=image-out bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 5.5158e-05 seconds, 9.3 MB/s
[root@server]#

ddコマンドを使う。
このコマンドを使えば、ハードディスクの先頭セクタから512バイト分の
データをハードディスクの中身に記録されている状態で取り出せる。


  そして、取り出した中身を、16進数の型式で表示させてみる。

取り出した中身を、16進数の型式で表示

[root@server]# od -x image-out 
0000000 48eb 1090 d08e 00bc b8b0 0000 d88e c08e
0000020 befb 7c00 00bf b906 0200 a4f3 21ea 0006
0000040 be00 07be 0438 0b75 c683 8110 fefe 7507
0000060 ebf3 b416 b002 bb01 7c00 80b2 748a 0203

(途中、省略)

0000720 0c41 fe83 ffff b20c 0041 5eac 1cd8 0000
0000740 0d01 fe82 0b7f 2fcd 0003 823f 003e 0000
0000760 0000 0000 0000 0000 0000 0000 0000 aa55
0001000
[root@server]#

odコマンドを使って、データの中身を16進数表示で見てみる。
そしてデータの最後の部分にシグネチャの値「aa55」があった。


  やはり自分の目で見ると納得できる (^^)

  この部分を書き換えて、実際にブートができるのかどうかを
確認してみたかったが、さすがに、そこまでの技術力はないし、
調べるのも面倒だ。
  そこで、GRUBのソースコードで、恐らく、シグネチャの判定をしている部分を
見てみる事にした。

stage2/asm.S (grub-0.97のソース)

	/* check the result */
	jc	1f
	cmpw	$0xaa55, %bx
	jne	1f

	movb	%ah, %bl	/* save the major version into %bl */

「0xaa55」の値がある。
しかも、命令分が「cmpw」なので比較命令と思われるので、
ここでシグネチャの値の確認をしていると思ったりする。
でも、私はアセンブラは全く読めないので、
あくまでも予想にすぎない。


  こんな時、ハードウェアの知識とアセンブラの知識があれば
GRUBの詳細な仕組みがわかるのだが、そんな知識は全くない。
  もし「勉強しろ!」という声があれば、堂々と反論します。

  事務員だから無理だもーん (^^)

  常套手段を使って逃げた所で、次に進みます。


  パーティションテーブルを見てみる。

パーティションテーブルの構造

マスターブートレコードには4つのパーティションテーブがある。パーティションテーブは16バイトの領域で、上図の構造になっている。


  1つ1つ見ていく事にする。
  まずはブートフラグから。

ブートフラグ

ブートフラグの値が「0x80」なら、そのパーティションはブート可能を意味する。「0x0h」ならブート不可を意味する。


  さて論より証拠で、マスターブートレコードのイメージデータを
16進数型式で見てみる事にした。

  その前に、dfコマンドでカーネルイメージが格納された
パーティションを確認してみる。

ディスクパーティションの様子

[root@server]# df
Filesystem           1K-ブロック    使用   使用可 使用% マウント位置
/dev/sda2            234389980   3219176 219072256   2% /
/dev/sda1               101086     10884     84983  12% /boot
tmpfs                  1033776         0   1033776   0% /dev/shm
[root@server]#

第1パーティションの「sda1」は「/boot」をマウントしている。
/bootにはカーネルイメージが格納されているため、
第1パーティションでブート可能にしておく必要がある。


  dfコマンドの結果を踏まえて、マスターブートレコードのイメージを
見てみる事にした。

マスターブートレコードのイメージデータ

[root@server]# od -x image-out 
0000000 48eb 1090 d08e 00bc b8b0 0000 d88e c08e
0000020 befb 7c00 00bf b906 0200 a4f3 21ea 0006
0000040 be00 07be 0438 0b75 c683 8110 fefe 7507
0000060 ebf3 b416 b002 bb01 7c00 80b2 748a 0203

(途中、省略)

0000540 be7c 7d85 40e8 eb00 be0e 7d8a 38e8 eb00
0000560 be06 7d94 30e8 be00 7d99 2ae8 eb00 47fe
0000600 5552 2042 4700 6f65 006d 6148 6472 4420
0000620 7369 006b 6552 6461 2000 7245 6f72 0072
0000640 01bb b400 cd0e ac10 003c f475 00c3 0000
0000660 0000 0000 0000 0000 c503 0009 0000 0180
0000700 0001 fe83 0c3f 003f 0000 2f8e 0003 0000
0000720 0c41 fe83 ffff b20c 0041 5eac 1cd8 0000
0000740 0d01 fe82 0b7f 2fcd 0003 823f 003e 0000
0000760 0000 0000 0000 0000 0000 0000 0000 aa55
0001000
[root@server]#

ブートフラグの部分だけ色をつけてみた。
第1パーティションは「80」なのでブート可能。
その他のパーティションは「00」なのでブート不可になっている。

dfコマンドで見た時、第1パーティションにカーネルイメージがある。
そのため、第1パーティションはブート可能にする必要があるが、
ブートフラグを見て、ブート可能になっていた。

(注意)
リトルエンディアンとビッグエンディアンの違いによって
他のサイトでの16進数表示の違いが出ていると思う。


  次にパーティションタイプを見てみた。

パーティションタイプ

この部分は、そのパーティションで使われているファイルシステムを記録する部分だ。


  パーティションタイプに入る値の表が以下のサイトにある。
  http://www.win.tue.nl/~aeb/partitions/partition_types-1.html

  いくつかのファイルシステムを表にしてみた。

パーティションタイプの値
値	内容
00	何も入っていない
07	Windows NT NTFS
0c	Windows95 OSR2 FAT32, LBA-mapped
a5	BSD/386, 386BSD, NetBSD, FreeBSD
82	Solaris x86
82	Linux swap領域
83	Linux パーティション


  「82」はLinuxのスワップ領域と、Solaris x86用と共用しているのだ。
  必ずしも、1つの値に1つの内容ではないみたいだ。

  さて、ブートレコードのイメージデータで、パーティションタイプを
見てみる事にする。

ディスクパーティションの様子

[root@server]# df
Filesystem           1K-ブロック    使用   使用可 使用% マウント位置
/dev/sda2            234389980   3219176 219072256   2% /
/dev/sda1               101086     10884     84983  12% /boot
tmpfs                  1033776         0   1033776   0% /dev/shm
[root@server]#

第1パーティションの「sda1」と第2パーティションの「sda2」は
普通のLinuxのパーティションで、ここで見えていないのが
Linuxのスワップ領域だ。


  上のdfコマンドの結果を踏まえた上で、イメージデータを見てみる。

マスターブートレコードのイメージデータ

[root@server]# od -x image-out 
0000000 48eb 1090 d08e 00bc b8b0 0000 d88e c08e
0000020 befb 7c00 00bf b906 0200 a4f3 21ea 0006
0000040 be00 07be 0438 0b75 c683 8110 fefe 7507
0000060 ebf3 b416 b002 bb01 7c00 80b2 748a 0203

(途中、省略)

0000540 be7c 7d85 40e8 eb00 be0e 7d8a 38e8 eb00
0000560 be06 7d94 30e8 be00 7d99 2ae8 eb00 47fe
0000600 5552 2042 4700 6f65 006d 6148 6472 4420
0000620 7369 006b 6552 6461 2000 7245 6f72 0072
0000640 01bb b400 cd0e ac10 003c f475 00c3 0000
0000660 0000 0000 0000 0000 c503 0009 0000 0180
0000700 0001 fe83 0c3f 003f 0000 2f8e 0003 0000
0000720 0c41 fe83 ffff b20c 0041 5eac 1cd8 0000
0000740 0d01 fe82 0b7f 2fcd 0003 823f 003e 0000
0000760 0000 0000 0000 0000 0000 0000 0000 aa55
0001000
[root@server]#

第1パーティションと第2パーティションは「83」なので
Linuxのパーティションを意味する。
dfコマンドで見た時、第1パーティションと第2パーティションが
普通のLinuxのパーティションになっているのと一致した。

第3パーティションは「82」なので、Linuxのスワップ領域を表す。
dfコマンドで見えていなかった部分だ。

パーティションは3つしか作成していないため、
第4パーティションは何も入っていない事を意味する
「00」の値になっている。


  次に、パーティションの開始場所を表す部分を見ていく。
  ハードディスクの位置を表す方法が2種類ある。
  CHS方式とLBA方式だ。

  なんだか、わかった風に書いているのだが、実際は・・・

  CHSもLBAも、どっかで見た事がある程度なのらー!!

  だった。
  確か、ハードディスクの位置情報を表す方式だった記憶がある。
  そこで、BIOS関係の本を取り出してみた。

  それにしても、GRUBの設定で軽い気持ちで取り上げたのだが、
いつの間に、ハードディスクの話にまで及んできた。

  まずはCHS(Cylinder/Head/Sector)方式から。

CHS(Cylinder/Head/Sector)方式

シリンダ、ヘッダー、セクタの3つの座標を使って
ハードディスクの位置を表現する方法だ。
それぞれ10ビット、8ビット、6ビットを使っている。
合計すると24ビット(3バイト)だ。


  ところで何故、CHS方式以外に、LBA方式があるのか。
  CHS方式には、大容量のハードディスクでは使えない問題があるからだ。

CHS方式の問題点

2の24乗のセクタ数を表現する事ができる。
多そうに見えるが、実は大した事がない。
1セクタは512バイトなので、理論的にCHSが最大網羅できる
ハードディスクの容量は約8.5Gバイトになる。

今の時代、8.5Gなんて大した事がない。


  CHS方式だと、たった8.5Gバイトしか表現できないため、
それより容量の大きいハードディスクがあっても
パーティション開始位置に記録する事ができない。

  そのため8.5G以上のハードディスクが見えない問題が発生する。

  それを解消するのが、LBA方式だという。

LBA(Logical block Addressing)方式

先頭のセクタから順番に番号を割り振る方式だ。 4バイト(32ビット)を使う。


  バイト数も「3」から「4」に増えた事で、表現できる値が増える。

LBA(Logical block Addressing)方式

理論的には、2の32乗個のセクタが見れる事になる。 1セクタあたり512バイトなので、単純計算すると 2Tバイトのハードディスクが見れる事になる。


  2Tバイトも認識できれば、理論的には市販の今のハードディスクの
全ての範囲は認識できると思う。


  このまま深く踏み込んでいくと、どんどん泥沼にハマりそうなので、
マスターブートレコードの仕組みについては、ここで終えたいと思います。

設定ファイルは grub.conf なのか?

  ところで、ここまで読まれた方でGRUBの設定ファイルは
「grub.confじゃないぞ」と言われる方がおられると思います。

  最初に答えを明かします。
  設定ファイルは「menu.lst」です。

GRUBの設定ファイル

[root@localhost grub]# ls -l
合計 223
-rw-r--r-- 1 root root     63  7月 16 17:15 device.map
-rw-r--r-- 1 root root   7616  7月 16 17:15 e2fs_stage1_5
-rw-r--r-- 1 root root   7456  7月 16 17:15 fat_stage1_5
-rw-r--r-- 1 root root   6720  7月 16 17:15 ffs_stage1_5
-rw------- 1 root root    570  7月 16 17:15 grub.conf
-rw-r--r-- 1 root root   6720  7月 16 17:15 iso9660_stage1_5
-rw-r--r-- 1 root root   8192  7月 16 17:15 jfs_stage1_5
lrwxrwxrwx 1 root root     11  7月 16 17:15 menu.lst -> ./grub.conf
-rw-r--r-- 1 root root   6880  7月 16 17:15 minix_stage1_5
-rw-r--r-- 1 root root   9248  7月 16 17:15 reiserfs_stage1_5
-rw-r--r-- 1 root root   5427 11月 23  2007 splash.xpm.gz
-rw-r--r-- 1 root root    512  7月 16 17:15 stage1
-rw-r--r-- 1 root root 104924  7月 16 17:15 stage2
-rw-r--r-- 1 root root   7040  7月 16 17:15 ufs2_stage1_5
-rw-r--r-- 1 root root   6272  7月 16 17:15 vstafs_stage1_5
-rw-r--r-- 1 root root   8864  7月 16 17:15 xfs_stage1_5
[root@localhost grub]#

2つのファイルは、シンボリックリンクで結ばれているのがわかる。

だが、最初は「menu.lst」の存在に気づかなかった。
なので、設定ファイルはgrub.confだと思い込んでいた。


  CentOS4.4、5.1の場合、grub.confを設定ファイルと謳っている。
  なぜ、変則的な事をするのかは、わからない。


  ところでGRUBの設定ファイルがgrub.confではなく、menu.lstである事は、
最初から知っていたわけではなかった。

  そこで、GRUBの設定ファイルが menu.lstである事を知った経緯を
書く事にしました。


  GRUBの設定が一通り理解した所で、次の事を考えた。

  ソースコンパイルでインストールしてみよう！

  実験に使ったのは、CentOS5.1が入ったLinuxマシンだ。
  まずは、バージョンを見てみる。

CentOS5.1に入っているGRUBのバージョン

[root@server]# rpm -iq grub
Name        : grub                         Relocations: (not relocatable)
Version     : 0.97                              Vendor: CentOS
Release     : 13                            Build Date: 2007年01月09日 07時10分41秒
Install Date: 2008年07月15日 21時03分28秒  
    Build Host: builder6.centos.org
Group       : System Environment/Base       Source RPM: grub-0.97-13.src.rpm
Size        : 1056599                          License: GPL
Signature   : DSA/SHA1, 2007年04月04日 09時22分40秒, Key ID a8a447dce8562897
URL         : http://www.gnu.org/software/grub/
Summary     : GRUB (Grand Unified Boot Loader)
Description :
GRUB (Grand Unified Boot Loader) is an experimental boot loader
capable of booting into most free operating systems - Linux, FreeBSD,
NetBSD, GNU Mach, and others as well as most commercial operating
systems.
[root@server]#


  CentOSなのでRPM型式でインストールされている。
  なので以下のようにインストールされているGRUBの削除を行う。

GRUBの削除を行う


[root@server]# rpm -e  grub

これで削除ができたと同時に、新たにGRUBをインストールせずに
Linuxをシャットダウンしてしまうと、起動できなくなる。

もちろん、実験マシンで行ったのだが、稼働中のサーバーで
GRUBの削除を行うのは自殺行為なのだ


  これで退路は絶ったのだ (^^)

  いくら実験サーバーとはいえ、失敗すると、再度、実験する場合には
OSのインストールから行う必要があるので、面倒なのだ。
  なので、一発で決める必要がある。慎重になる。


  最後に、GRUB関係の残骸ファイルを移動させておく。

GRUB関係の残骸ファイルを移動
[root@server]# pwd /boot [root@server]# mv -f grub grub-org
/boot/grubディレクトリーを移動させる。これで残骸ファイルを移動させた事になる。


  これで新しくGRUBをインストールする準備ができた。


  まずは、ライブラリ依存や機種依存を調べて、それに合わせた
Makefileを作成するため、 congifure コマンドが必要だ。

  configureコマンドのオプションを見てみた。

configureコマンドのオプション

[root@server]# ./configure -help
`configure' configures GRUB 0.97 to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

(途中、省略)

Optional Features:
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --enable-maintainer-mode  enable make rules and dependencies not useful
                          (and sometimes confusing) to the casual installer
  --disable-dependency-tracking  speeds up one-time build
  --enable-dependency-tracking   do not reject slow dependency extractors
  --disable-ext2fs        disable ext2fs support in Stage 2
  --disable-fat           disable FAT support in Stage 2
  --disable-ffs           disable FFS support in Stage 2
  --disable-ufs2          disable UFS2 support in Stage 2
  --disable-minix         disable Minix fs support in Stage 2
  --disable-reiserfs      disable ReiserFS support in Stage 2
  --disable-vstafs        disable VSTa FS support in Stage 2
  --disable-jfs           disable IBM JFS support in Stage 2
  --disable-xfs           disable SGI XFS support in Stage 2
  --disable-iso9660       disable ISO9660 support in Stage 2
  --disable-gunzip        disable decompression in Stage 2
  --disable-md5-password  disable MD5 password support in Stage 2
  --disable-packet-retransmission
                          turn off packet retransmission
  --enable-pci-direct     access PCI directly instead of using BIOS
  --enable-3c509          enable 3Com509 driver
  --enable-3c529          enable 3Com529 driver
  --enable-3c595          enable 3Com595 driver
  --enable-3c90x          enable 3Com90x driver
  --enable-cs89x0         enable CS89x0 driver
  --enable-davicom        enable Davicom driver
  --enable-depca          enable DEPCA and EtherWORKS driver
  --enable-eepro          enable Etherexpress Pro/10 driver
  --enable-eepro100       enable Etherexpress Pro/100 driver

(この後は全て省略)

オプションを見ていると、不要なファイルシステムを外す事ができる。
このファイルシステムは、stage2のプログラムがハードディスクの中身を
認識する際のファイルシステムだが、不要だと思う物を省く事ができるのだ。

あと、LANカードのドライバを追加するオプションがある。
これはネットワーク経由でカーネルイメージを読み込む際、
ネットワークカードを認識させる必要があるため、
ドライバの追加のオプションがあるのだ。


  ネットワーク上からカーネルイメージを取り込んで起動させる事ができる。
  configureのオプションを見て、初めて知ったのだ (^^)


  不要な物を外すのは面倒だし、特に追加するドライバはないため、
オプションをつけないで、configureを実行させる。

configureを実行させる

[root@server]# ./configure
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking for gcc... (cached) gcc
checking for C compiler default output file name... a.out

(この後は全て省略)


  そして、makeコマンドを使う。

makeコマンドを使う

[root@server]# make
make  all-recursive
make[1]: Entering directory `/usr/local/src/grub-0.97'
Making all in netboot
make[2]: Entering directory `/usr/local/src/grub-0.97/netboot'
make[2]: `all' に対して行うべき事はありません。
make[2]: Leaving directory `/usr/local/src/grub-0.97/netboot'
Making all in stage2
make[2]: Entering directory `/usr/local/src/grub-0.97/stage2'

(この後は全て省略)



  そして、インストールを行う。

インストール

[root@server]# make install
Making install in netboot
make[1]: Entering directory `/usr/local/src/grub-0.97/netboot'
make[2]: Entering directory `/usr/local/src/grub-0.97/netboot'

(この後は全て省略)


  その後、どうすれば良いのか、わからなかった。
  でも、ネットで調べると次の事を行うのがわかった。

最後の作業

[root@server]# grub-install /dev/hda
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.

(fd0)   /dev/fd0
(hd0)   /dev/hda
[root@server]#

grub-installコマンドは、GRUBをインストールするコマンドだ。
青いのは、GRUBをインストールするハードディスクのデバイスを指定。
ここでは/dev/hdaを指定。
指定したハードディスクの先頭セクタに、stage1が格納される。

そしてGRUB関係の実行ファイル等が /boot/grubディレクトリに格納される。


  これで設定作業は終わった。

  次に、/boot/grub/grub.confファイルを設定した。
  そして再起動をかけた。

  すると、再起動はした物の、以下の所で起動作業が止まった。

Linuxの起動の前に出てきた画面


    GNU GRUB  version 0.97  (636K lower / 2087872K 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>


  これを見た瞬間・・・

  なんで、こんな画面が出るんや！

  と思った。

  とりあえずhelpコマンドを使えば、何か掴めるだろうと思い、
helpコマンドを使ってみた。

helpコマンドを使ってみた

grub> help
blocklist FILE                         boot
cat FILE                               chainloader [--force] FILE
color NORMAL [HIGHLIGHT]               configfile FILE
device DRIVE DEVICE                    displayapm
displaymem                             find FILENAME
geometry DRIVE [CYLINDER HEAD SECTOR [ halt [--no-apm]
help [--all] [PATTERN ...]             hide PARTITION
initrd FILE [ARG ...]                  kernel [--no-mem-option] [--type=TYPE]
makeactive                             map TO_DRIVE FROM_DRIVE
md5crypt                               module FILE [ARG ...]
modulenounzip FILE [ARG ...]           pager [FLAG]
partnew PART TYPE START LEN            parttype PART TYPE
quit                                   reboot
root [DEVICE [HDBIAS]]                 rootnoverify [DEVICE [HDBIAS]]
serial [--unit=UNIT] [--port=PORT] [-- setkey [TO_KEY FROM_KEY]
setup [--prefix=DIR] [--stage2=STAGE2_ terminal [--dumb] [--no-echo] [--no-ed
terminfo [--name=NAME --cursor-address testvbe MODE
unhide PARTITION                       uppermem KBYTES
vbeprobe [MODE]

grub>


  ここで勘を働かせた。
  もしかして、configfileコマンドを使って、grub.confファイルを
読み込ませると起動できるかも。

  早速、実行してみた。

configfileコマンドを使ってみる
grub> configfile hd(0,0)/grub/grub.conf


  するとGRUBの処理が進み、Linuxが立ち上がった。

  一体、どういう現象なのだろうか。

  調べてみると、ここでようやくGRUBの設定ファイルが、grub.confではなく
menu.lstだという事を知る。

  なので、/boot/grub ディレクトリにmenu.lstファイルを
置いてみる。そして再起動を行うと

  問題なくLinuxが起動した！

  だった。

  ここで疑問が出た。
  なんで初期状態では、設定ファイルがmenu.lstファイルなのに、
CentOSではgrub.confファイルなのか。

  GRUBが読み込むファイルを、menu.lstファイルからgrub.confファイルに
変更する方法はないのか。

  早速、googleで検索して探してみる事にしたのだが・・・

  あらへんやん！

  だった。

  ここで思った。
  ディストリビューターがRPMファイルにする際、ソースを変更しているのかも。
  なので、grub-0.97のソースコードを眺めてみる。

  すると、menu.lstファイルを読み込む部分を発見した。

stage2/builtins.c の3976行目

  /* The prefix was determined.  */
  grub_sprintf (stage2, "%s%s", prefix, "/stage2");
  grub_sprintf (config_filename, "%s%s", prefix, "/menu.lst");
  *real_config_filename = 0;

赤い部分が該当の3976行目の部分だ。
ここで読み込むファイル名を指定している。


  なので以下のように書き換える。

stage2/builtins.c の3976行目を書き換える

  /* The prefix was determined.  */
  grub_sprintf (stage2, "%s%s", prefix, "/stage2");
  grub_sprintf (config_filename, "%s%s", prefix, "/grub.conf");
  *real_config_filename = 0;

青い部分が書き換えた3976行目の部分だ。
これでGRUBの設定ファイルを grub.confとして読み込んでくれる


  ソースを書き換えた(と言っても、たった1行なのだが)ので、
再度、コンパイルを行い、インストールしなおした。
  そして、再起動をさせた結果・・・

  grub.confを設定ファイルとして認識してくれた！！

  だった。
  見事、成功だった  (^^)V  

  でも、ここで思った。
  ディストリビューターが、わざわざ設定ファイルの名前のために
1行だけソースを書き換えるのだろうか。

  そして、何気なく他のCentOSのマシン /boot/grub ディレクトリを見てみると、
今まで気づいていなかった事に気づいた。

/boot/grub ディレクトリを見てみると

[root@localhost grub]# ls -l
合計 223
-rw-r--r-- 1 root root     63  7月 16 17:15 device.map
-rw-r--r-- 1 root root   7616  7月 16 17:15 e2fs_stage1_5
-rw-r--r-- 1 root root   7456  7月 16 17:15 fat_stage1_5
-rw-r--r-- 1 root root   6720  7月 16 17:15 ffs_stage1_5
-rw------- 1 root root    570  7月 16 17:15 grub.conf
-rw-r--r-- 1 root root   6720  7月 16 17:15 iso9660_stage1_5
-rw-r--r-- 1 root root   8192  7月 16 17:15 jfs_stage1_5
lrwxrwxrwx 1 root root     11  7月 16 17:15 menu.lst -> ./grub.conf
-rw-r--r-- 1 root root   6880  7月 16 17:15 minix_stage1_5
-rw-r--r-- 1 root root   9248  7月 16 17:15 reiserfs_stage1_5
-rw-r--r-- 1 root root   5427 11月 23  2007 splash.xpm.gz
-rw-r--r-- 1 root root    512  7月 16 17:15 stage1
-rw-r--r-- 1 root root 104924  7月 16 17:15 stage2
-rw-r--r-- 1 root root   7040  7月 16 17:15 ufs2_stage1_5
-rw-r--r-- 1 root root   6272  7月 16 17:15 vstafs_stage1_5
-rw-r--r-- 1 root root   8864  7月 16 17:15 xfs_stage1_5
[root@localhost grub]#

2つのファイルは、シンボリックリンクで結ばれているのだが、
最初は「menu.lst」の存在に気づかなかった。
なので、設定ファイルはgrub.confだと思い込んでいた。


  つまり、ディストリビューターはソースを書き換えたわけではなく、
単にシンボリックリンクを使って、grub.confを設定ファイルに
見せていたのだった。

  これを知った時、思わず力が抜けた。
  なにせ、GRUBコマンドで設定ファイル名を変更できるものだと考え
何時間も調べたからだ (--;;

簡単なGRUBコマンドの紹介

  GRUBコマンドの話が少し出ましたので、ここで私が知っている範囲で
GRUBコマンドの紹介をしたいと思います。

  GRUBの設定や状態等を見るのに、GRUBコマンドがある。
  このコマンドは次の2つの場面で使う事ができる。

GRUBコマンドを使う場面

その1

カーネルイメージを読み込む前

GRUBのメニュー画面の際、「c」を押せば、
GRUBで使うコマンドを入力する画面が出てくる。

その2

カーネルイメージを読み込み、Linuxが起動した後

ログインした後で、grubと打つと
GRUBで使うコマンドを入力する画面が出てくる。


  さて、まずはカーネルイメージを読み込む前の段階の話から。


  GRUBのメニュー画面になった時だ。

GRUBのメニュー画面
背景画像有り

背景画像無し

GRUBのメニュー画面になった時に「C」キーを押す。 GRUB上でコマンドを打てる画面が出てくる。


  「C」キーを押すと以下の画面が出てくる。

Linuxの起動の前に出てきた画面


    GNU GRUB  version 0.97  (636K lower / 2087872K 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>


  上の画面が出てきたら、コマンドが入力できる状態だ。
  コマンドの種類を見たい場合は、helpコマンドが使える。

helpコマンドを使う

grub> help
blocklist FILE                         boot
cat FILE                               chainloader [--force] FILE
color NORMAL [HIGHLIGHT]               configfile FILE
device DRIVE DEVICE                    displayapm
displaymem                             find FILENAME
geometry DRIVE [CYLINDER HEAD SECTOR [ halt [--no-apm]
help [--all] [PATTERN ...]             hide PARTITION
initrd FILE [ARG ...]                  kernel [--no-mem-option] [--type=TYPE]
makeactive                             map TO_DRIVE FROM_DRIVE
md5crypt                               module FILE [ARG ...]
modulenounzip FILE [ARG ...]           pager [FLAG]
partnew PART TYPE START LEN            parttype PART TYPE
quit                                   reboot
root [DEVICE [HDBIAS]]                 rootnoverify [DEVICE [HDBIAS]]
serial [--unit=UNIT] [--port=PORT] [-- setkey [TO_KEY FROM_KEY]
setup [--prefix=DIR] [--stage2=STAGE2_ terminal [--dumb] [--no-echo] [--no-ed
terminfo [--name=NAME --cursor-address testvbe MODE
unhide PARTITION                       uppermem KBYTES
vbeprobe [MODE]

grub>


  個々のコマンドの詳細を見るには、helpコマンドが使える。

コマンドの詳細を知るには
grub> help displaymem displaymem: displaymem Display what GRUB thinks the system address space map of the machine is, including all regions of physical RAM installed. grub>


  うーん、英語なので読む気は起こらない。

  ただ言えるのは、GRUBコマンドは、GRUBの設定や状態を見るために使う
コマンドなのだ。
  もちろん、設定ファイルのgrub.conf(厳密には menu.lst)で記述しているのも
GRUBコマンドになる。

  そのためGRUBコマンドの待ち受け画面から、grub.confに記述されているのを
そのまま入力して、カーネルイメージを読み込み、起動させる事も可能だ。

手入力でGRUBコマンドの待ち受け画面から
カーネルを起動させる事ができる

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

grub> kernel /vmlinuz-2.6.18-53.el5 ro root=LABEL=/
   [Linux-bzImage, setup=0x1e00, size=0x1b3634]

grub> initrd /initrd-2.6.18-53.el5.img
   [Linux-initrd @ 0x1fda9000, 0x246c04 bytes]

grub> boot

最後にブートの命令である「boot」コマンドを使うと
カーネルを読み込み、Linuxが起動してくれる。


  ハードディスクの中に保管されているテキストファイルの
閲覧も可能だ。

テキストファイルの閲覧

grub> cat /grub/grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/sda2
#          initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=50
splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title CentOS (2.6.18-53.el5)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.el5 ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.18-53.el5.img

grub>

catコマンドを使って、ファイル名(絶対パス)を指定すると
該当のファイルの中身を閲覧する事ができる。


  ここまで読まれた方で、次のように思われた方がおられると思います。

  簡単なコマンドの紹介ばかりやん!

  そうなのです。
  難しいコマンドは、私には理解できないため、簡単なコマンドしか
紹介できないのです (^^)   ←  あっさり認める私。

  ハードウェアの知識が必要なので・・・

  事務員の私にはわかりませーん (^^)V

  うーん、常套手段で逃げてばかりの私なのだが、そこまで知識があれば
今頃、立派な技術者として転職しています♪


  さて、GRUBコマンドが使えるのは、GRUBメニューの場合だけでなく、
Linuxが起動した時も、GRUBコマンドが使える場合があります。

grubを打つと


    GNU GRUB  version 0.95  (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>

Linux起動後でもGRUBコマンドが使えるため、
パスワードの設定で、MD5の暗号化パスワードの生成に使える。


  MD5の暗号化パスワードの生成は、パスワードの設定の所で紹介しましたので、
他の使い方を説明します。

geometryコマンド

grub> geometry (hd0,0)
drive 0x80: C/H/S = 38792/16/63, The number of sectors = 39102336, /dev/hda
   Partition num: 0,  Filesystem type is ext2fs, partition type 0x83
   Partition num: 1,  Filesystem type is ext2fs, partition type 0x83
   Partition num: 2,  Filesystem type unknown, partition type 0x82

grub>

ドライブの情報を見るためのコマンド。
デバイス名を指定すると、該当のデバイスの情報が出てきます。

上の出力結果は、CHS方式で表記できる値、セクタ数
各パーティションごとのファイルシステムと、OS等の内容。


  次にファイルの保存されているセクタの表示を行うコマンド。

blocklistコマンド

grub> blocklist (hd0,0)/grub/stage1
(hd0,0)77826+1

grub>

指定したファイルが、ハードディスクの保管されている位置を
表示するためのコマンド。

マニュアルではファイルシステムが不明の時に
有効だというのだが、どんな時に使うのか全く見当がつかない。


  他にもGRUBコマンドがあります。以下のURLがあります。
  http://jo1upk.blogdns.net/linux/?%E3%82%BD%E3%83%95%E3%83%88%2FGRUB%2F%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89

シリアルコンソールからのブート

  パソコンのようにモニターがついている場合は問題ないのだが、
ラック用のサーバーの場合、モニターがついていない場合がある。

  そんな場合、近くにあるパソコンや、ノートパソコンのモニターから
RS232Cケーブルで経由で、サーバーのブート画面を操作する事ができるのだ。

  以下のURLを参考にやってみた。
  http://www.shoshin.co.jp/c/lsi/scs/faqlinux.html

RS232CケーブルでLinuxサーバーを起動

モニターが付属していないサーバーの場合、ブート画面を見る事ができない。
だが、RS232Cケーブルを使い、Windowsのハイパーターミナルで
ブートの画面が見れ、操作する事が可能なのだ。


  Windows側は、ハイパーターミナルの設定を行えば良い。

ハイパーターミナルの設定

通信速度は、115200bpsが最高速度です。これ以上、速度を上げてもエラーが出ます。


  詳しい事は「システム奮闘記:その41」をご覧ください。
  シリアルコンソールでログイン(RS232Cケーブルの活用法)

  次にサーバー側の設定を行う。
  2つの設定ファイルの変更が必要だ。

  1つ目はgrub.conf(厳密には menu.lst)ファイルだ。

grub.conf(厳密には menu.lst)ファイルの設定

default=0
timeout=50
#hiddenmenu
serial --unit=0 speed=11520 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

title CentOS (2.6.18-53.el5)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-53.el5 ro root=LABEL=/ console=ttyS0,115200
        initrd /initrd-2.6.18-53.el5.img

赤い部分はシリアルポートを使った時の通信速度などの設定
青い部分は、GRUBが起動した時に、10秒以上経つと、
シリアルコンソールでGRUBの画面が出るようにする設定

そしてピンクのカーネルオプションは、カーネル起動時での
シリアルコンソールを使った時の端末と速度を指定している。
これによりブート中の処理画面も見れる。


  ただ、これだけだとログインメニューが出てこないので
/etc/inittabファイルの設定も必要だ。

/etc/inittabファイルの設定

id:5:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.  
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"

#serial
co:2345:respawn:/sbin/agetty -h 115200 ttyS0 vt100

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon

青い部分が追加した箇所だ。
これを記述すれば、RS232Cケーブル経由で、ハイパーターミナルから
Linuxへログイン可能になる。


  準備が整ったので、早速、再起動をしてみる。
  するとWindows側のハイパーターミナルで、以下の画面が出てきた。

GRUBメニュー


  そして、起動させたいOS(1つしかないけど)を選択する。
  すると、Linuxが起動処理の画面が出てくる。

Linuxが起動処理の画面


  そして、ログイン画面に辿り着く。

ログイン画面


  うーん、こんな事ができるのかと感心してしまった (^^)

おまけ

  CentOSに手を出して、今回、GRUBを勉強した。
  では、LILOはどうなるのか。LILOがGRUBに取って変わられたら。
LILOの存在は危機的状況なのか!

  もし、LILOが消滅したら・・・

  大阪のLILOはどないするねん!

  でも、大丈夫。大阪のLILOは健在です。
  大阪のLILOは「Linux Install Learning Osaka」という
Linuxのユーザグループで、私もお世話になっている団体だ。

  LILOのURL:http://lilo.linux.or.jp

  ところで、あるLILOの関係者に「LILOを使っていますか」と尋ねた所、
返ってきた言葉が・・・

  このパソコンはGRUBを使っています!

  だった。

  LILOの人もLILOではなくGRUBを使う。
  それだけGRUBが便利な証拠なのかも (^^) 

まとめ

  GRUBの場合、設定ファイルの変更をした後、何もせずに変更内容が
反映されるので、LILOよりも使い勝手は良い点があります。

  でも、一歩踏み込んでみますと、OSの起動の知識やハードウェアの知識が
要求されるため、奥が深い分野だと思います。
  私は、ハードウェアの知識もないし、アセンブラやC言語が読めないので
とても難解な分野だと思いましたが、知れば、知るほど、面白そうなだけに、
実力をつけた時に、もっと踏み込んでいきたいと思います。

次章：「initrdファイルって何?」を読む
前章：「検索サイトで検索結果を上位に掲載するSEO対策入門」を読む
目次：システム奮闘記に戻る