[fol] Re: boot manager (Re: LILO でWindows95を優先的に立ちあげる方法)

[Taketoshi Sano <kgh12351 _at_ xxxxxxxxxxx>]

佐野＠浜松です。

In <8mic91$no1$1 _at_ s-news2.din.or.jp>,
  on "Sun, 06 Aug 2000 09:47:33 +0900',
   with "Re: boot manager (Re: LILO で  Windows95 を優先的に立ちあげる方法)",
 Nobumasa Takayasu <nobumasa _at_ fhe.freeserve.ne.jp> さん wrote:

> > # そういえば高安さんは御自身では解説を書かれないのですか ?
> > # 以前頂いた質問メールにとりあえずの返事を差し上げたらそれきり
> > # 何の音沙汰も無かったようですが、その後あの疑問は解決されたの
> > # でしょうか。
> 
> 　まだです。以前頂いたメールは中間報告的でしたので、まだご報告
> 頂けると思い、首を長くして待っていたところです。

そうでしたか。最初に頂いたメールに「一緒に考えていきたい」と
あったので「とりあえずの返事」に対して何らかの反応があるはずと
考えていました。

> 　その後自分なりに調べた点、まだ疑問な点など整理して、またご質問
> させて頂きます。

よろしくお願いします。

> 　やはりMBMやGRUBのように、MBRのプログラムコード部分から脱却する
> 他ないと私は思ってます。

最近の大容量は HDD の場合をメインに考えるなら、そういう方向に
進むのが正解なのかもしれませんね。私自身は MBR 中の 446bytes に
こだわりを持っている点が extIPL の特徴だと思っていますし、それは
それでメリットのあるという状況も存在するだろうと思ってますが。

> 　私も聞いてないです。性善説に則ると記述されているので、たぶん
> シグニチャバイトがいい加減でも、ブートプロセスを中断しないとかの
> 簡略化がはかられているとかくらいだとは思いますが。
> 
> 　それよりも、「アクティブ切り替え機能」が省略されているので、
> MSのOSをブートする私としては、致命的なんです。

ああ、なるほど。そういうことでしたか。私の場合は Linux システムの
切り換え (rescue, devel/unstable, main/stable) という用途でしか
使ってないので気にしてませんでしたが、たしかにそういう用途であれば
そういった評価になるのも理解できます。

> 　別に佐野さんが、そんなことを主張していると思って書いた訳では
> ありません。
> 
> 　ただしあのままだと、知らない人が見たら、８GB越えは、extIPLと
> LILO 21-5を組み合わせないと「成功」しないのかと受け取られ兼ねない
> ので、一応補足しただけです。
> 
> 　8GB越えを可能にするブートローダの紹介として、「それだけじゃない」
> と言って補足したのではなく、そのままでは、extIPLもLILOも単独では
> 不可能であるかのような誤解を招きかねないので、そうではないのだよと
> 皆さんに言いたかったというです。勿論誤解しない人もいるでしょうが。

了解。

> 　佐野さんだって、うちかわさんの記事へのフォローは、別に「それだけ
> じゃないだろ」っていう意味で投稿した訳ではないですよね。
> 
> 　私も大意はないです。

どうやら誤解してしまったようですね。すみませんでした。

> 　ホームページで書いてます。時折自分でnewsでも紹介もしてます。
> どちらも非常に好きですが、やはり欠点があるので、一つに絞れない。
> 
> 　でもMBMのマウス対応グラフィックメニューがやはりいいですね。
> マルチブートしないのに、あれだけのために導入する人もいるのでは
> ないかと思うくらいです。
> 
> 　あと、MBMのWindows2000のバグ対策は、私には必須です。

そういうこと (Win2000 のバグ) があるんですね。参考になります。
個人的には「マウス対応グラフィックメニュー」を欲しいとは思いませんが
一般への普及を図るにはそういう機能が必須なのかもしれません。

> > MBM についてはまだ自分で使って確認してないので私は書くことが
> >できません。高安さんが書かれるなら歓迎します。ついでに JF へ
> >投稿してもらえれば、より多くの人に役に立つことでしょう。
> >
> > # hdd-intro を改訂してもらえるなら合わせてお譲りしますが。
> 
> 　JFに参加する具体的方法がわからんもので。もしお手伝いできるなら
> 私は自身は是非させて頂きたいとは思ってます。

 JF への参加については http://www.linux.or.jp/JF/jf-ml.html を
御覧ください。高安さんが参加してくださるなら歓迎します :)

> 　ここでお断りしておきますが、これから書くことは、全く佐野さん
> への反論ではありません。ただひたすら私の意見、所見です。
> 
> 　意見の出発点として佐野さんの文章を引用させてもらう場合もあり
> ますが、反論のための引用ではありませんので、あしからず。

了解。

