マルチブート総合スレ 2つ目

1 ：10/11/30 〜 最終レス ：12/01/09

なんでも訊いてこいや(ﾟДﾟ)ｺﾞﾙｧ!!(ﾟДﾟ)ｺﾞﾙｧ!!(ﾟДﾟ)ｺﾞﾙｧ!!
前スレ
http://hibari.2ch.net/test/read.cgi/linux/1094022155/
まずはここを読んでから ...
ブートとハードディスクのすべて
http://www37.tok2.com/home/nobusan/boot_hdd.html

2 ：

スレ推奨のマルチブートの方法
・MBRにはMBMを入れ、各PBRをチェーンロード
　こうすることで各OSのブート環境を独立させることが出来るので
　どの順序でも新規インスト、アンインストを行なえる
・GRUBをどうしても使いたいなら、MBR後続等、パーティション外のセクターに
　stage2とmenu.lstを書き込む方法がある
　この方法ではMBMと同じ運用が可能になり、更にファイルシステムを理解できる
　というメリットはそのまま ( >>3 の�Cの形態 )
NTLDRで別領域にインストされているOSをブートしたり
GRUB、LILOをMBRに入れるのは各OSのブート環境の独立性の観点から却下

3 ：

※ GRUBは関連ファイルをジオメトリ指定出来るため、様々なインストール形態があります
　 MBR後続セクタにstage2等書き込む場合は第1パーティションの開始位置に注意！
　 メーカー製PCならばくれぐれも信長に！
　 なお、このスレ推奨は「MBRにはMBMを入れ各PBRをチェーンロードする」です誤解無きよう
/* ＭBR に GRUB を入れる際の各パターン */
×××◯ �@（ MBR: stage1 ）- { 後続セクタ: 無 } - [ パーテ内: stage2 menu.lst ]
×◯×◯ �A（ MBR: stage1 ）- { 後続セクタ: stage1_5 } - [ パーテ内: stage2 menu.lst ]
×◯△◯ �B（ MBR: stage1 ）- { 後続セクタ: stage2 } - [ パーテ内: menu.lst ]
◯◯◯× �C（ MBR: stage1 ）- { 後続セクタ: stage2 menu.lst } - [ パーテ内: 無 ]
││││
│││└ 簡単な設定変更
││└ どこを領域解放／フォーマットしても無問題
│└ パーテ内ファイルのジオメトリ依存無し
└ ローダ関連ファイル無し
# 通常のインストールでは、上2つのどちらかです
/* ＰBR に GRUB を入れる際の各パターン */
誰か書け

4 ：

MBMってGPTで使えるの？

5 ：

grub(legacy)ってPBRにセットアップしたら、stage1_5は使わないんだな
stage2ジオメトリ依存かよ

6 ：

GRUBとGRUB2が区別されてないあたりレベルの低いスレだな

7 ：

>>1のサイトに飛んだらFirefoxアドオンのWOTが真っ赤で怖いんだが

8 ：

たいしたことは書いてないから見なくていい

9 ：

2TB買うか、SSDに順次買えていくか迷い所の昨今ｗ
まあ暫くはGPTは用無し
>>6
正直、grub2は相手にされてないと思われ

10 ：

マルチブートするなら２段階ブート方式に統一しよう
ttp://wikiwiki.jp/disklessfun/?multipleboot
初心者相手に「grubをmbrに入れて苦労して設定しろ」とすすめるやつは
自分の無駄な知識をひけらかしたいだけだろ。

11 ：

２段階ブート方式も無駄な知識だろ
お前も同類だ

12 ：

↑grub厨乙ｗ
grubは「Linuxと」その他のOS切替えツールでしかない
MBMはOS汎用切替えツールで、マルチブートに最適なんだよ

13 ：

環境はすっかりエミュで切替えるのが主流になっちまったな
ゲームとかパフォーマンスが要求されるものだけだなもう
あ、レスキュー環境もあるか

14 ：

ttp://www.powerx.jp/product/catalog/enhancement/xpm11/
ttp://www.powerx.jp/product/catalog/enhancement/xbm11/xbm11_a.php
この手のソフトウェアのスクショまで仮想環境なのは如何なものかｗ

15 ：

ttp://www.linuxmania.jp/linux_multiboot.html
各OSのブート環境を独立させようと思っても
grubだとプライマリをひとつつぶさざるをえないんだよな。
それにこの例だと後日、論理ドライブにOSを追加したら設定ファイルをシコシコ修正しなきゃいけない。
無駄が多く、後々も面倒がついて回る駄目ノウハウの典型。

