16.04までupgradeしたubuntuの件。uefi+gptでのbootloader

16.04までupgradeした2つのubuntuは、
共にuefi+gptの同じhddに入っている。
アップグレードすると、/boot/efi/EFI以下にある
ubuntuのgrub2（bootloader）を互いに上書きし合う。
/boot/efi/EFI以下に２つのubuntu用bootloaderが
共存するわけじゃない。

だから、あら？って感じでgrubのos選択画面が変化する。
管理ディストロが入れ替わるわけで。

ってことで、hddの管理ディストロを決めているなら、
それを最後にupgradeすれば、元通りになる。

uefishell（v2.0）を使ってのnvramへの書き込みは、
未だに達成出来ていない、というか、トライさえしていない。
以前、かなり粘ったんだけど、どうあがいても
shellが起動しなかった。

根性なしは、元からデフォルトで入っているもので起動する
ことにして、不揮発性を担保している。
つまり、電源＆信号ケーブルを抜いたりしても、
ブートローダーが蒸発してしまわないようにしている。

asus辺りのマザーで、今現在、蒸発しないのは、
linuxではubuntuとopnesuse。
windowsだと、/boot/efi/EFI/Microsoft/Boot/bootmgfw.efiの名前で
蒸発しない。じぶんは、refindをbootmfwにrenameして、
windowsに見せかけてbootをしたりもしている。

最近uefi-gptをあまりしなくなった。

多マルチブートのときは、mbmが一番いい。
uefi+gptにおいて、この方式は、やれない。
なんか、新しいので、いいのがないかな、と思っている。

uefi+gptでのbootに関しては、しばらくカヤの外だった。
知らないうちに新方式の画期的なのが出ていないかな。
仮に3tbの今日的大容量のhddを使うとしたら、uefi-gptに
せざるを得ず、じぶんは1ディストロに30gbしか
割かないから、90ぐらいは入る。
そのとき、hdd上の変化を反映するために
いちいちupdate-grubなんか、やっていられない、
と思うのだ。数が多ければ、時間もかかるしね。

refindは、update-grub的なことは
しなくてすむが、いちいち一からosの所在を読み込むから、
数が多くなると、システムの起動がとても遅くなりそうだ。

低容量の中古のhddを使うわけには、
ボンビーだけでなく、そのへんの悩みもある。