> 　パーティションに依存する＝MBR446bytesで完結していない、ではない
> と思います。MBMをはじめいくつかのブートローダが使っている手法として
> MBRに続く、同一トラックの未使用のセクターを利用するという方法。
> この領域はパーティションの切りなおしなどに全く影響を受けず、MBRと
> 一蓮托生なので、是非使うべきだと思います。
> 
> 　これならパーティションに依存せずに、MBRから脱却できる。60セクター
> くらい使えるので、かなり思い切ったコード書けます。extIPLにもこの
> 手法を取り入れて頂ければ、機能を省くこともなく、エラー処理の簡略化
> もせずに、LBA対応などの機能拡張ができると思います。
> 
> 　ですからMBRで完結しているというのは、上記手法があるので、むしろ
> extIPLの欠点になり兼ねないと私は思ってます。

たしかに、そういう考え方は理解できます。古いディスクや古いディスク
コントローラ (SCSI など) の場合にはトラックあたりのセクター数がもっと
少ないという構成もありますが、最近だと (名目上の) セクター数として 63 を
選択する構成が大部分でしょうね。

> 　また私は「パーティションに依存」していることもそれほど問題では
> ないと思ってます。市販のブートローダは殆どそうですね。
> 
> 「パーティションに依存」していても、そのファイルシステムに則って
> アクセスしているなら、少なくともデータが破壊されたり、書き換え
> られたりしない限りは、問題が起こらないはずです。
> 
> 　ファイルのちょっとした移動（勿論別のディレクトリとかではだめ）
> やデフラグ、また構成変更のないパーティションの移動にも耐えられる
> はずです。
> 
> 　勿論パーティションに依存しないに越したことはないですが。

 OS/2 のブートマネージャは専用のパーティションを必要としていた
という話をどこかで読んだことがありますし、そういう方向もひとつの
解だろうとは思います。

ただ、LILO の場合には 2nd boot loader や map file が LILO を実行した
 Linux システムの /boot ディレクトリ内に存在している (標準設定の場合)
ということを知らずに、「Linux を削除したら PC が起動しなくなった」と
助けを求める人を過去にけっこう見た覚えがあるので、やはりパーティション
内のファイルにはできるだけ依存しないほうが安心な気もします。

> 　LILOの最大の欠点は、パーティションに依存しているというよりも、
> 構成データの位置情報を、絶対番地固定で内部に持ってしまっている
> ことだと思います。2nd BootloaderやMapFileにext2のファイルシステム
> 経由でアクセスせず、絶対番地のジオメトリアクセスしている。
> 
> 　従ってこれらのファイルが、内容が全く変更されていなくても、
> 少しでも位置が変わったら、たちまちアクセス不能になっちゃう。
> 多くの人が何度かみたであろう「LI」で止まる。
> 
> #　これは一方でLILOの利点でもある。パーティションテーブルも
> #ファイルシステムも何も見ず、ただひたすら自分の内部で持っている
> #絶対番地情報だけを信じてアクセスするので、論理領域であろうが、
> #アクティブであろうかなかろうが、全然お構いなしに起動できる。

カーネルのロードだけなら partition table から該当するパーティションを
削除してしまってもロード可能ですね。

> 　更にGRUBが優れているのは、パーティション依存でありながら、
> 前述の未使用セクターも使っていて、たとえstage2などが破壊されて
> 見えなくなっても、なんとかGRUB shellだけでも動けるように工夫して
> あるところですね。
> 
> 　まあそれでも「stage1」と表示して、固まることはよくありますが、
> LILOに比べれば、遥かに環境の変化に強いですね。

そうですね。

> 　最近気が付いたのですが、GRUBの場合、構成データがすべてFDに
> 収まるので、ここに収納すれば、かなり環境の変化につよいローダに
> なりますね。
> 　LILOも構成データはそんなに大きくないので、この手法が使えますが、
> LILOの場合、起動時に動きを変えることが殆どできないので、少なくとも
> 「LIで止まることはなくなる」程度にしかなりませんね。

MBM でも同様なことが可能なのかもしれません (既に書いたように MBM に
ついては何も知らないのでフォローを待ちます) が、extIPL を FD に
インストールした場合はパーティション情報を HDD から読んで動作するので
ひとつの FD で多くの HDD に対応することも可能です。これは起動時に
動作を変更する余地がほとんど無い LILO では不可能なことですね。

> > -  LBA アクセスについては、LILO の場合同じ IPL で LBA/CHS の
> >両方に対応することができない (インストーラのオプションで指定) が、
> 
> 　LILOはコンパチじゃないんですか。

これはちょっと情報が古かったかも。以前テストされていた lilo 22 dev0 
のコードでは LBA アクセスを指定された場合 CHS ではアクセスできなかった
のですが、21.3 以降のほうでは

    - checks if BIOS supports packet calls (int 0x13, AH=0x42), and uses
      these calls if 'lba32' was specified.  Otherwise, it uses
      the C:H:S addressing scheme of the original IBM-PC BIOS.

と書いてあるので両方使えるようになっているかもしれません。
あとでまた 21 系の最新のコードを調べてみたいと思います。

> 　因みにMBMはコンパチです。

それはいいですね。そのうち MBM についても調べてみたいと思います。

# 最近はなかなかこっちの方面に時間を取れないので、

-- 
     ＃ (わたしのおうちは浜松市、「夜のお菓子」で有名さ。)
    <kgh12351 _at_ nifty.ne.jp> : Taketoshi Sano (佐野　武俊)