Armadilloフォーラム

dump_rootfsの差分について

daisuke2

2024年1月11日 10時04分

作成したソースコードなどに変化が無い同一のファイル・手順にて生成されたdump_rootfsの作成結果に差分が発生します。
random-seed、timestanpsや実行コマンド等の履歴ファイルが毎回更新されてしまうのは分かるのですが、~XXX等の一時ファイルと思われるものが存在したりしなかったり、作成したアプリケーション部分のオブジェクトファイルが一致しない状況が出たりしています。
これらの差分を発生させずに毎回一致したdump_rootfsを作成する方法はありますでしょうか?

また、どうしても一致しない場合、作成したソースコードなどに変化が無い同一のファイル・手順にて生成された2つの一致しないdump_rootfsが同じものである保証はどのようにとったら良いのでしょうか?

コメント

at_kojiro.yamada

2024年1月11日 16時54分

dump_rootfs は rootfs 上のファイルには書き込みを行わないので、
1 回目のdump_rootfsとその次のdump_rootfsの間で 誰か がファイルを更新しているはずです。
(dump_rootfs は、 initramfs にいる間に tar コマンドを実行して rootmnt (rootfsがmountされています) から dump_rootfs.tar.gz を作るだけです。)

差分を発生させないようにするためには、1つ1つ原因を突き止めて対処していくしかないと思います。
ファイルが不要なのであれば、/etc/dumprootfs/excludes.list にそのファイルのパスを追加して dump の対象から除外したほうが良いです。

あとは、Linuxのディレクトリ構成(https://manual.atmark-techno.com/armadillo-guide-std/armadillo-guide-st…)が参考になると思います。
/tmp/* は、 Linux が起動されるたびに削除される一時ファイルなので excludes.list に追加して良いです。(これはデフォルトの excludes.list に追加しておけばよかったですね…すみません。)

他のファイルについては、
個別に見ていくか、
もしくはソフトウェア(/bin, /lib等の下にあるもの)に差分が無いなら、ソフトウェアが変更したファイルにおかしな差分は無いと割り切ってしまうか(保証とまでは言えませんが、ある程度妥当だとは思います)、
でしょうか…

以上、参考になれたら幸いです。

daisuke2

2024年1月18日 14時43分

ご回答ありがとうございます。

すみません。手順の記載にぬけがありました。
実行している手順は
・同一のソースコードをビルド→dump_rootfsの作成を繰り返す。
です。申し訳ありません。

追加で質問なのですが、上記の手順だけで作成されたdump_rootfsごとに多数の差分(どちらかにしか無いファイルやファイルの内部の差分)が発生してしまうのでしょうか?

daisuke2

2024年1月26日 18時47分

質問事項がわかりにくくなっておりましたので、以下、補足して改めて質問を投稿致しますので、ご確認お願い致します。

ビルド→dump_rootfsの作成を繰り返した場合のに発生する差分の詳細は以下になります。
(毎回同じでは無いですがほぼ以下で発生)

発生ディレクトリ(x,y,zの部分は公開できないディレクトリ名なので変えてます)
 root
 usr\src\simw-top\pycli\output
 usr\src\xxxxx\yyyyy\build\CMakeFiles
 usr\src\xxxxx\zzzzz\build\CMakeFiles
 var\cache
 var\lib
 var\xxxxx

各ディレクトリで差分が出ているのは以下のファイルになります。

root
.bash_history
~.ssscli_session.pkl

usr\src\simw-top\pycli\output
error_log.txt

usr\src\xxxxx\yyyyy\build\CMakeFiles
CMakeError.log
CMakeOutput.log

usr\src\xxxxx\zzzzz\build\CMakeFiles
Makefile.cmake

var\cache
aux-cache
index.db

var\lib
status
timestamps
random-seed

var\xxxxx
CloudStatus.json
certificatesiotCloud_Publish
certificatesiotCloud_Subscribe

varディレクトリはLinuxのディレクトリ構成のHPを確認すると頻繁に更新されるファイルとのことなのでこれらは更新があっても問題無いとして、

以下のディレクトリのテキストファイル系(.bash_historyはコマンド履歴のため除くビルドの際のログファイル系)は同じソースコードのビルドなのにログの内容が変わるのはなぜなのでしょうか?
root
usr

また、~.ssscli_session.pkl等のビルド毎に存在したりしなかったりするファイルは、なぜ発生するのでしょうか?
これらについては発生していても(dump_rootfs作成時に存在していただけ)問題ないと考えてよいでしょうか?

at_kojiro.yamada

2024年1月29日 18時40分

> varディレクトリはLinuxのディレクトリ構成のHPを確認すると頻繁に更新されるファイルとのことなのでこれらは更新があっても問題無いとして、
>
> 以下のディレクトリのテキストファイル系(.bash_historyはコマンド履歴のため除くビルドの際のログファイル系)は同じソースコードのビルドなのにログの内容が変わるのはなぜなのでしょうか?
> root
> usr

.bash_history についてはご認識のとおりです。
他のファイルについては cmake の生成物か、cmake の生成物(Makefile)による生成物かと思います。

cmake には詳しくないのですが、少し検索しただけでも、目的の成果物とそれ以外を区別するために色々工夫されている方がいらっしゃるのがわかります。
cmake の使いこなしの問題になりそうです。

差分を少なくするという意味では、install 後に clean してから dumprootfs を実行すると良いかもしれません。
中間ファイルと一緒にビルド結果も削除されますが、 install したものは削除されないので動作には問題ないはずです。
想像ですが、
cmake
make
make install
dumprootfs
のようにしているところを
cmake
make
make install
make clean
dumprootfs
というふうにすることになると思います。

> また、~.ssscli_session.pkl等のビルド毎に存在したりしなかったりするファイルは、なぜ発生するのでしょうか?

CMakeLists.txt か、cmake が生成したMakefile を読めばどこかに書いてあるとは思いますが、なんとも言えません。

> これらについては発生していても(dump_rootfs作成時に存在していただけ)問題ないと考えてよいでしょうか?

cmake が生成した Makefile の中に install ターゲットがあると思いますが、
その中に ~.ssscli_session.pkl が無いなら実行時に ~.ssscli_session.pkl は不要なはずです。

ビルド後に make install を実行してビルドしたものをインストールしていると思いますが、
make install によって /root/~.ssscli_session.pkl が作られるなら必要、
そうでないのなら(少なくとも実行環境には)不要、
ということになります。