Armadilloフォーラム

量産用インストールディスクでコンテナのverがunsetになる

nshmr

2024年9月27日 13時42分

abos-ctrl make-installer にて作成したmicroSDを使って初期化した環境を、.swuイメージ(作成方法は後述)を使ってアップデートすると、アップデートは完了し、コンテナ自体の動作にも問題はないのですが、ログイン時に以下のようなメッセージが出ます。

Last update on Fri Sep 27 12:58:23 JST 2024, updated:                                             
  extra_os.tlv_judge: unset -> 80                                                                 
  tlv_judge: unset -> 80                                                                          
  boot: 2020.4-at22 -> 80                                                                         
  base_os: 3.19.1-at.1 -> 3.20.3-at.3                                                             
WARNING: upgrade_available wasn't either unset, 0, 1 or 2? 

# 最後のWARNINGの行は、rootでログインした場合は出ません。
また、アップデート対象にbase_osを含めないと、.swuファイルを入れたUSBメモリーを挿しても、アップデートが実行されません。

これらの原因は、初期イメージにて、
extra_os.tlv_judgeとtlv_judgeのver情報がunsetになっていたためと推測しているのですが、合っていますでしょうか?
また、その場合の解決方法としては、初期イメージを作成する際に、これらのver情報を入れておく必要があると思うですが、それはどのようにすれば良いでしょうか?

[使用している.swuの作り方]
当方のシステムでは、OP-TEEを使用しています。
そのため、Atmark techno様提供のBase OSアップデート用swuファイルでは、boot loaderが標準のものに書き換えられてしまい、当方作成のboot loaderに再度書き換えるまで、OP-TEEが正常に動作しなくなるため、Armadillo Base OSアーカイブからswuファイルを作成しています。

# mkswu base_os.desc tlv_judge.desc -o ./update_judgement_logic_box.swu

base_os.descの内容 (Base OSの更新)

swdesc_option component=base_os
swdesc_option version=3.20.3-at.3
swdesc_tar --preserve-attributes --base-os baseos-x2-3.20.3-at.3.tar.zst

tlv_judge.descの内容 (boot loaderとコンテナの更新)

swdesc_option version=80
swdesc_boot /home/atmark/JL/imx-boot/imx-boot_armadillo_x2
swdesc_embed_container "tlv_judge_v1.1.1.tar"
swdesc_files --extra-os --dest /etc/atmark/containers/ "tlv_judge.conf"
コメント

nshmrさん

お世話になっています、
マルティネです

> # 最後のWARNINGの行は、rootでログインした場合は出ません。

このワーニングについてはこちらの確認不足です、非rootユーザーですと uboot の環境変数を読み取れないので変なワーニングが表示されますが無視していいです。
10月のアップデートで対応します。

> また、アップデート対象にbase_osを含めないと、.swuファイルを入れたUSBメモリーを挿しても、アップデートが実行されません。

こちらについてはおかしいですね。
base_os があってもなくてもアップデート対象のバージョンがあればインストールされるはずですので、USBメモリーを指した後に /var/log/messages を確認していただけますでしょうか。
grep -i swupdate /var/log/messagesの出力を https://armadillo.atmark-techno.com/faq/swupdate-troubleshooting-abos
に検索すれば理由が分かるかと思います

> これらの原因は、初期イメージにて、
> extra_os.tlv_judgeとtlv_judgeのver情報がunsetになっていたためと推測しているのですが、合っていますでしょうか?

はい、バージョンがまだ記載されていない環境から SWU をインストールするとアップデート状態は 「unset から」として表示されます。

> また、その場合の解決方法としては、初期イメージを作成する際に、これらのver情報を入れておく必要があると思うですが、それはどのようにすれば良いでしょうか?

解決のはインストールしない問題だと思いますが、別に解決したいことがあれば教えてください。

よろしくお願いします

マルティネさん
お世話になっております。

アップデートされるのであれば、元のversionがunsetと表示されることは、問題ありません。

