uefiに関わる妄想-3。linux方面(archbang_EFI-loader_install)

すでにubutuのgrubによって、起動できている
archbang-20131217-x86_64から、grub-installしてみた。

事前に必要なパッケージは、grub, dosfstools, efibootmgrだけど、
すでに入っていた。ubuntu頼りでarchbangを起動して、
※sda1は、EFIブートパーティション。

$ sudo mkdir /boot/efi
$ sudo mount /dev/sda1 /boot/efi
$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=$esp --recheck --debug
$ sudo grub-mkconfig -o /boot/efi/EFI/grub/grub.cfg 　　緑字を追加ないし修正
$ sudo grub-mkconfig -o /boot/grub/gurb.cfg

これで、archbangから起動し、archbangのgrubのos選択画面で、
他のosも起動できるようになった。これをやって少し弊害が出た。
archbangの起動途中で起動が止まることは一切ないが、
swapがアクティブじゃないみたいな表示が出る
起動後、gpartedから見れば、アクティブになっているんだけど。

で、もとに戻そうと、archbangのgrubのos選択画面でubuntuを選択。
ubuntuから同じことをやってみた。で、ubuntuのos選択画面で
archbangを選択して起動させたが、swapがアクティブじゃない
の表示は、出たままだった。こういうの、どうやって治すのか、
わからない。

で、肝心のわかったことは、どのuefi対応のディストロからでも
osの管理は自在にさせられる、
pcのbios画面で、どのディストロに管理させるかを選べる。
sda1のEFIブートパーティションにgrub-installする利点は、そこ。
sda1の容量を超えなければ、いくつインストールしても、
起動上の障害にはならないんじゃないかな。断定はできないが。

archbangから
$ sudo mount /dev/sda1 /boot/efi　しての"現"風景

その1:EFIの中


その2:EFI/ubuntuの中


その3:EFI/grubの中　※ここでいうgrubは、archbangのこと。


archbangからのgrub-installで生成されたのは、
grubのフォルダとその中身のgrubx64.efiだけ。
あとは、ぜーんぶubuntuのgrub-installで
インストールされたもの。

uefiに関わる妄想-2。linux方面

つづき。

ubuntuと最初のインストールの痕跡をすべて削除し、
ubuntu13.10-amd64を空いている先頭のパーティションに
当初の状況になるように、インストールしなおした。

