tizen.moe

tizen.moe

OS起動直後にGBS chroot出来ない

f:id:moguriso:20130112171611p:plain

電車内でgbs chrootできない( ゚д゚)!

電車でPCを起動して、コンソール立ち上げ

$ gbs chr -r ~/GBS-ROOT/local/scratch.armv7l.0/

とすると、

info: chroot /home/moguriso/GBS-ROOT/local/scratch.armv7l.0/
chroot: failed to run command `su': 実行形式エラー

と言われて、一度lbで何らかのパッケージをbuildするまでchroot出来なかったりします。
特に電車ではネットワークに繋がっているとは限らないので結構ストレスです。

何が悪いのか

gbsコマンドはpythonで書かれたスクリプトで、フロント部分は /usr/bin/gbs に出されています。実際にはサブコマンドの集まりで、それらは

/usr/lib/python2.7/dist-packages/gitbuildsys

に格納されています。chrootの場合、実体はcmd_chroot.pyにあり、ここで

 40     cmd = ['sudo', 'chroot', build_root, 'su', user]

というコマンドを組み立ててchrootしています。厳密には前2つの"sudo"、"chroot"はx86系のコマンドで、末尾の"su"はarmバイナリ(build_rootのパス配下にいる)を呼び出すことになります。


arm向けのパッケージビルドにはqemuが利用されいてるはずですが、スクリプトだけを追いかけてもどこで呼んでいるのかまでは、引っかかって来ません。

$ grep -rin qemu ./
バイナリファイル ./cmd_build.pyc に一致しました
./cmd_build.py:76:QEMU_CAN_BUILD = ['armv4l', 'armv5el', 'armv5l', 'armv6l', 'armv7l',
./cmd_build.py:232:        if buildarch not in QEMU_CAN_BUILD:

結論からいうと、別に環境をスイッチするためのスクリプト(/usr/bin/depanneur)がいて、こいつが

1070     if ($arch ne "i586" ) {
1071         push @args, "--use-system-qemu";
1072     }

的なオプションを内部で指定してqemu-user-staticを設定し、armバイナリのsuを実行できるようにbinfmtを利用してくれる設定をする(x86環境でarmバイナリを実行できるようにする)ようです。

なのですが、gbs lbでのみ上記を呼び出すため、起動直後にgbs chrootしてもbinfmt設定がなく、armバイナリのsuが呼べない→chroot出来ない、となっていました。

JIRAにあげてみた

「バグじゃね?」と思ったのでJIRAにあげて見ました*1

どうも、gbs chrootはbuildする際に作成されるrootfsの作成を補助するものなので、そのrootfsをガリガリ使いまわしてる私がおかしいらしいです。(usage errorではないと思うとは言われましたけど。。。)*2

デモできないと不便なので

要するにbinfmt設定が常時有効になって、armバイナリが実行できれば起動直後でもchrootできるので、簡単な解決策としてはqemu-user-staticパッケージを入れてしまえば出来ました。いろいろビルドしまくって、FSが13GB位になっているので、今更やめるのもあれですし、今後もgbs chrootで続けます( ゚д゚)!

*1:今見たら、be動詞を2つ書いてる所とかある...orz

*2:実はその前の日辺りに[twitter.com/TNaruto:title=@TNarutoさん]にも似たようなこと言われた...