2017年1月15日の記事で、firstboot的な機能をautoyastに埋め込む例を紹介しました。しかし、当該記事では、うまくいかない場合があることが分かりました。記事中では

<scripts>
<post-scripts config:type=”list”>
<script>

と言う記載がありましたが、ここが問題でした。

実は、autoyastで、設定後、各種スクリプトを動かすための設定方法は
マニュアルにきちんと書いてあります。<scripts>の次のタグの記述で、どのタイミングでスクリプトを動かすかを決められるのです。そして、<post-scripts>の場合には、再起動後YaSTが各種設定をしている中でスクリプトを動かします。これがどういう問題を引き起こすかというと、スクリプトの中にzypperコマンドでリポジトリを設定しようとするときに、ファイル競合を起こして設定が出来ないという問題が発生してしまうのです。

そこで、<init-scripts>に切り換えて、各種daemon等が起動したあとに、スクリプトを実行するようにします。そうすることで、zypper コマンドが正しく動くようになりました。

google での検索では、当該マニュアルまでうまくたどり着けなかったのですが、/usr/share/doc/packages/autoyast2/ 配下にマニュアルがあり、そこを参照することで原因と対策が分かりました。やはり、マニュアルは読むものですね。

下記の記事に対する更新情報があります。こちらを参照してください。

firstboot 機能はautoyastにも組み込めます。しかし、firstbootの解説の所にはあっさりとしか書いてないので、いろいろやってみましたがうまくいきませんでした。しかし、autoyastの設定の中から代替の方法を見つけました。
以下のようにautoinnst.xml に記述を追加すると、再起動後の初期設定中にスクリプトを動かす事が出来ます。

  <scripts>
<post-scripts config:type=”list”>
<script>
<debug config:type=”boolean”>true</debug>
<feedback config:type=”boolean”>false</feedback>
<feedback_type/>
<filename>demo.sh</filename>
<interpreter>shell</interpreter>
<location><![CDATA[]]></location>
<network_needed config:type=”boolean”>false</network_needed>
<notification>demo</notification>
<param-list config:type=”list”/>
<source><![CDATA[#! /bin/sh
touch /root/testend
sleep 50

]]></source>
</script>
</post-scripts>
</scripts>

この設定は autoinst機能を追加したYaSTでも設定出来ます。やってみましょう。

まずYaSTを起動し、「その他」→「独自のスクリプト」を選択し、編集画面に移ります。

新規作成を選び、スクリプト名(ファイル名)を入力し、スクリプトの実体を、「スクリプトソース」に記入します。これで、autoyastが生成するautoinstファイルにスクリプトが組み込まれます。

さらに、生成されたautoinstスクリプトを適宜編集し、自動実行を行わせるサーバに組み込みます。その後、ネットワーク越しに自動インストールが行われ、再起動後に、先ほど設定したスクリプトが動作します。「demo」というタイトルが表示されています。

実行後、ログインしてみると、ちゃんとファイルが出来ています。

openSUSEには、起動したときに1回だけ特定の処理を動かす firstboot という機能があります。試しにちょっと使ってみました。

• モジュールの追加
  YaST2-firstboot モジュールをインストールします。
• ファイルの作成
  touch /var/lib/YaST2/reconfig_system ファイルを作成します。
• 再起動

すると、再起動後、インストール時に見たような物と同じような画面が表示されます。

一通り先に進んでいって処理を終えると通常のログイン画面になります。その後再起動しても、もうこの画面は出ません。

また、再起動後、表示される手順は /etc/YaST2/firstboot.xml に定義されています。ここでの定義を編集すれば、処理を変更することが可能です。

ほぼ、autoyast がうまくいきました。

うまくいかなかった原因はいくつかありますが、おそらく、openSUSEインストール時に作成するautoinst.xmlがバグってます。たぶん。

通常はインストールするパッケージがずらっと並ぶのですが、なぜか、そのパッケージを*削除*する一覧がくっついているのですね。こんな感じで。

<patterns config:type=”list”>
<pattern>yast2_basis</pattern>
<pattern>x11</pattern>
<pattern>sw_management</pattern>
<pattern>lxde</pattern>
<pattern>fonts</pattern>
<pattern>enhanced_base</pattern>
<pattern>apparmor</pattern>
<pattern>base</pattern>
<pattern>multimedia</pattern>
<pattern>remote_desktop</pattern>
</patterns>
<remove-packages config:type=”list”>
<package>zypp-plugin-python</package>
<package>zisofs-tools</package>
<package>ypbind</package>
<package>yp-tools</package>
<package>yast2-vm</package>
<package>yast2-users</package>
<package>yast2-tune</package>
….

これじゃ、パッケージの依存関係が正しくなるわけがありません。セクションを手動で削ったらほぼうまくいきました。あと、セクションもうまくハンドリング出来ないので、ここも削ります。

ただ、lxde環境だと、更に問題があります。起動時にlxdmが設定されません。xdm になってしまいます。しかし、kde環境を指定してインストールすると、ちゃんとkdm が指定されて、起動するので、lxdmに設定するという部分が抜けちゃっているのだと思います。

autoyastを使って自動インストールをしようとしていますがうまくいきません。普通にインストールするとき、インストールした状況を/root/autoinst.xml というファイルに書き込むように指示出来るのですが、そのファイルを自動インストール時に使ってもインストール途中に、パッケージの依存関係解決に失敗します。

