[FreeBSD-users-jp 95935] Re: ELF interpreter /usr/libexec/ld-elf.so.1 not found

2016年 8月 13日 (土) 03:53:11 UTC

青木@名古屋です。

On Fri, 12 Aug 2016 15:42:58 +0900
"kenji at kens.fm" <kenji at kens.fm> wrote:

> > 念の為確認ですが、brandelf -t Linuxした状態のバイナリを実行する際は
> > linux_enable="YES"（かつlinux.koをロード済）で試していますよね？
> 
> はい
> kldload linux.ko　して
> kldstat　で確認してテスト後
> kldunload linux.ko　しました

まずは本当にLinuxバイナリで【ない】ことは確認できましたね。

> svnlite checkout https://svn.FreeBSD.org/base/stable/10 -r r286665 /usr/src
> 
> stable/10　の　r286665～r297262　までを試して
> r293448 まではOK
> r293449 以降がNG
> と言う事がわかりました
> r293448とr293449の間で変更されているのは
> 
> sys/kern/imgact_elf.c
> https://svnweb.freebsd.org/base/stable/10/sys/kern/imgact_elf.c?r1=293318&r2=293449
> だけのようです。

私の頭に引っ掛かっていたのは多分その次のr295366だったと思いますが、
それはさておき、

　・r293499をbackoutするとどうなるか？
　　　※上記で引用頂いたURLの画面上方の「patch」をクリックすると
　　　　パッチが手に入りますので、これをファイルに落とし、
　　　　/usr/srcで
　　　　　　patch -p2 -R -i パッチファイル名
　　　　で当てれば大丈夫です。
　　　　　※パッチ内のパスのうち「stable/10/」の部分を無視させる
　　　　　　必要があるので -p2 が必須です。

　・上記だけで駄目な場合、さらにr295366もbackoutするとどうなるか？

を試してみてはどうでしょうか？　もしこれで動くなら、POLA violationと
してBugzillaにPR登録してfreebsd-stable MLにもその旨報告すると、認め
られれば次のSAのタイミングでENとして対応してもらえるかもしれません。

　※POLA violationをまともに考慮するのはstableブランチからですので、
　　今回のように「従来動いていたものが動かなくなった」というケースは
　　freebsd-currentで報告してもとりあって貰えないかもしれません。

なお、素直にこのファイルだけr293448以前に戻せと言わないのは、さらに次の
r295454がシステムの他の部分の更新と絡んでいるため、迂闊にこのファイル
だけ戻すと何が起こるか不安だからです。

> 10.2-RELEASE-p8　と　stableの 10.2p8  は全く別物ですか？
> revision番号は各ブランチ共通みたいですが

portsは別管理ですが、base（OS本体部分）はご察しのとおり、共通です。
また、stableブランチにはp8やp10のようなパッチレベルは無く、ただただ
リビジョンが進むのみです。

一応説明すると、*.0-RELEASEまでの流れは割と知られていると思いますので
置いておいて、その後の更新に絞ると、

　　・開発はhead(所謂-current)で進む。

　　・headである程度以上の有効性・安全性が確認され、K[P|B]I・A[P|B]I
　　　を壊さないものがstableにマージされる。（MFC 乃至 MFH）

　　・stableブランチで新たな問題が発生しなかった【SA／EN関連】の修正が
　　　relengブランチにマージされる。（MFS）

　　・必要な更新が出揃い、relengブランチでの動作検証をパスしたところで
　　　relengブランチのバージョン情報を更新し、freebsd-update用のバイナリ
　　　をビルド、提供開始（10.2-p18や10.3-p4等）。

という流れになります。　そのため、正式にSAやENが出るより少しでも早く
セキュリティ修正を取り込みたい（リスク覚悟）場合、relengブランチを
追いかけてソースからビルドして更新するのがお薦めです。

　※特殊な環境や一部のアーキティクチャでのみ不具合が発生し、SAの
　　発行が大幅に遅れるケースもありますので。　手間や検証未完の
　　リスクとのトレードオフですが。　さらに早くというならさらに
　　リスクは上がりますがstableブランチの追いかけです。

> > SA-16:25
> これとの関係は判りませんが　SA-16:25 の反映済みと思われる
> 10.3-RELEASE-p7　でも例の古いバイナリは動きませんでした。

上述のとおり、今回発見して頂いた変化点を含む全てのリビジョンが
アウトと考えるのが自然です。　今回は問題のリビジョンでの変更が
1ファイルのみ・1箇所のみ（もう1件も変更箇所は増えるものの1ファイル
のみで個々の変更は小さい）ため、それだけを外してみるのを提案させて
頂きました。

stable/10で今回のトライアルがうまく行ったら、そのままstable/10を
使うのも一手ですし、基本10.3-RELEASEからfreebsd-updateでuserlandを
更新しつつカーネルだけソースで更新（今回同様、patch -p2 -Rで手動
backout）するのも可でしょう。

いずれにせよ、これで駄目ならもう私の現状では白旗を上げざるを得ません。

> 
> 
> --
> けんずふぁみりー
> _______________________________________________
> freebsd-users-jp at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-users-jp
> To unsubscribe, send any mail to "freebsd-users-jp-unsubscribe at freebsd.org"
> 

-- 
青木 知明  [Tomoaki AOKI]    <junchoon at dec.sakura.ne.jp>