16 ：

ttp://fedora.forums-free.com/topic-t67.html
一生懸命書かれた力作ではあるんだが。
各OSのブート環境は独立してないし、
後々も面倒がついて回る駄目ノウハウの典型。

17 ：

MBMをMBRに置いても xfs使いはプライマリが余計に一つ潰れるんだがな。

18 ：

そこで >>3 の�Cですよ

19 ：

今どきMBM薦めるとかバッドノウハウ過ぎ
老害かよくわかってない新参インスコ厨だな

20 ：

全部XFS派 (そんなヤツ居るかね?) には福音だな。
>>17
GRUBはカーネルをファイルとしてアクセスしロード出来るので
/dev/sda ( MBR+: GRUB_stage1+stage2+menu.lst )
\_ /dev/sda1: Primary [XFS] 鳥1
\_ /dev/sda2: Primary [XFS] 鳥2
\_ /dev/sda3: Primary [XFS] 鳥3
\_ /dev/sda4: Primary [XFS] 鳥4
みたくシンプルな構成だって可能だよ、ってこと。
もちろんどのパーテ内のカーネルも叩ける。カーネル置いとくだけでいい。
GRUBの動作は全くパーテに依存しないし、セクタ直書きなので専用のパーテも不要。
Linux同士でのマルチブートなら「PBR完全フリー」のこんなのもあり。
「各OSのブート環境の独立」「MBRのローダのパーテ内依存無し」は堅持してる。

21 ：

でも俺はMBM派ｗ

22 ：

>>20
この構成から、たとえば鳥3,4をWinVistaとWin7に差し替えるとしたら
えらくめんどくね？

23 ：

…あくまで説明のための例だから

24 ：

以下、前スレに書いたもの(一部修正済)
grubをmbr入れる必要があるのって、
ttp://wikiwiki.jp/disklessfun/
にあるネットワークブートの場合だけじゃない？
Windowsと併用しなくても、マルチブートで複数ディストリのアップグレードを繰り返したり、
別のディストリにまるごと差し替えようと思ったら、
mbrにはMBMを入れるのが最強。
grubをmbrへ入れる選択はありえない。
Windowsプリインストールのネットブックで
linuxをひとつだけ入れて、win と linux のふたつだけでデュアルブートにするなら
mbrにgrub入れても許す。というかオレはそうしてるw
起動時間(手順)がちょっとだけ短くなるというメリットはある。
ただ、winの入れ直しとかlinuxの差し替えとかやるときはめんどいが。

25 ：

複数bootしてないからわからないのだが、
grubをmbrへ入れて面倒というのは、
設定を書き込む際にLinuxへログインしなくてはならないということ？

26 ：

grubはその本体であるstage2と設定ファイルmenu.lstをパーティション内に置く。
だから、>>24 のようにwin+linuxの2パーテだけ、という切り方の時、grubをmbrに入れると
その設定ファイルはlinuxのファイルシステム内に置くことになるので、当然設定変更時には
そのファイルシステムが読めないといけない。つまりそのセットアップされてるlinuxなり
CDブートさせたlinuxでマウントし変更することになる。
ただliloみたく、設定変えたら再度ローダー自身の入れ直しなんてことにはならない。
だから >>15 で紹介されてる、grubのstage2とmenu.lstを置く専用のパーテを取るやり方で
かつそのパーテをFATあたりにしておけば、winとlinux両方から設定変更が可能になる。
そういう意味で、winとの共存をするなら >>15 で紹介されてる方法のほうが >>16 のほうよりスマート。
もっともそれでも "mbrのローダーがパーティション内の状態に依存" しているのは間違いない。
win+linuxの2パーテだけなら、linuxのパーテのPBRにgrubを入れて、mbrにはmbmが一番賢い。
これなら依存は全く無くなるので、このスレ推奨の方法。
若しくはgrubをパーティション外のセクターに書く、>>2,3 >>20 に書かれている方法。
grubの標準的な入れ方じゃないので、マニア向け。ddで設定ファイル書き込みたい人向け。
XFS主義者もこれ。
メーカー製パソコンでmbrとかあまりイジりたくないよ〜とか言う場合はNTLDRで分岐。そんなとこ。

27 ：

