博士

やあ、ロボ子！DebDroidプロジェクトについての記事は読んだかのじゃ？古いAndroidデバイスを再利用して、ポータブルデスクトップや軽量サーバーにするなんて、面白い発想じゃな！

ロボ子

はい、博士。Termuxとは違って、glibcベースのLinuxユーザーランドを動かすところが興味深いと思いました。でも、ずいぶんと苦労されたようですね。

博士

そうなんじゃ。最初はsshdとgpgを動かすのが目標だったらしいが、古いAndroidカーネルがgetrandom()システムコールをサポートしてない問題にぶつかったみたいじゃ。

ロボ子

/dev/urandomから直接読み取るスタブ実装を作って、ldでプリロードしたんですね。なかなか賢い回避策です。

博士

じゃろ？じゃが、X11/Xfce4 VNCセッションがフリーズするという、新たな問題が発生したんじゃ。xfce4-sessionプロセスがハングアップして、デバッグに苦労したみたいじゃぞ。

ロボ子

gdbやstraceを使って原因を特定しようとしたんですね。GLibやGTK3のデバッグビルドまで作ったとは、すごい執念です。

博士

systemdが原因かと思ってDevuanイメージに移行しても解決しなかったのは、気の毒じゃったな。原因はsyscall()ラッパーが引数を正しく転送していなかったことだったとは…

ロボ子

getrandom()システムコールを処理する際に、引数をreal_syscallに正しく渡していなかったんですね。まさか、そんなところに落とし穴があったとは。

博士

まさに「小さな互換性の修正が長期にわたる問題を引き起こす可能性がある」という教訓じゃな。syscall()をグローバルにオーバーライドするのは危険じゃと。

ロボ子

本当にそうですね。問題が解決しないときは、まず自分自身を疑うべき、というのも肝に銘じておきます。

博士

syscall()内でva_argを使って引数を抽出し、real_syscallに渡すように修正したことで、ようやく問題が解決したんじゃな。めでたしめでたし。

ロボ子

本当に長い道のりでしたね。しかし、この記事から得られる教訓は非常に大きいと思います。

博士

そうじゃな。ところでロボ子、もしロボ子が原因不明のエラーに遭遇したら、どうする？

ロボ子

まずは自分のコードを疑います。そして、それでも解決しなければ、博士に泣きつきます！

博士

ふむ、よろしい。じゃが、その前に、ロボ子のエラーの原因が、実はロボ子の充電切れだった、なんてオチもあり得るぞ？