SVX日記

2004|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|

2015-12-07(Mon) 増殖するEFIブートエントリ、キックされないキックスタート

  kugutsuスクリプトを完成する都合もあって、やたらFedora23とopenstackのインストールを繰り返していたことで、いろいろと気づいた点があったのでまとめておく。やっぱ、OSS関連の仕事をしている以上、たまにはマシンやデバイスを新調し、いろいろと気づきを得ることは重要だな。いくらソフトウェアのサポート要員とはいえ、OSだけ最新のLinuxを使っていたって気づけない点は多々ある。

  とはいえ、ソフトウェアに関しても、角度を変えれば同じこと。何年も前にWindowsから開放されてヒャッハーな気分だったとはいえ、その反面、Windowsの操作に関しては、完全に素人以下になり下がってしまっている気がする。何度使ってみたものの、まったく興味が湧かないAndroidも同じような状況。まぁ特段、生活にも仕事にも支障は出ていないのだからいいのだけれど。

  それはそうと、気づきのひとつとはEFIブート。コンピュータが単細胞生物レベル(?)だった頃のピタゴラ装置的ブート機構をようやく今になって置き換えるものだ。EFIと言えば破廉恥なセキュアブート機構が話題だが、真の狙いのひとつはブート機構をスッキリさせることのはず……だったはずだが、なんだこれは。いつの間にこんなことに。

Fedora
UEFI:CD/DVD Drive
UEFI: Built-in EFI Shell
UEFI:Removable Device
UEFI:Network Device
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1

  OSのインストールを繰り返しているうちに、ブートエントリが増殖してしまっているような……なんだこれ、消したいが、どうやって消しゃええんじゃ?

  調べると、どうもEFIブートでは、ブート関連の設定情報をマザーボード上の不揮発性メモリ上に記録するようになっており、OSが起動した後も、その不揮発性メモリへのアクセスは可能らしい。いわゆる稚拙なBIOS画面でゴチャゴチャと操作しなくてもよくなったということか。具体的にいうと、Linuxでは擬似ファイルシステムとしてアクセスが可能であり、Fedoraでは/sys/firmware/efi/efivars/にmountされている。

  んが、ディレクトリの中身をlsで見てもほぼハナモゲラだ。エントリ数も妙に多い。何をどうすればいいのかよくわからんが、ブートエントリを操作するために、efibootmgrというツールがあるらしい。試してみたところ「efibootmgr」でリスト表示をさせて「efibootmgr -b 0000F -B」のようにしたら重複エントリを消すことができた。

  このefibootmgrがエントリを消す際、具体的には何をしているのか気になったので、straceで処理内容を覗いてみたところ、普通に擬似ファイルシステムに対して、削除や書き換えを行なっているだけだった。ふむん。EFIってそんなモンなのね。

  画像の説明

  んが、消したそばからまた増える……もぉええわ。

  さて、もうひとつの気づきはLinux OSのキックスタートインストール。この機能を使えば、最初に設定内容を渡すだけで、インストール完了までのすべての操作を自動化できるというシロモノ。openstackの環境用には2台のマシンを用意していることもあり、省力化の程度は大きい。

  具体的には、インストールDVD-ROM等からブート、直後に表示されるメニューの「Install Fedora 23」に移動し「e」キーを押下、以下の★部分の後ろにパラメータを追記することにより行う。

setparams 'Install Fedora 23'
linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-23-x86_64 quiet ★
initrdefi /images/pxeboot/initrd.img

  追記内容は以下。

selinux=0 inst.ks=http://server/anaconda-ks.cfg

  ちなみに「selinux=0」は、インストール開始時点からSELinux機能を無効化する指定で、これによりハナから各ファイルに拡張属性が付与されることを完全に防ぐことができる。

  続く「inst.ks=http://server/anaconda-ks.cfg」が、キックスタート機能に渡す設定内容。いったんキックスタートを使わずにインストールした場合に/rootに生成されるanaconda-ks.cfgを再利用する。読み込む場所はいろいろと選べるようだが、今回は手持ちのウェブサーバ上に置いて読み込めるように取り計らったので、冒頭がhttp://となっている。

  追記が完了したところで「Ctrl-x」を押下すれば、完全自動イントールの開始……かと思ったが、なんだかネット上のFedoraリポジトリを見つけられない様子で、そこから先に進まない。特にマズってるところはないはずなのだが……と思ったら、なんと不具合とのこと。

  普通、OSの導入後の不具合ならば修正パッケージで対応されるのだが、この問題は導入後に起きてるんじゃない……導入前に起きてるんだッ!……ということで、一体どうすんのかと思ったら、なるほど、そういう場合のための機構があるのね。キックスタート機能と同様に、修正内容を渡すことができる機構が。つまりこう。

selinux=0 inst.ks=http://server/anaconda-ks.cfg inst.update=http://server/1277638.img

  これで完全自動インストール、いっちょ上がり!