>linuxのパーテのPBRにgrubを入れて、mbrにはmbmが一番賢い。
こうやっても設定変更時にファイルシステムが読めないといけないのは変わりないが。
そもそも"mbrのローダーがパーティション内の状態に依存" するのを避ける必要がない。
どうしてもそれが嫌な人だけMBM使えばいいのであってMBM推奨とかまして一番賢いとかはありえない。

28 ：

それ、
カーネルロードのコンフィグレーションと、マルチブートのコンフィグレーションを混同してるよ

29 ：

mbm.efiの見込みあるか？

30 ：

マルチブートの設定 -> パーテ自体をどう扱うか／何処からブートするかはパーテ外のMBMで！
カーネルロードの設定 -> パーテ内OSのことはPBRにインストしたgrubで！
この切り分けが可能なのが
PBRチェーンロードをMBR（とその後続セクタ）完結型のローダーでやるメリット
>>27
マジでもう少し勉強してくれｗ 頼むわｗｗ

31 ：

>>29
わからん。
おれは当面、というか可能な限りシステムドライブは
2TB以下にしてMBMを使っていくつもりでいる。

32 ：

GRUB一つの設定で済むから普通は分けて考えない
ただ設定箇所を増やしてるだけ。これのどこがメリットなの？

33 ：

>26の文章からは、
> つまりそのセットアップされてるlinuxなりCDブートさせたlinuxでマウントし変更することになる。
と
> ただliloみたく、設定変えたら再度ローダー自身の入れ直しなんてことにはならない。
で、
前者のほうが負担が少ないと読めるが、こういう価値観 (いざとなったらCDブートすりゃいいじゃん) の元では
そりゃ「ただ設定箇所を増やしてるだけ」だわな。

34 ：

その後の部分、↓これに繋がってるだけかと
> だから >>15 で紹介されてる、grubのstage2とmenu.lstを置く専用のパーテを取るやり方で
> かつそのパーテをFATあたりにしておけば、winとlinux両方から設定変更が可能になる。
GRUB: 設定ファイルを書き換えれば次から動作に反映される
LILO: 設定ファイルを書き換えてLILOを実行してやらないと、ただテキスト編集しただけ
この違いがあるから、例えばWindowsからext2読むツールでlilo.conf書き換えても反映されない
LILOの実行が出来ないからな
一方GRUBなら反映される、次回からちゃんと読んで動作を変えてくれる
WindowsからもLinuxからも普通に読めるFATにGRUBのstage2と設定ファイルを置くのはアリ
LILOでは (FATに置けたかどうかは知らんが) 全く意味がない
このくらい把握した上で書き込んで欲しいな…

35 ：

>34
A つまりそのセットアップされてるlinuxなりCDブートさせたlinuxでマウントし変更することになる。
B ただliloみたく、設定変えたら再度ローダー自身の入れ直しなんてことにはならない。
C だから >>15 で紹介されてる、grubのstage2とmenu.lstを置く専用のパーテを取るやり方で...
AはBよりマシだがCにすればもっと素晴しい、という文面っしょ。
>33ではCは問題にしてない。AとBを比較した部分に注目しただけ。

36 ：

A 基本、Linux側に設定ファイルがあるとLinuxから変更することになるよ〜
(空行)
B ただこのGRUBの場合はLILOとは違いローダーを再度入れ直す必要はないよ〜 書き換えるだけ〜
C だからGRUB専用のパーテを両方から書き換えられるFSにしとけば、両方から設定変更出来るんだな〜
>>35
お前、国語あまり良くなかったろｗ ちょとウケた

37 ：

>>33の
>> つまりそのセットアップされてるlinuxなりCDブートさせたlinuxでマウントし変更することになる。
> ...こういう価値観 (いざとなったらCDブートすりゃいいじゃん) の元では
すでにこの時点で読解力なんてレベルじゃねーぞｗ

38 ：

パソコンいじる前に、国語の勉強したほうがよさそうだな
小学校3・4年生くらいのテキストで

39 ：

grub 第 4 形態やってみた
kernel 直指定できる MBM みたいな感じで使えてる
menu.lst の書き換えも、dd でそのセクタを更新するだけで別に面倒臭くないし
>◯◯◯× �C（ MBR: stage1 ）- { 後続セクタ: stage2 menu.lst } - [ パーテ内: 無 ]
>││││
>│││└ 簡単な設定変更
設定変更のとこ×になってるけど、最悪でも△だわ
個人的には普通に menu.lst 弄るのと大差ないので◯でもいいくらい
ちなみに fdisk で先頭パーテを2個目のシリンダからにして
最初のシリンダの2個目のトラックから menu.lst、その続きに stage2 の順で書き込んでる
設定変更はエディット後に
dd if=menu.lst.4096 of=/dev/sda seek=63
ってやるだけ
これ覚えると、update-grub が…とか言ってるヤツがアホにみえますな