そもそも、インストールパッケージに不要なものが入ってしまいます。たとえばこんな感じで、本来DVDに入っていないパッケージが入ってしまっています。

試しにこれらのファイルを手でautoinst.xml から取り除いても結果は同じでした。途中でこんな感じになります。

bashはインストールされ、存在するパッケージなのですが、なぜか依存関係が破綻していると思われています。理由は謎です。

openSUSE mini sumitでも話ましたが、openSUSEを自動インストールしようとして試行錯誤しています。すべて仮想環境でテストしているのですが、なかなかうまくいきません。

仮想環境は、debian ベースの proxmoxVEを使っています。これが、なかなか便利で、Webベースで仮想マシンを立てたりつぶしたり、VNC経由で仮想マシンとサクッと繋がる、バックアップも取れる、やろうと思えば高可用性構成も取れるなど、便利な機能がてんこ盛りです。VMware ESXi と比べると、機能的に劣るところもありますが、個人ベースで使うには十分すぎるくらいです。

ただ、この仮想環境、ちょっと変わったところがあって、仮想OS用のBIOSに、iPXEが組み込まれているのですね。PXEではなくて。なので、ネットワークブートを行う時は、PXEのノウハウがあまり使えません。とりあえず、今やっていることをメモとして書いておきます。

準備

◆１ dhcpの設定

iPXEを使う時には、dhcpで、インストールサーバの情報を設定する必要があります。dhcpの設定はyastからも出来ますが、今回は直接 /etc/dhcpd.conf を設定しました。こんな感じになります。

default-lease-time 14400;
subnet 192.168.10.0 netmask 255.255.255.0 {
range 192.168.10.101 192.168.10.127;
default-lease-time 14400;
max-lease-time 172800;
}
if exists user-class and option user-class = “iPXE” {
filename  “iPXE/boot.ipxe”;
}
else  {
filename “iPXE/undionly.kpxe”;
}
next-server 192.168.10.41;

この設定により、iPXEが、OSを起動するための初期スクリプト boot.ipxeをダウンロードすることが出来ます。

◆2 tftpの設定

tftpの設定はyast から行います。特に標準のままで問題ありません。なお、tftpはxinetd配下から起動することになります。

◆3 httpdの設定

httpdを設定します。rootディレクトリは、/srv/tftpboot/install/ にします。

◆4 OSイメージの展開

yast の、インストールサーバ設定から、OSイメージを展開します。サブディレクトリは、leap42にしてみます。

◆5 OSイメージの配置

/srv/tftpboot 配下にOSのISOイメージを置きます。

◆6 boot.ipxe の作成

ひな形は、ここにあります。こんな感じになっています。

#!ipxe
menu Please choose an operating system to install
item –gap openSUSE
item isolinux isolinux boot
item efi efi boot
item iso iso boot
item –gap ipxe shell
item shell       Drop to iPXE shell

choose target && goto ${target}

:failed
echo Booting failed, dropping to shell
goto shell

:shell
echo Type ‘exit’ to get the back to the menu
shell
set menu-timeout 0
set submenu-timeout 0
goto start

:isolinux
kernel http://192.168.10.41/install/leap42/CD1/boot/x86_64/loader/isolinux.bin initrd=http://192.168.10.41/install/leap42/CD1/boot/x86_64/loader/initrd install=http://192.168.10.41/install/leap42/CD1/
initrd http://192.168.10.41/install/leap42/CD1/boot/x86_64/loader/initrd
boot || goto failed

:efi
chain   /install/leap42/CD1/EFI/BOOT/bootx64.efi initrd=initrd install=/install/132/CD1
initrd  /install/leap42/CD1/boot/x86_64/loader/initrd
boot || goto failed

:iso
sanboot http://192.168.10.41/leap42.iso
boot || goto failed

やってみました

◆1 isolinux でブートする

展開されたISOイメージ内にはisolinux.bin があります。これを直接指定してみます。結果は

と、あえなく撃沈。

◆2 EFIでブートする

展開されたISOイメージ内にはEFI用のブートコードがあります。これを指定してみます。結果は

と、これも撃沈。

◆3 ISOイメージをブートする

iPXEには、SANからブートする機能があります。この機能を使うと、ISOイメージをそのままブートすることが出来ます。結果は、

と、ISOブートと同じ画面が出ます。ただ、この後そのまま続行しても、インストールデータがネットワークブートしたkernelから直接読めるわけではないので、

と、インストールデータがある場所を要求してきます。ここに、httpで取得出来るURLを入れてあげればそのまま続行出来ます。

とりあえずここまでは出来ています。

昔は、リモートからXを使う場合、手元のマシンにXサーバを入れてつないでいました。LinuxをはじめとするUnix系OSであれば、標準でXが入っているため問題はなかったのですが、Windows OSの場合は、Xサーバソフトを入れないと使えません。Windows用Xサーバソフトは現在も何社から販売されていますが、そこそこな値段がするため(数万以上)おいそれと使うわけにはいきません。そこで、自由に(=無償で)使える、VNCを使って同等の事が出来るようにしてみました。

作業手順については、
https://www.ibm.com/developerworks/jp/opensource/library/os-multiuserloginsvnc/ にほとんどまとまっています。ここに書いてある通りにすれば、間違いなく動きます。

ただ、1つ注意すべき事があります。いくつかあるディスプレイマネージャのうち、LXDEはXDMCPプロトコルに対応していません。ですので、VNCから使おうとしても繋がりません。GDMかKDMに切り換える必要があります。