朝方というより早朝のこと。
pacmanでのSignature（署名）がinvalidになった。
$ sudo pacman-key --init
$ sudo pacman-key --populate archlinux
をしても、治らず、で、他のディスロに行っていた。
いまさっき、戻って
$ sudo nano /etc/pacman.conf
の、全サーバまとめて設定のところで
SigLevel = Required DatabaseOptional TrustedOnly
というふうに緑字を追加した。
これをしたことで治ったかどうかは判らないけど、
正常に戻った（やる前に、TrustedOnlyなしでやっていない）
ちなみに、20131205とか、20131217のx86_64版では、
何も問題は生じていない。
リポジトリサーバが一時的に
不具合を発症していただけじゃないか。
2013年12月31日
禁断の、mbm。uefi+gptのlinux
うーん。mbmのブータブルメディアで
起動できるかな、mbmが使えるかな、と試したら、
（具体的には、mbm起動後のメニューの１を選択）
したら、ubuntuのuefi機能で起動している
hdd自体が起動できなくなっちゃった。
トホホ。
bios画面でも、ふつうのhddと
認識されるようになってしまった。
mbmで1を選んでも、mbrに
影響ない、と思っていたのだが。
ubuntuの重ね再インストールでは、
復帰せず。ubuntuを削除しての
新規的再インストールでなんとか復帰。
lba0（mbr)というエリアを壊した
ことによって、uefi起動のドライブってことを
pc側が認識しなくなったようです。
uefi+gpt上では、mbmを使ってはいけない。
ってことを、身をもって学びました。
uefi+gptになっても、旧mbrのスペースは使う。
ただし、違う使い方で。ってことを
肝に銘じます。
参考サイト：
http://ja.wikipedia.org/wiki/GUID%E3%83%91%E3%83%BC%E3%83%86%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB
↓ ↓ ↓ ↓
その後。
mbr従来方式のhddにつなぎ替えたりした。
そして、戻ってきたら、grubのos洗濯画面は
でるものの、選んでも、うんともすんとも。
なんやねん。
ドタマに来て、ufeiのタスキのない当該hddを
選んだ。当然起動しないでhddの初期状態の表示みたいな
表示が出るだけ。で、またuefiのタスキ付きを
選んだら、ふつうに起動した。
アドバンス設定で基本的に変更するより、
uefiで使う時は、その都度、bios画面に入って
一時的起動でしのいだほうが安全かもしれない。
じぶんみたいに、複数のhddをつなぐことによる
電気代を気にせず、hddをひんぱんにつなぎかえない
ひとなら、問題ないのかも。
uefi+gptでずっと行くと決めた場合は、ノープロブレムと
思われる。当分じぶんは、mbrでやってけばいいかな。
でも実験は、つづけていかないとね。
起動できるかな、mbmが使えるかな、と試したら、
（具体的には、mbm起動後のメニューの１を選択）
したら、ubuntuのuefi機能で起動している
hdd自体が起動できなくなっちゃった。
トホホ。
bios画面でも、ふつうのhddと
認識されるようになってしまった。
mbmで1を選んでも、mbrに
影響ない、と思っていたのだが。
ubuntuの重ね再インストールでは、
復帰せず。ubuntuを削除しての
新規的再インストールでなんとか復帰。
lba0（mbr)というエリアを壊した
ことによって、uefi起動のドライブってことを
pc側が認識しなくなったようです。
uefi+gpt上では、mbmを使ってはいけない。
ってことを、身をもって学びました。
uefi+gptになっても、旧mbrのスペースは使う。
ただし、違う使い方で。ってことを
肝に銘じます。
参考サイト：
http://ja.wikipedia.org/wiki/GUID%E3%83%91%E3%83%BC%E3%83%86%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB
↓ ↓ ↓ ↓
その後。
mbr従来方式のhddにつなぎ替えたりした。
そして、戻ってきたら、grubのos洗濯画面は
でるものの、選んでも、うんともすんとも。
なんやねん。
ドタマに来て、ufeiのタスキのない当該hddを
選んだ。当然起動しないでhddの初期状態の表示みたいな
表示が出るだけ。で、またuefiのタスキ付きを
選んだら、ふつうに起動した。
アドバンス設定で基本的に変更するより、
uefiで使う時は、その都度、bios画面に入って
一時的起動でしのいだほうが安全かもしれない。
じぶんみたいに、複数のhddをつなぐことによる
電気代を気にせず、hddをひんぱんにつなぎかえない
ひとなら、問題ないのかも。
uefi+gptでずっと行くと決めた場合は、ノープロブレムと
思われる。当分じぶんは、mbrでやってけばいいかな。
でも実験は、つづけていかないとね。
2013年12月30日
その先行き。uefi+gpt/linux
とにもかくにも、uefi+gptでlinuxのひとつ
であるubuntuをインストールでき、その起動システムを
活用して、archbangも起動できるようになった。
/etc/grub.d/40_customを使えば、
gptテーブルに対応しているディストロなら、
いくらでも追加できそうなのだが。
ただ、fedoraのように、
インストーラーが、定例として、
mbrにgrubをインストールするような？
ディストロの場合は、どうなるのだろうか。
いまある、EFIブートパーティションの
sda1は、ubuntuにとって不可侵な場所の
はずで、uefi方式でgrub-efiみたいなものを
上書きするようなことはないだろう？？？
EFIブートシステムにする新たなパーティションを
作るとすれば、それもおかしなことになりそうだが？？？
追っかけインストールするものは、
grubをインストールしないで、インストールを終えられれば、
いちばん合理的のように思われる。
手動にはなるが、40_customでやる方法には、
かなり確実性がある。
ってことで、じぶん的には、まだまだ課題がある。
今回の取り組みで確認できたこと：
・容量に関係なく、これまでの低容量のhddにも
uefi＋gptの方式はふつうに適用できる。
・gpt、旧来のパーティションテーブルの間で、
ファイルの移動などに問題は生じない。
包丁とまな板が変わるだけという感じに近いかな。
当たり前といえば、そうかもしれないけど、
習わぬ経を読む式の立場としては、けっこう大事なこと。
↓ ↓ ↓ ↓
fedora20-x86_64をuefi+gptのhddに、
インストールした。うまく行った。
ライブ（インストール）ディスクを、uefiモードで起動し、
インストールしたわけだけど、途中、ブートローダーの
インストールを止める項目があった。ディスク選択の
画面の下の、、、なんて書いてあったか、
クリックすれば、「ブートローダーをインストールしない」が
選べる。インストール終了→reboot、grubブートを司る
ubuntuで起動後、
$ sudo grub-mkconfig -o /boot/efi/EFI/ubuntu/grub.cfg
とするだけで、fedora20が拾われた。そして、
起動できるようになった。40_customの出番はなし。
やっていないから断定はできないが、
fedora20インストール後の
/bootに存在するファイルを見たかぎり、
fedora20は、uefiモードでのgrubインストールに
対応しているようだ。インストーラーで
パーティション設定のとき、/ を決めるだけで、
すんなり前に進めたから、 ubuntuのインストールで
決めたEFIブートシステム（sda1)を上書きするのかもしれない。
インストールディスクをuefiモードで立ち上げたせいか、
grub.cfgは、どこにもなかった。
grub-mkconfigでubuntuの
/boot/efi/EFI/ubuntu/grub.cfgにコピーされた
fedoraの起動に関する文字列が、どこから来るのか、
わからない。efiやEFIの拡張子のファイルは、
実行ファイルっぽく、エディタで開かない。
ubuntuから見ての、/mnt/boot/efi/EFI/fedoraの中
同じく、/mnt/boot/efi/EFI/BOOTの中
同じく、/mnt/boot/grub2の中には、
themeフォルダがあり、そのなかには、 os選択画面の
バック画像の.png、２点あるだけ。ほぼ、空。
であるubuntuをインストールでき、その起動システムを
活用して、archbangも起動できるようになった。
/etc/grub.d/40_customを使えば、
gptテーブルに対応しているディストロなら、
いくらでも追加できそうなのだが。
ただ、fedoraのように、
インストーラーが、定例として、
mbrにgrubをインストールするような？
ディストロの場合は、どうなるのだろうか。
いまある、EFIブートパーティションの
sda1は、ubuntuにとって不可侵な場所の
はずで、uefi方式でgrub-efiみたいなものを
上書きするようなことはないだろう？？？
EFIブートシステムにする新たなパーティションを
作るとすれば、それもおかしなことになりそうだが？？？
追っかけインストールするものは、
grubをインストールしないで、インストールを終えられれば、
いちばん合理的のように思われる。
手動にはなるが、40_customでやる方法には、
かなり確実性がある。
ってことで、じぶん的には、まだまだ課題がある。
今回の取り組みで確認できたこと：
・容量に関係なく、これまでの低容量のhddにも
uefi＋gptの方式はふつうに適用できる。
・gpt、旧来のパーティションテーブルの間で、
ファイルの移動などに問題は生じない。
包丁とまな板が変わるだけという感じに近いかな。
当たり前といえば、そうかもしれないけど、
習わぬ経を読む式の立場としては、けっこう大事なこと。
↓ ↓ ↓ ↓
fedora20-x86_64をuefi+gptのhddに、
インストールした。うまく行った。
ライブ（インストール）ディスクを、uefiモードで起動し、
インストールしたわけだけど、途中、ブートローダーの
インストールを止める項目があった。ディスク選択の
画面の下の、、、なんて書いてあったか、
クリックすれば、「ブートローダーをインストールしない」が
選べる。インストール終了→reboot、grubブートを司る
ubuntuで起動後、
$ sudo grub-mkconfig -o /boot/efi/EFI/ubuntu/grub.cfg
とするだけで、fedora20が拾われた。そして、
起動できるようになった。40_customの出番はなし。
やっていないから断定はできないが、
fedora20インストール後の
/bootに存在するファイルを見たかぎり、
fedora20は、uefiモードでのgrubインストールに
対応しているようだ。インストーラーで
パーティション設定のとき、/ を決めるだけで、
すんなり前に進めたから、 ubuntuのインストールで
決めたEFIブートシステム（sda1)を上書きするのかもしれない。
インストールディスクをuefiモードで立ち上げたせいか、
grub.cfgは、どこにもなかった。
grub-mkconfigでubuntuの
/boot/efi/EFI/ubuntu/grub.cfgにコピーされた
fedoraの起動に関する文字列が、どこから来るのか、
わからない。efiやEFIの拡張子のファイルは、
実行ファイルっぽく、エディタで開かない。
ubuntuから見ての、/mnt/boot/efi/EFI/fedoraの中
同じく、/mnt/boot/efi/EFI/BOOTの中
同じく、/mnt/boot/grub2の中には、
themeフォルダがあり、そのなかには、 os選択画面の
バック画像の.png、２点あるだけ。ほぼ、空。