40 ：

あとこの方式だと本当にパーテ内はファイル置き場って感じ
kernel 直指定で パーテの PBR とジオメトリは一切気にしなくていい
データ倉庫的運用っていうかネットワークのデータボリュームっていうか
バックアップ取ったり書き戻したりは cp | rsync | tar でやるだけでいけるだろう
当然、MBMのようにチェーンロード主体でも使えるけど
これはこれで完璧なやり方だとおもいました！

41 ：

GRUB2の構成やカスタマイズに詳しい人いる？
仮想マシンで環境分けてるのでマルチブート環境はもう使うのやめたんだけど
聞けるのこのスレくらいしかないんだよね…

42 ：

>>32 が、ぼっちな件
>>41
Grub2は誰も使いたがらんからねぇ

43 ：

俺もシリンダは2からとる派なのでやってみようかな・・・
この主義の人結構居るよね？

44 ：

ブートローダーとカーネルだけはパッケージで済まさないなあ
カーネルはパッケージばらしてだけど、ローダーは野良ビルド
各ディストリごとに色々妙なことするの止めて欲しい…

45 ：

GRUB2に移行してまで3TBとか使わずに
SSD + GRUB-LEGACYって考えてる奴も多く居そうなふいんき

46 ：

Linux入れて初めてマルチブートな環境になって
ローダーのgrubを盲信してるやつ
すごくおおいですねｗ

47 ：

扱いやすいlegacyのほうが好きでずっと使ってたけど２も調べてみたら手間はたいして変わらんね。
今はどっちでもいいので最後に入れた鳥の２そのまま使ってる。

48 ：

俺はシステムの中にgrubの実行ファイルがあるだけでキモチ悪い。
カーネルのローダとしては使うけど、stage2とmenu.lst以外は消してる。
よくを言えばパーテ領域外のやり方なんだろうけど。

49 ：

GRUBレガシーで 背景画像を設定してみたんだけど
選択メニューがでかいから肝心の画像が全然見えん。
まるで中央を残してアタックチャンスに臨んだみたいだ。

50 ：

burgでやれw

51 ：

城砦の中心でアタックチャンスを叫ぶ、んだなｗ

52 ：

アタックチャンスに挑んだものの、間違えてペナルティ喰らって涙目

53 ：

grub第4形態はすごく気に入ってるんだけど
最初のパーティションをシリンダ2から取ってる人以外は試しにくいんだよなあ
もちろんHDDの最後尾の余ってるところを使ってもいいが、どっちにしろ判りにくい
ブートローダー自身がパーティション内にファイルを置くのって
気にならない人はとことん気にしないし

54 ：

/boot/grub 専用にパーティション切るのって、イケてないの？

55 ：

来年普及間違いなしのUEFIはFAT認識できるからジオメトリうんぬんで悩まなくてよくなるぜ。

56 ：

>>54
状況による。
「WindowsとのマルチでLinux側が全てXFS、だがMBRにはメーカー純正のロダしかダメ」
「しぶしぶNTLDR/BOOTMGRで分岐しています」
そんな極めて限定された状況なら専用領域はイケてる。
でもそうじゃないなら…わかるよな？
イケてないんだよ。ダサいんだよ。

57 ：

>>54
専用パーティション確保するなら、fatでgrub4dos使うのが面白くない!?
/dev/sda ( MBR+: MS Bootstrap Loader )
\_ /dev/sda1: Primary [NTFS] Windows
\_ /dev/sda2: Primary [FAT16] grub4dos *アクティブ
\_ /dev/sda3: Primary [EXT4] Linux鳥1
\_ /dev/sda3: Primary [XFS] Linux鳥2
でもやっぱりXFS使わない人には値打ち無いかもだが

58 ：

専用パーテ確保するんだったら、
ttp://wikiwiki.jp/disklessfun/?multipleboot
２．リモート環境にあるPCをマルチブートする手法
これにしておくと後々いいことがあるかもだ

59 ：

>>54 をどこからリモートって判断したんだ？
そして
…スレ違いだろうがあえて言おう。
リモートをマルチブートするなんて、それ運用が悪いだけ。

60 ：