> > また、アップデート対象にbase_osを含めないと、.swuファイルを入れたUSBメモリーを挿しても、アップデートが実行されません。
>
> こちらについてはおかしいですね。
> base_os があってもなくてもアップデート対象のバージョンがあればインストールされるはずですので、USBメモリーを指した後に /var/log/messages を確認していただけますでしょうか。
> grep -i swupdate /var/log/messagesの出力を https://armadillo.atmark-techno.com/faq/swupdate-troubleshooting-abos
> に検索すれば理由が分かるかと思います

/var/log/messages のメッセージを確認したところ、

Sep 30 10:17:28 armadillo user.err swupdate: FAILURE ERROR : ----------------------------------------------                                                                                                    
Sep 30 10:17:28 armadillo user.err swupdate: FAILURE ERROR : /!\ the following users have an empty password, failing update: setup                               
Sep 30 10:17:28 armadillo user.err swupdate: FAILURE ERROR : ----------------------------------------------

が出ておりました。これは、初回ログイン時にユーザーにパスワードを付けてもらうつもりのアカウントで、パスワードを意図的に未設定にしていました。
このアカウントにパスワードを付ければ解決するのかと思っていたのですが、初期イメージに書き戻しとパスワード設定を行った後、同じアップデートファイルの入ったUSBメモリを挿すと、Armadilloが再起動はするようになったのですが、アップデートされていませんでした。(rollbackされているようです。)

Sep 30 10:30:59 armadillo user.err swupdate: FAILURE ERROR : ----------------------------------------------                                                                                                    
Sep 30 10:30:59 armadillo user.err swupdate: FAILURE ERROR : /!\ Update looks like it already had been installed but rolled back, failing on purpose.                                                          
Sep 30 10:30:59 armadillo user.err swupdate: FAILURE ERROR : /!\ Set SW_ALLOW_ROLLBACK=1 environment variable to force installing anyway.                                                                      
Sep 30 10:30:59 armadillo user.err swupdate: FAILURE ERROR : ----------------------------------------------

何故、rollbackされるのか、原因を調べる方法があれば、教えてください。(base OSのアップデートを含めるとrollbackされず、正常にアップデートされる理由もまだはっきりしていません。)

調査の過程で4通りのパターンを試してみました。
パターン1. パスワード未設定、base OSを含めてアップデート -> 再起動する + アップデートされる。(最初の問い合わせ時の比較対象)
パターン2. パスワード未設定、boot loaderとコンテナのみアップデート -> 再起動しない(最初の問い合わせ時の相談内容)
パターン3. パスワード設定済み、boot loaderとコンテナのみアップデート -> 再起動する + アップデートされない(roolbackされる) (上記の内容)
パターン4. パスワード設定済み、base OSを含めてアップデート -> 再起動する + アップデートされる。
各パターンで、grep -i swupdate /var/log/messagesした結果を参考として添付しておきます。
(パターン1とパターン4は、実質的に同じ内容になりました。)

ファイル ファイルの説明
パターン1.txt パスワード未設定、base OSを含めてアップデート、再起動後の内容
パターン2.txt パスワード未設定、boot loaderとコンテナのみアップデート、USBメモリ挿入後、しばらく経ってからの内容
パターン3.txt パスワード設定済み、boot loaderとコンテナのみアップデート、再起動後の内容
パターン4.txt パスワード設定済み、base OSを含めてアップデート、再起動後の内容

at_dominique.m…

2024年9月30日 15時25分

nshmrさん

マルティネです。

ログと追加説明ありがとうございます。

> > base_os があってもなくてもアップデート対象のバージョンがあればインストールされるはずですので、USBメモリーを指した後に /var/log/messages を確認していただけますでしょうか。
> > grep -i swupdate /var/log/messagesの出力を https://armadillo.atmark-techno.com/faq/swupdate-troubleshooting-abos
> > に検索すれば理由が分かるかと思います
>
> /var/log/messages のメッセージを確認したところ、
>