パーティション番号が何かの拍子にずれると厄介だから、
完全にやりなおしたわけです。
削除のツールは、livecdのgparted(uefi起動）を使った。



インストールは、一等最初とほぼ同じに進んでいるように
見えたが、ブートローダーのインストール先に、
sda1がなぜか出ない。一等最初のインストールでは出たんだけど。
で、仕方がないから、sdaをインストール先にした。

で、瓢箪から駒というか、いきなりgrubのos選択画面が出る
ようになりーの、ほかのarchbangやfedoraもインストール中の
update-grubでだろうと思うけど、拾っていて、
os起動できるようになっていた。bios画面をチェックすると、
uefiのたすき掛けが一番に変わっていた。

この状態で、なにか別なuefi対応のlinuxをインストールし、
ブートローダーのインストール先に、sdaを選ぶと何が起こるのだろうか。
管理するディストロが代わるのかな。
sda1が出たとして、sda1にインストールすると、管理ディストロは、
代わらずにそのままで、ってことかな。やってみなければ、わからない。

話が元の木阿弥で、旧mbrには、いったい何があるのか。
いま、/boot/efi/EFI/ubuntu/以下には、一等最初に、
sda1にブートローダーをインストールしたと同じ内容がある。
んーん。わからん。

「WIKIのGUIDパーティションテーブル」には、
下記のような記述がある。

従来の MBR (LBA 0)[編集]
GPTを使用するディスクにもMBRが存在するのは、MBRを前提としたディスクユーティリティを利用した場合の事故の防止のため（誤って何も中身がないと判断されないため）である。MBRにはそのディスク全体がひとつのパーティションになっているという情報が記述されることになっている。

mbrというのは、じぶんの認識では、hddなら、どれでも
存在する、特別の場所という感じだけどね。
そこに収納される情報としては、白か赤かの区別だけ？

uefiに関わる妄想。linux方面

きょう、数あるarchbangの更新を行った。
そのなかで、蛍光灯な私でも気づくことがあった。

gummiboot というパッケージの更新のところで、

File system /boot is not a FAT EFI System Partition (ESP) file system.
エラー: コマンドの実行に失敗しました

という文言が出る。
これをじっと見ていて判るのは、
/bootパーティションが別にないとダメらしい。
しかも、そのファイルシステムは、fat32（指定時はvfat）でないと
ダメらしい。ってことだね。

ubuntu13.10のuefiの支配下、gptテーブルに
インストールしたarchbang-20131217-x86_64でも
/var/log/pacman.logを遡って確認すると、同じ文言が出ていた。
archbang-20131217-x86_64は、/パーティションだけでインストールしている。
grubのインストールはしなかった。archbangから見て
EFI System Partitionはあるにはあるはずだが、
「同じ文言」が出るということは、
ubuntuのものだから、不可侵な領域だったようだ。

uefi+gpt上で、マルチブートするには、原則としては、
それぞれに、fat32のEFI System Partitionが要るという
ことになるのかな。

最初にインストールしたディストロに
管理させ、その他のディストロを、grubで認識させる方法は、
現実にできたし、ほぼありだと思う。
このほうが、パーティションの数を無駄に消費しない気はする。
ただ、きのう、mbmで犯したミス時のように
その肝心要を壊してしまうと、厄介だ。やり方としては
かなりリスキー。uefi+gpt版のmbm的お助けツールがあるといいんだけど。

仮に、すべてのディストロに、fat32のEFI System Partitionを
くっつけてインストールすると、どんな情景が現れるのだろうか。
インストール時のままデフォルトだと、たぶん、grubのos選択画面は素通りで、
bios画面（古い言い方で、今日的には的を射ていない）を
いちいち出して、osを選択することになるのかな。
いま、bios画面を見ると、ubuntuが二つあって、
片側は、os起動しない。なんで二つ現れるのか定かでない。

uefiの起動を構造的に考えると、
旧mbrの場所は、osの起動にやっぱり使うようだ。
すごく単純で、128のシンプルな信号が、
おそらくディストロそれぞれの
EFI System Partition（一番目のパーティション）を
特定し、橋渡しをするという流れのような気がする。

もしも、そうだとするなら、gpt側の制約はどうなのか
ってことが残るが、じぶんがやったgrubで管理させるやり方と
合わせて使えば、無限大みたいな数のパーティションを
扱えるようにも思えるけど、どうなのだろう。
EFI System Partitionは、容量を自在に決められるしね。

勝手な妄想をしてみました。

妄想でしか、ありませなんだ。
EFI System Partitionは、ひとつのみだそうで、
他のディストロも、同じところに向かって、
ブートローダーをインストールするそうだ。
http://kledgeb.blogspot.jp/2013/10/uefi-win8-ubuntu1304-4-ubuntuubuntuuefi.html
でも、osの切り替えをbios画面のboot managerでやるようだから、
とっかえひっかえ切り替える者には、現実的じゃないね。

ちなみにで、いま気づいたこと。
bootできなくなったubuntuについて、
削除＆新規インストールを選んで再インストールした結果は、
じぶんの思惑とはまったく異なった状況を呈していた。



じぶんとしては、削除したところに再インストールされると
思っていたのに。再インストールしたubuntuから見て
当初のsda1の/boot/efiは、非アクティブになって、マウントポイントが
取れており、新たにsda2の/boot/efiが設けられ、残りの全域を/に使って、
インストールされちゃってた。トホホホホホ。

sda1は、削除していいんですかね。
sda6は、liveなgparted辺りから、縮小できるのかな。



追伸：しっかしIT関係のネット上の辞典って、
あれ読んで解る人って、いるのかね。
たぶん、書いている本人も解っていないよ。
読む必要のない人が読んだら判るのだろう。
物事を解らせる、ってことがどういうことなのか、
根本から勉強し直したほうがいい。

新春の更新。manjaro-0.8.4 "Openbox-Lite"

まただいぶ時間があいてしまった。
このバージョンの最新のカーネルは、
3.8.13.14-1-MANJARO
(リリース時期をバージョンとするとして、
バージョンごとにカーネル更新に制限を
設けているようだ。だとするなら、
ちっともローリングリリースではない。
archbangなら、壊れることなど、おかまいなしに
ぜーんぶ、最新まで持って来られる。リリース時の
システムのシャーシ部分は除く）

archbang（己がswapを構築しないと
インストールできないディストロ）の混ざっている、
マルチブートゆえ、manjaroを更新後、/boot/grub/grub.cfgの
swapのuuidを修正しなければならないこと、
＆ カーネル更新の影響で、virtualboxのモジュールの
ロードを止めなおさねばならないのは
相変わらずだけど、システムとしては安定している。

$ sudo nano /etc/modules-load.d/linux38-virtualbox-guest-modules.conf
この中の３項目を下記のようにコメントアウト。
#vboxguest
#vboxsf
#vboxvideo

小さな親切、大きなお世話系のarchは、
きょうもわが道をゆく？
mirrorlistの更新を自動にしていて、時間を食う。
評判にこだわって、前に行けていない感じがする。
カーネルが3.8台だものね。