>>57
ついでに俺ならMSのローダー使わない前堤なら
/dev/sda ( MBR+: GRUB_Stage1+2 )
\_ /dev/sda1: Primary [FAT16] Freedos + menu.lstのみ
\_ /dev/sda2: Primary [NTFS] Windows
\_ /dev/sda3: Primary [EXT4] Linux鳥1
こんな感じでシンプルにやるな。
これならFAT16のmenu.lstはどのOSからでも弄れるし、Stage2も置かなくていい。
判り易いシステムが結局強い。

61 ：

>>59
デキが悪く行儀も悪いgrub君が唯一その個性を活かせる方法を紹介しただけ
リモートじゃないのはもちろんわかってるから「後々」と書いた
必要な運用法を選択するのは >>54 自身なんだからあとは本人にまかせておけばいい

62 ：

>>54
どうしても専用パーティションを使いたいのでないなら、
/dev/sda ( MBR: MBM)
\_ /dev/sda1: Primary [NTFS] Windows (普通にインストール)
\_ /dev/sda2: Primary [EXT4] Linux鳥1 (grubをpbrに入れるだけで普通にインストール)
\_ /dev/sda3: Primary 何かお好きなものをどうぞ
こんな感じでシンプルにやるな。
これならmenu.lstをいじるなんてめんどくさいことはする必要はないし、
どのOSの差し替え、アップデートも楽々。
判り易いシステムが結局強い。

63 ：

とは言え、>>62 のシンプルな「MBMによる各PBRチェーンロード」じゃ
XFSには対応できないんだよなぁ…
MBRにインストしたローダーがMBMだからXFS諦めるわ、では本末転倒だし
色々なFS試したい奴だって居る
そこでMBM使うにしろ使わないにしろ、GRUB専用パーテという選択肢はありだろうな
まあ究極的にはパーテ領域外インストの >>20 のやり方なら
「PBRのチェーンロード」に軸足置きつつ、XFSであろうと柔軟にカーネルロード出来る
未知なるFSでも、TFTP経由とかMBR後続セクタにカーネル入れることすら出来る
*Linuxがらみのマルチブートなら* ベストだと思うのは俺だけではあるまい
もちろんMBMはカーネルロードしなくてシンプルだからいいんだけどね
PBRにローダー入れられないおかしなFSなぞ放っとけって対応でいいと思う
>>61
リモートの運用云々はリンク先のサイトの話じゃない？
WOLのブートでマルチはほんとに運用下手糞過ぎ
バッドノウハウすすめんなボケ、みたいな
やらんほうがまし
それでスクリプトで次回起動を切替えて…なんて愚の骨頂
マルチブートのスレでアレだが、環境ごとに専用ホスト用意を考慮すべき事案
そもそも最近なら仮想PCも考えないと駄目だろ

64 ：

ごめんアゲてたわ…
/dev/sda ( MBR+: GRUB_stage1+stage2+menu.lst )
\_ /dev/sda1: Primary [NTFS] Windows (普通にインストール)
\_ /dev/sda2: Primary [Ext3] 鳥1 (PBRにGRUBでもLILOでも)
\_ /dev/sda3: Primary [XFS] 鳥2 (直接FS内のカーネルロード)
Windows、Linux併用するならベストはこんな感じじゃない？
拡張領域使っても余裕で対応できるし
MBMの強力PBRチェーンロードは場合によっては助かるんだが
GRUBを入れるとそれ以外のメリットが多い

65 ：

Grubの専用パーティションってprimaryじゃないとダメなん？

66 ：

パーティションの最終形を美しく構成するにはgrubだろうな
mbm: pbrチェーンロードのみ
grub: チェーンロード + fs理解してファイルアクセスによるロード
　 　 + tftpからロード + 指定したセクタからロード
スッキリ構成にしたいならgrub
dosとかwindowsだけならmbmでもいいんだけど

67 ：

>>65
>>20からコピペしたときに消し忘れたんじゃね?

68 ：

freebsd boot0
+ ntipl
+ ldlinux.sys
+ freebsd boot1

69 ：

いちばんうつくしいのは
MBR: Grub stage1
↓ 指定された後続セクタをロード
後続セクタ: stage2 (同じく後続セクタのmenu.lstを読み込み)
↓ チェーンロード
PBR: Grub stage1
↓ 指定された後続セクタをロード
後続セクタ: stage1_5
↓ 指定されたファイルをロード
FS内ファイル: stage2 (同じくファイルのmenu.lstを読み込み)
↓
FS内ファイル: linux kernel
これだと思うが、reiserFSとかじゃないと不可能なんだよな
FS内のファイルもジオメトリ依存一切無しだし、ext4でも採用されて欲しかった

