そのなかで、蛍光灯な私でも気づくことがあった。
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のインストールはしなかった。
EFI System Partitionはあるにはあるはずだが、
「同じ文言」が出るということは、
ubuntuのものだから、不可侵な領域だったようだ。
それぞれに、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関係のネット上の辞典って、
あれ読んで解る人って、いるのかね。
たぶん、書いている本人も解っていないよ。
読む必要のない人が読んだら判るのだろう。
物事を解らせる、ってことがどういうことなのか、
根本から勉強し直したほうがいい。