> Sep 30 10:17:28 armadillo user.err swupdate: FAILURE ERROR : ----------------------------------------------                                                                                                    
> Sep 30 10:17:28 armadillo user.err swupdate: FAILURE ERROR : /!\ the following users have an empty password, failing update: setup                               
> Sep 30 10:17:28 armadillo user.err swupdate: FAILURE ERROR : ----------------------------------------------
> 

> が出ておりました。これは、初回ログイン時にユーザーにパスワードを付けてもらうつもりのアカウントで、パスワードを意図的に未設定にしていました。

なるほど、パスワードが設定されてなかったんですね。
base OS のアップデートが入ってもそのチェックはあるはずですが、base os にパスワードが設定されているか、何かの処理の問題でエラーしない可能性もありますので、後ほど確認します。

確かに最終ユーザーにパスワードを設定させる想定でしたらパスワードなくてもいいですね。お手数をお掛けしました。
マニュアルに書いてないオプションですが、desc ファイルに「swdesc_option ALLOW_EMPTY_LOGIN」を追加していただければインストール可能になります。

今後の対応としてちょっと考えさせてください(変更必要なアカウントを許すか、マニュアルや faq を更新するかは社内で相談してから対応します)

> このアカウントにパスワードを付ければ解決するのかと思っていたのですが、初期イメージに書き戻しとパスワード設定を行った後、同じアップデートファイルの入ったUSBメモリを挿すと、Armadilloが再起動はするようになったのですが、アップデートされていませんでした。(rollbackされているようです。)

> Sep 30 10:30:59 armadillo user.err swupdate: FAILURE ERROR : ----------------------------------------------                                                                                                    
> Sep 30 10:30:59 armadillo user.err swupdate: FAILURE ERROR : /!\ Update looks like it already had been installed but rolled back, failing on purpose.                                                          
> Sep 30 10:30:59 armadillo user.err swupdate: FAILURE ERROR : /!\ Set SW_ALLOW_ROLLBACK=1 environment variable to force installing anyway.                                                                      
> Sep 30 10:30:59 armadillo user.err swupdate: FAILURE ERROR : ----------------------------------------------

> 何故、rollbackされるのか、原因を調べる方法があれば、教えてください。(base OSのアップデートを含めるとrollbackされず、正常にアップデートされる理由もまだはっきりしていません。)

インストールが成功して、再起動しましたが rollback されているようですね。
恐らく /var/at-log/atlog に何かの rollback の記録があると思いますが、確認していただけますか?
タイミング的に u-boot でカーネルを起動できなかったように見えますが「Could not load fdt file」や「Could not boot image」等のメッセージが多少のヒントになるかもしれません。Base OS のイメージのアップデートに起動に関連するファイルがあって、標準にないファイルがあるかもしれません。
それで原因が分からなかった場合はお手数ですがシリアルコンソールを接続して再起動のログを取得していただければこちらで確認します。

よろしくお願いします。

マルティネさん
お世話になっております。

rollbackしてしまう現象ですが、再現しなくなってしまいました。(パスワードを設定している場合、正常にアップデートできるようになってしまいました。)

abosのアップデートを含めるとアップデートできるのに、ブートローダーとコンテナだけのアップデートの場合アップデートできなかった件は、
原因が分かりました。

別スレッド https://armadillo.atmark-techno.com/forum/armadillo/22573 を立てさせてもらいましたが、パスワードなしのアカウントはabosをアップデートすると、/etc/shadowから消されるため、形式上はパスワードなしのアカウントがなくなっていて、アップデートは成功していたようです。
(実際には、/etc/shadowからそのユーザー行が消えているため、ログインできなく(パスワードの変更もできなく)なっていました。)

versionがunsetでもアップデートできることと、パスワードなしの場合でもアップデートできるようにする方法もわかったため、このスレッドはクローズさせて頂きたいです。
(別スレッド、/etc/shadowから行が消える件 については、引き続きお付き合いください。)