70 ：

>>68
うちも使ってるけど、FreeBSDのBootMgrは512byteに収まってるのに多機能だよなぁ

71 ：

先頭セクタはMBR領域だけどさ、その後ろの62セクタは
丸々未使用なんだよね？ ここって使っちゃいかんの？

72 ：

MBMもGrub (stage1_5) も使ってると思うよ
RAIDコントローラーのがどうとかメーカー製PCのリストアがどうとか
色々調べるといい
あと、今使ってるPCのMBRの後続62セクタをddで吸い出してみれば？
なんか入ってるかもよ？

73 ：

>>20 の構成に >>22 が言ってる、
> この構成から、たとえば鳥3,4をWinVistaとWin7に差し替えるとしたら
> えらくめんどくね？
って全然そんなこと無くないか？
・Windowsインストール前にMBRのバックアップを取っておいて、インストール終了後に書き戻す
・grubの再セットアップ用にFD/CDを準備しておいて、インストール終了後に再セットアップ
どっちかやるだけじゃないかな。そしてそれはMBMでも同じだろう。
それともWin7/Vistaはそれ以外に配慮が要るってこと意味？ Win2kまでしか持ってないからわかんね。
>>20 のは例だとわかった上で書いてみるが。

74 ：

その実際の手間がちがうんじゃない！？
MBM:　再インストが簡単、タイトル変更もその場でできる
GRUB: パーテ外完結型だと再インストもセクタ気にしないといけない
個人的には凝りに凝った構成で完成後にあまりイジらないならGRUB
手軽で簡単、OS入れたり消したりが頻繁でどんどん構成が変わるならMBM
って使い分けがいいと思ったりｗ

75 ：

そっか、再インストじゃなくMBR部分だけ事前にバックアップとっといて
書き戻せばいいんだね
それからまったりとタイトルを現状に合わせてやればオッケーだな

76 ：

>>72
マジすか。それはそれで嫌な話だね。

77 ：

>>76
だったらこれからfdiskでパテ切りする時、第1パーテをシリンダ2から取ればいい。
最近のHDDだと、
最初のシリンダ
　 最初のトラック
　 　 　最初のセクタ: MBR (512byte)
　 　 　次のセクタからトラック終るまで 62 セクタ (31744byte)
　 次のトラック: 第1パーテはじまる →→→
(次のシリンダ)
これを
最初のシリンダ
　 最初のトラック
　 　 　最初のセクタ: MBR (512byte)
　 　 　次のセクタからトラック終るまで 62 セクタ (31744byte)
　 次のトラックからシリンダ終るまで 254 トラック (8193024byte)
次のシリンダ: 第1パーテはじまる →→→
にすればいい。俺はこの 254 トラックにgrubの
menu.lst (2048byte = 4セクタ) + stage2 (197576byte = 386セクタ)
を書き込んでる。
第1パーテもシリンダ境界で切り始められて、気分もすがすがしいぞｗ

78 ：

>>77
冗談抜きでそうしたい。
第1パーティションにブートローダが入ってるというのが
そもそもいびつで嫌なんだよね。

79 ：

>>78
その立ち位置が中途半端。
stage2がNGなのにvmlinuzやinitramfs.imgはOKなのはなんで？
ntldr,winload.exe,stage2,vmlinuzがrootfs上にある必要性なんて別にないでしょ？？
フロッピーブートのようにカーネルイメージもrootfs外に配置すべきなんでは？

80 ：

GRUBをMBRに入れるか、PBRに入れるかで全然違う話になるよ
「MBRのブートローダー構成ファイル」が特定のパーテに置かれる
「PBRのブートローダー構成ファイル」がその当該パーテに置かれる
オレは前者はキモチ悪くて許せないが、後者は許せる
> stage2がNGなのにvmlinuzやinitramfs.imgはOKなのはなんで？
> ntldr,winload.exe,stage2,vmlinuzがrootfs上にある必要性なんて別にないでしょ？？
ファイルじゃないと、使い勝手や管理が悪くなるからだろ
頭悪くないかい？？？
大体どっちにしろファイルシステムで最初に読まれるファイルは出てくるよ
で、その最初のファイルをカーネルにするかカーネルローダーにするかだが (若しくは/sbin/initにするかだがｗ)
カーネル自体よりカーネルローダにしておいたほうが、カーネルにオプション渡したり
柔軟に簡単に設定が出来るので優れてる
普段使ってるエディタでファイル書き換えるだけだからな
さらに言うと、その最初に読まれるファイル = カーネルローダーがジオメトリ依存より
ジオメトリフリーな方が優れてる
LILOみたくローダー本体とカーネルの両方がジオメトリ依存なのは最低
だから理想的なシーケンスとしてはreiserFSのPBRにstage1_5まで入れる方式だろう
stage1_5でファイルアクセスが可能になってるので、stage2はジオメトリフリー
つーか「ジオメトリ依存のファイル」なんてそもそも鬼っ子だからね

81 ：

しかし所詮ブートの話だからなぁ。
気持ちよくブートするためにパソコン使ってる人なんていないしw

82 ：

↑コイツ何しに来てんの？ｗ
2段階！2段階！書き込んでくる某サイトの管理人の主張はわからんでは無いが…
MBRにMBMインストしても、そもそもLinux Kernelをロードするのは大抵GrubかLiloなので
結局「ジオメトリ依存のファイル」の存在を許さないといけないんだよな。
ReiserFSにしてPBR後続部にstage1_5仕込むなりしない限り。
/bootを別パーテにしても、そのパーテには「ジオメトリ依存のファイル」が存在するわけだし。
根本的解決にならない。
特別扱いせず、boot関連／kernel関連ファイルもパーテ内に置いとくだけにしたいよ。
ちなみにMSのOSでio.sysがジオメトリ依存を脱したのは15年くらい前なんだぜｗ

83 ：

少なくとも俺は、ジオメトリ依存が嫌いだからMBMで二段階ブートにしているわけではないが…
こっちの方が複数OS入れるのが楽。ただそれだけの理由だろ普通

84 ：

弱点を指摘してるだけだよ。
もちろんディス鳥を普通インストールだと、GrubがMBRに入り
stage1_5を使うのでジオメトリ依存ファイルは無いよ、当然。
他にも、XFSメインのシステムだと余計なパーテを確保しなきゃならなかったり
新しいファイルシステムで、カーネルは対応してるがローダーが対応してない状況
なんかじゃTFTPからのカーネルロードが出来ないのは使いにくい。同じく別パーテ頼りになる。
超柔軟なGrubと比べるとどうしても。
PBRのチェーンロードは基本だけど、その機能だけだとXFSからブート不能だったり
基本に忠実なだけでは現実には使いにくいんだよ。MS系OSだけじゃないからね。
ジオメトリ依存共々そこまで固執するモンじゃないよｗ
まあ、MBRに入れたときのGrubに対する圧倒的優位点、「パーテを必要としない」ところ
だって、Grubパーテ外完結型で勝負あった感があるし。
OS差し替えとかでも事前に512byteのバックアップさえ取っておけば
マルチブート環境の再構成なんてラクラクだしね。
「パーテ内状態に依存する」という最大の弱点を解消したGrubは
Linux + ◯ のマルチブートにはベストだと思うわ。
すげぇ普通のマルチブート構成やLinuxインスト厨みたいなのには手軽だろうけど。
でもそれだけなんだよなぁ。

85 ：

MBM、指定したセクタをチェーンロードとかあったら
別のロダと連係できるだろ
エキスパート版限定とかでもいいやん

86 ：

MBRのオートバックアップ機能もつけてほしい。
導入時にMBM本体と同じ、MBRの後ろ62セクターのどこかにバックアップ。
それからMBMが実行されるごとにMBRとそのセクターの内容を照合し違っているならコピー。
照合無しの単純コピーだとCFをHDD代わりに使ってる人とか嫌がるから。
1〜3世代くらいバックアップが残してくれると最高。
あとMBM付属のMBRXを特定のセクターじゃなく、セクターからセクターへの
単純コピーも対応してほしい。
これをDOSブートCDに仕込んで、MBMのMBRバックアップからの自動復旧させたい。
新たなOSインストールが終ったら、これ突っこんでブートするだけで元通り。これ。

87 ：

MBMってGPLになったんだっけ？
それなら自分で弄れるはず

88 ：

ブートローダーってかなり特殊な分野だから、ソース公開されたからといって積極的に改善しようとする人がどれだけいるか疑問

89 ：

>>87 に期待ｗ
俺はGRUB使うよ

90 ：

　　　∩＿＿＿∩　　　　　/ﾞﾐヽ､,,___,,／ﾞヽ
　　　| 丿　　　　　ヽ　　　　i ノ　　 　 　 ｀ヽ'
　　/　　○　　　○ |　　　 /　｀(○)　 (○)´i､　　先生助けてっ！、
　　|　U　　( _●_) 　ミ　 彡,U　ミ(__,▼_)彡ミ　　　去年まで二段階二段階って宣伝貼ってた disklessfun が
　彡､　　　　|∪|　,,/　　　,へ､,　　 |∪|　　/ﾞ　　　　　　　息をしてないの！！
　/　　ヽ　　ヽノ 　ヾ_,,..,,,,_ /　 '　　ヽノ ｀/´ ヽ
　|　　　　　　ヽ 　./ ,' 3　 `ヽｰっ　　/　　　　 |
│　　　ヾ　　　 ヾl　　 ⊃　⌒_つ ソ　　　 　 │
│　　　　＼,,＿＿`'ｰ-⊃⊂'''''"＿＿,,,ノ　　　|

91 ：

　 1. MBMによる各PBRチェーンロード
　 2. その他のMBR+後続セクタ完結型ローダによる各PBRチェーンロード
選外. grub (通常型) によるマルチブート
　 　 　 　 ↓↓↓ シリンダ2から第1領域をとってるなら ...
　 1. grub (パテ外完結型) によるチェーンロード主体のマルチブート
　 2. MBMによる各PBRチェーンロード
　 3. その他のMBR+後続セクタ完結型ローダによる各PBRチェーンロード
選外. grub (通常型) によるマルチブート
俺的には順位はこうなった
でもインストールのハードルは高いよなあw

92 ：

まあ一番笑えるのは、
> 選外. grub (通常型) によるマルチブート
grub厨は全てこれなところで、まさに盲信
しかし、マルチブートでぐぐってみてもその殆どが
"NTLDRの情弱マルチでインストの順番が大事だよ" とか
"grubをMBRに組み込むと1つのディス鳥しか使えません！" とか
もうねw

93 ：

>>86
ttp://www.geocities.co.jp/SiliconValley-Bay/3897/grub/grub-5.html
このパッチで似たようなこと出来ると思う

94 ：

↑ パーティション外: ローダー、マルチブートの設定、各領域の管理／性格付け・・・[セクタ単位の世界]
- - - - 別世界の壁 - - - - - - - - - - - - - - - - - - - -
↓ パーティション内: ファイルシステム、OSが管理・・・・・・・・・・・・・・・・・・・・・・・・・・[ファイル単位の世界]

95 ：

各FSつくる側は責任持って、PBRにはファイルアクセスまでのコードを実装すべき！
でそのPBRをddで吸い上げ ⇒ 書き換え ⇒ PBRに戻す、ことで
最初にロードされるファイルを変えられるみたくしてくれよ頼むわ

96 ：

おいこのスレほとんど>>1の書き込みだろwっ

97 ：

>>94
マルチブートを自負する以上、上側に属するなら、SolarisやFreeBSDのsliceやMSの論理区画も認識できるべきだと思うけど。セクタレベルの話だし。
>>95
最近の流れはその古めかしくあいまいな仕様の方式を捨てる方向でしょ。
あまり固執してるとガラパゴスの珍獣化してしまう。
複数ドライブの識別仕様、起動引数の引き継ぎ方、A20ラインの初期値問題、2TiBの壁問題など、PBRチェイン方式は時代遅れになると思う。
より洗練されたブートプロトコルに移行すべき。

98 ：

>>97
意味不明すぎる。
PC/ATの一般仕様では不充分だったから、BSD系はそのパーテの中で色々やってるワケで。
MBR方式のパーティションテーブルを拡張して欲しい、ってこと？？
"MSの論理区画" は "拡張領域の論理ドライブ" のことなのかな。
とりあえず >>1 の "ブートとハードディスクのすべて" を読んで勉強してからまたおいで
>>95
書き込みとなると大変だが、読むだけでいいんだからね

99 ：

HDDはPCATのためだけに作られたわけでもないけどね
MBRを7C00にロードてのはPCATの方言だし8086依存なIPLがあってもね
Mac、STBの台頭もあってEFIへシフトしてくよ

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・　次のスレ
7: [[[ 2ch ブラウザ JD 11 ]]] (239)
8: 【deb系】Ubuntu Linux 54【ディストリ】 (987)
9: Vine Linux Thread 其の62 (922)
10: Unityって最高だね。全部Unity採用すればいいのに。 (235)