ahirata
2025年2月3日 14時38分
お世話になります。
Armadillo-X2を購入し、ATDEの環境構築を行って、
X2が立ち上がるところまでできております。次に、
Raspberry PiからArmadilloへの移行をやりたい
と思っており、下記のサイトを参考にしていましたが、
エラーが出ており対処方法に困っております。
どなたか同じようなエラーを解決された方はおられませんでしょうか?
私は、ラズパイを使った機器開発をしているソフト屋ですが、
Linuxのコマンドについては、それほど詳しくない状態です。
参考にしたのは下記のサイトです。
https://armadillo.atmark-techno.com/migrate-from-rpi-to-armadillo/softw…
この中の「imgファイルのrootfsを使用する場合」の箇所で、
実施した手順は下記の通りです。
手順1)
$ sudo losetup --show -f -P kernel8.img (←使用していたラズパイのイメージ)
出力結果1)
/dev/loop0
losetup: kernel8.img: Warning: file does not fit into a 512-byte sector; the end of the file will be ignored. (←Warningが出ている)
手順2)
Warningは出ていますが、/dev/loop0自体できているので、先に進めると、
下記のエラーが出ます。
$ mkdir rpi
$ sudo mount /dev/loop0 rpi
出力結果2)
mount: /home/atmark/rpi: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepae or helper program, or other error. (←errorが出ている)
なお、こちらではラズパイはラズパイ5とラズパイ4Bを使用しており、
どちらのイメージを使っても同じ結果になりました。
ラズパイのイメージが悪いような気がしますが、それを修復する方法がわかりません。
コメント
ahirata
> rpiのディスクイメージの構造がhowtoで想定していない状態のようです。
>
> もともとのディスクイメージをどうやって作ったorどこからダウンロードしたものか
> 教えてもらえるでしょうか。
> ツールを利用している場合はそのバージョンも教えてほしいです。
https://armadillo.atmark-techno.com/migrate-from-rpi-to-armadillo/softw…
「imgファイルのrootfsを使用する場合」に
>1.ATDEにRaspberry Piで使用しているimgファイルを保存します。
の記載があるので、ラズパイに挿しているSDカードに格納してあった
kernel8.imgをそのまま保存しています。
at_ohsawa
> https://armadillo.atmark-techno.com/migrate-from-rpi-to-armadillo/softw…
> 「imgファイルのrootfsを使用する場合」に
> >1.ATDEにRaspberry Piで使用しているimgファイルを保存します。
> の記載があるので、ラズパイに挿しているSDカードに格納してあった
> kernel8.imgをそのまま保存しています。
いいえ、そちらではなくラズパイのSDカード自体に書き込んでいるイメージを
どう作ったのかを教えてほしいです。
ahirata
> > https://armadillo.atmark-techno.com/migrate-from-rpi-to-armadillo/softw…
> > 「imgファイルのrootfsを使用する場合」に
> > >1.ATDEにRaspberry Piで使用しているimgファイルを保存します。
> > の記載があるので、ラズパイに挿しているSDカードに格納してあった
> > kernel8.imgをそのまま保存しています。
>
> いいえ、そちらではなくラズパイのSDカード自体に書き込んでいるイメージを
> どう作ったのかを教えてほしいです。
コメントありがとうございます。
進展がありましたので展開します。
[前提1]
まず、
https://armadillo.atmark-techno.com/migrate-from-rpi-to-armadillo/softw…
の「imgファイルのrootfsを使用する場合」に記載されている
>1.ATDEにRaspberry Piで使用しているimgファイル
が何か分からなかったので、
「SDカードのrootfsを使用する場合」にやり方を切り替えたところ、
先にお話ししていたWarningやErrorはでなくなりました。
手順1)
その上で、ご質問に対する回答ですが、
>ラズパイのSDカード自体に書き込んでいるイメージ
==>
ラズベリーパイの公式サイト(https://www.raspberrypi.com/software/)から
imager_1.8.5.exeをダウンロードし、「ラズパイ4」「ラズパイOS(Legacy=Bullseye, 64-bit)」
を選択しました。
手順2)
「SDカードのrootfsを使用する場合」は、記載の通りに実行でき、
「rootfsをPodmanのイメージとして読み込む」を実行しました。
画面出力)
「rootfsをPodmanのイメージとして読み込む」において、
#podman import /mnt/rpi_rootfs.tar rpi_image
を実行したところで、下記エラーが出ました。
Getting image source signatures
Copying blob 7cba8c809c8e done !
Error : writing blob: adding layer with blob "sha256:...(文字列省略)....."/""/"sha256:.....(文字列省略).....":
unpacking failed (error: exit status 1; output: write /usr/share/pocketsphinx/model/en-us/en-us.lm.bin: no space left on device)
このようなエラーについて、解決方法を教えてください。
at_ohsawa
> imager_1.8.5.exeをダウンロードし、「ラズパイ4」「ラズパイOS(Legacy=Bullseye, 64-bit)」
> を選択しました。
imagerを使って取得しているのですね。イメージからの抜き出しではなく
rootfsを使うのであればこちらをQAする意味は無いのですが、rpiのイメージの
パーティションオフセット等の仕様が記事作成時から変わっているかもしれません。
別途確認しておきます。
> 手順2)
> 「SDカードのrootfsを使用する場合」は、記載の通りに実行でき、
> unpacking failed (error: exit status 1; output: write /usr/share/pocketsphinx/model/en-us/en-us.lm.bin: no space left on device)
そこに書かれているようにArmadilloのeMMCの容量を超えて
読み込もうとしてeMMCの容量がなくなっています(no space left on device)
rpi_rootfs.tarの容量を知りたいので以下で確認してみてください。単位はバイトです。
もし、7Gバイト近いのであれば絶対にeMMC上に配置できないので、イメージの
ダイエットをする必要があります。
また、リモートアップデート時は2面分持つためその半分以下の3GB前後である
必要があるため、ギリギリを狙うと最初に一旦展開できても、アップデートできません。
これについてもダイエット必要なので、容量が大きければ具体的な容量やシステムの内容を
教えてください。
(rpiで意識せずに開発すると、かなり運用には不要なパッケージが入っている場合が多い
のとログ等多いので、かなりの部分を消せるとは思います。)
# tar -tvf rpi_rootfs.tar | awk '{print $3}' | paste -sd+ | bc
また、すでにArmadillo上に幾つかコンテナを作っていることで
容量を消費しているのであれば、必要なければ削除することで
広げることができます。 "podman images"の結果にコンテナが
すでに存在していれば、その名前と容量が表示されます。
ahirata
> rpi_rootfs.tarの容量を知りたいので以下で確認してみてください。単位はバイトです。
> もし、7Gバイト近いのであれば絶対にeMMC上に配置できないので、イメージの
> ダイエットをする必要があります。
> また、リモートアップデート時は2面分持つためその半分以下の3GB前後である
> 必要があるため、ギリギリを狙うと最初に一旦展開できても、アップデートできません。
> これについてもダイエット必要なので、容量が大きければ具体的な容量やシステムの内容を
> 教えてください。
>
> (rpiで意識せずに開発すると、かなり運用には不要なパッケージが入っている場合が多い
> のとログ等多いので、かなりの部分を消せるとは思います。)
>
> # tar -tvf rpi_rootfs.tar | awk '{print $3}' | paste -sd+ | bc >
ありがとうございます。
上記コマンドを実行したところ、
3322633204
と表示されました。
かなり大きいのでダイエットが必要ですが、
下記に記載のとおり、他のコンテナを削除すると
ひとまずは起動させることができました。
> また、すでにArmadillo上に幾つかコンテナを作っていることで
> 容量を消費しているのであれば、必要なければ削除することで
> 広げることができます。 "podman images"の結果にコンテナが
> すでに存在していれば、その名前と容量が表示されます。
ただ、一旦終了させて、再度起動させる方法がわかりません。
"podman images"の結果には、REPOSITORYの列に
localhost/rpi_image
が表示されています。
at_ohsawa
コンテナを永続的に(Armadillo自体の電源投入と同時に)起動させるには
podmanコマンドを直接使うのではなく、/etc/atmark/containersに
設定ファイルを置いておくと自動的に起動してくれますし、手動でも
$ podman_start -a
というコマンドで、設定が存在するコンテナをまとめて手動で起動できます。
参照:
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-base-os-dev…
(podman startではなくpodman_startです。オリジナルのpodmanをwrapして設定処理等しています)
ahirata
/etc/atmark/containersに設定ファイル(.conf)を置いて、
$ podman_start -a
を実行しましたが、下記のように表示されました。
armadillo:/etc/atmark/containers# podman_start -a Starting 'rasp4B' 2890a349009f0279c69bf72eca8725a838b0dfe177e17f6c88db657371366235 armadillo:/etc/atmark/containers#
起動しているようにも見えますが、プロンプトは変わっていません。
設定ファイル(rasp4B.conf)は、下記のように記載しています。
設定ファイルの書き方がわかっていないのだと思いますので、ご教示をお願いします。
set_image "localhost/rpi_image" set_command rpi_container /bin/bash
at_ohsawa
> 起動しているようにも見えますが、プロンプトは変わっていません。
> 設定ファイル(rasp4B.conf)は、下記のように記載しています。
> 設定ファイルの書き方がわかっていないのだと思いますので、ご教示をお願いします。
>
> set_image "localhost/rpi_image" > > set_command rpi_container /bin/bash >
>
>
>
いいですね。少し違いますが無事動いています。
https://manual.atmark-techno.com/armadillo-x2/armadillo-x2_product_manu…
書式は製品マニュアルを参照してください、howtoには本当に最小限の情報しかありません。
まず、set_commandにはコマンドを書くのでrpi_containerは不要です。
そして、bashが起動して特に何もしないで終了します。
dockerで docker run hoge bashとしたら、すぐにbashが実行完了するのと一緒です。
普通完成したコンテナを運用するということは、人間はコンソールを触らず、
- サービスとして終了しないアプリケーション
- 起動時にワンショットのアプリケーション
いずれかを実行するものなので、ここにはそういうものを書きます。
単に何も実行せずにshellにつなぎたいのであれば
commandにsleepを引数infinityを書いておくと、コンテナが起動しっぱなしになります。
set_command sleep infinity
もし、その場でコンソールに繋ぎたいのであれば、その状態で
podman exec -it rpi_container bash
のように稼働済みのコンテナにexecで繋ぐと良いです。
(これもdockerと完全に一緒です)
ただし、armadilloの場合、shutdown等せずに電源を途中遮断
した場合でもファイルシステムの破壊をしないよう、
書き込み禁止でシステムを動かしています。
そのため、shellから変更を加えても電源を切ると変更は消えます。
(変更を保存可能なvolume mount可能な領域もあります)
そのHowtoでは基本的にその場でログインして開発するのではなく、
rpiですでに開発済みのコンテナを持ってくることを想定しているのですが、
そのような実装を動かしたいのか教えてもらえると、
もっと詳細にサポートできると思います。
もしくは、コンテナ自体の開発をしたい場合は
ABOSDEという環境でVSCode上でPC側でコンテナを開発・エミュレート実行して
適宜Armadilloに転送するワークフローを推奨しています。
(製品マニュアルとABOS開発ガイドを参照してください)
もし、rpiでほぼ何も開発していないのであればデータを持ってくる意味が
無いので、ABOSDEを使った開発をするのが良いです。
ahirata
設定ファイル(rasp4B.conf)を下記のように変更しました。
(”set_command sleep infinity"にした)
set_image "localhost/rpi_image" set_command sleep infinity
結果は、下記のようになり、起動してそうですが、
1秒後くらいにプロンプトが返ってきました。
(set_commandで"sleep infinity"としていたので、プロンプトは返ってこないものと思っていました。)
armadillo:# podman_start -a Starting 'rasp4B' 900e027fab0354517c237a2815a2f9f7e479c352085a4e5cf29c96003836abdc (1秒後くらいに) armadillo:#
さらに、この状態で
armadillo:#podman exec -it rpi_container bash
を実行すると、下記エラーが表示されました。
Error: can only create exec sessions on running containers: container state improper
コンテナのステートが合っていないようですが、どのように合っていないのでしょうか?
at_shinya.koga
アットマークテクノの古賀です。
ahirataさん:
>設定ファイル(rasp4B.conf)を下記のように変更しました。
>(”set_command sleep infinity"にした)
set_image "localhost/rpi_image" set_command sleep infinity
...
>さらに、この状態で
armadillo:#podman exec -it rpi_container bash
>を実行すると、下記エラーが表示されました。
Error: can only create exec sessions on running containers: container state improper
>
>コンテナのステートが合っていないようですが、どのように合っていないのでしょうか?
running ステートではないのかも知れません。次のように pdoman ps コマンドを実行して、コンテナおよびイメージ名とステートを一覧表示してみてください:
armadillo:~# podman ps -a --format "{{.Names}} {{.Image}} {{.State}}"
https://docs.podman.io/en/latest/markdown/podman-ps.1.html
コンテナイメージ名 localhost/rpi_image のコンテナのステートが running ではない場合、次のように podman logs コマンドを実行して、コンテナのログ出力内容を見てみてください:
armadillo:~# podman logs [コンテナ名]
ところで、
>結果は、下記のようになり、起動してそうですが、
>1秒後くらいにプロンプトが返ってきました。
>(set_commandで"sleep infinity"としていたので、プロンプトは返ってこないものと思っていました。)
armadillo:# podman_start -a Starting 'rasp4B' 900e027fab0354517c237a2815a2f9f7e479c352085a4e5cf29c96003836abdc (1秒後くらいに) armadillo:#
podman_start -a で、/etc/atmark/containers/ に起動設定ファイルを配置したコンテナを起動しても、コンテナにターミナルが割り当てられていなければ、コンテナの起動が済んだらプロンプトが返ってきます。デフォルトでは、コンテナにターミナルを割り当てませんから、podman_start -a コマンドの実行後にプロンプトが返ってきます。
ahirata
下記コマンドを実行してみました。
armadillo:/etc/atmark/containers# podman ps -a --format "{{.Names}} {{.Image}} {{.State}}"
出力結果は下記のようになりました。
rasp4B localhost/rpi_image:latest running rpi_container localhost/rpi_image:latest exited armadillo:/etc/atmark/containers#
一度はrunningになっているものの、その後exitedになっているようです。
また、下記コマンドも実行してみました。
armadillo:~# podman logs rpi_container
出力結果が100行ほど出てきましたが、最後の2行は下記のようになっており、
1週間ほど前に1度だけコンテナに入れたときの最後のexitのコマンドが出力
されているように見えます。
[?2004hroot@baec509a1cd:/# cd /home/pi2 [?2004hroot@baec509a1cd:/home/pi2# exit
1点質問ですが、前回のコメントにて
>コンテナにターミナルが割り当てられていなければ、
と記載していただいていますが、コンテナにターミナルを割り当てるとは
どのようにすればよいのでしょうか?
現状、コンテナにターミナルを割り当てていませんので、そのために
一度はrunningになるものの、その後exitedになっているのかもしれません。
at_shinya.koga
アットマークテクノの古賀です。
ahirataさん:
>下記コマンドを実行してみました。
armadillo:/etc/atmark/containers# podman ps -a --format "{{.Names}} {{.Image}} {{.State}}"
>
>出力結果は下記のようになりました。
rasp4B localhost/rpi_image:latest running rpi_container localhost/rpi_image:latest exited armadillo:/etc/atmark/containers#
同じコンテナイメージ(localhost/rpi_image:latest)から生成されたコンテナが二つあり、rasp4B が runinng ステート、rpi_container が exited ステートですね。
2/14 に頂いた、以下のコメントと併せて見ると、podman_start -a で起動された方が rasp4B で、こちらが running ステートです。
しかし、podman exec では、exited ステートになっている rpi_container を指定していらっしゃるのでエラーする、というわけです。
ahirataさん(2025年2月14日 17時09分):
>結果は、下記のようになり、起動してそうですが、
>1秒後くらいにプロンプトが返ってきました。
>(set_commandで"sleep infinity"としていたので、プロンプトは返ってこないものと思っていました。)
armadillo:# podman_start -a Starting 'rasp4B' 900e027fab0354517c237a2815a2f9f7e479c352085a4e5cf29c96003836abdc (1秒後くらいに) armadillo:#
ahirataさん(2025年2月14日 17時09分):
>一度はrunningになっているものの、その後exitedになっているようです。
というわけで、既に exited になっている方のコンテナ(rpi_container)を podman exec で指定しているのがエラーの原因です。
>また、下記コマンドも実行してみました。
>
>armadillo:~# podman logs rpi_container >
>
>出力結果が100行ほど出てきましたが、最後の2行は下記のようになっており、
>1週間ほど前に1度だけコンテナに入れたときの最後のexitのコマンドが出力
>されているように見えます。
[?2004hroot@baec509a1cd:/# cd /home/pi2 [?2004hroot@baec509a1cd:/home/pi2# exit
rpi_container の終了については、おっしゃる通りの状況なのでしょう。
>1点質問ですが、前回のコメントにて
>>コンテナにターミナルが割り当てられていなければ、
>と記載していただいていますが、コンテナにターミナルを割り当てるとは
>どのようにすればよいのでしょうか?
起動設定ファイルで設定する引数オプションを追加すれば可能ですが、今回の件では、ターミナルを割り当てる必要は、ありません。
>現状、コンテナにターミナルを割り当てていませんので、そのために
>一度はrunningになるものの、その後exitedになっているのかもしれません。
いえ、上で述べたように、停止済み(exited)のコンテナと動作中(running)のコンテナができており、停止済みのコンテナに対して podman exec を実行しているのが原因です。動作中のコンテナ、つまり rasp4B に対して podman exe を実行してみてください。
ahirata
ありがとうございます。
すでにrpi_continerがあるのに、rasp4Bを新規に作成していたことをようやく理解しました。
>同じコンテナイメージ(localhost/rpi_image:latest)から生成されたコンテナが二つあり、rasp4B が running ステート、rpi_container が exited ステートですね。
>2/14 に頂いた、以下のコメントと併せて見ると、podman_start -a で起動された方が rasp4B で、こちらが running ステートです。
>しかし、podman exec では、exited ステートになっている rpi_container を指定していらっしゃるのでエラーする、というわけです。
仰る通りに下記を実行したところ、ラズパイのイメージがうまく起動しました。
armadillo:#podman exec -it rasp4B bash
その上で、さらに1点質問です。
ラズパイのイメージ上でstartxを実行して、
ラズパイと同様のX Windowを表示させたいのですが、
startxがエラーになってしまいました。
ラズパイのイメージが古い(?)などの問題なのではないかと思っていますが、
ラズパイからArmadilloへの移行が、バージョンの整合性なども含めて正常に完了できれば、
startxを実行してラズパイと同様のX Windowを表示できると考えてよろしいでしょうか?
at_shinya.koga
アットマークテクノの古賀です。
ahirataさん:
>ありがとうございます。
>すでにrpi_continerがあるのに、rasp4Bを新規に作成していたことをようやく理解しました。
...
>仰る通りに下記を実行したところ、ラズパイのイメージがうまく起動しました。
armadillo:#podman exec -it rasp4B bash
ひとまず、良かったです。ご確認有り難うございます。
>その上で、さらに1点質問です。
>ラズパイのイメージ上でstartxを実行して、
>ラズパイと同様のX Windowを表示させたいのですが、
>startxがエラーになってしまいました。
>ラズパイのイメージが古い(?)などの問題なのではないかと思っていますが、
>ラズパイからArmadilloへの移行が、バージョンの整合性なども含めて正常に完了できれば、
>startxを実行してラズパイと同様のX Windowを表示できると考えてよろしいでしょうか?
出力されたエラーメッセージが分からないので、確実ではありませんが、おそらく startx スクリプトから X サーバーを起動した際、画面出力用のフレームバッファデバイスや入力デバイスに、コンテナ内の X サーバーがアクセスできずにエラーするのではないかと思います。
Armadillo-X2 の製品マニュアルで、「画面表示を行う」の節にある「X Window System を扱う」で、コンテナ内の X サーバーがフレームバッファデバイスや入力デバイスにアクセスできるよう、コンテナの起動設定ファイルに add_devices 行を追加する例を説明しています:
https://manual.atmark-techno.com/armadillo-x2/armadillo-x2_product_manu…
https://armadillo.atmark-techno.com/resources/documents/armadillo-x2/ma…
これを参考にして、/dev/fb0 や /dev/input をコンテナからアクセスできるように設定してみてください。
ahirata
> Armadillo-X2 の製品マニュアルで、「画面表示を行う」の節にある「X Window System を扱う」で、コンテナ内の X サーバーがフレームバッファデバイスや入力デバイスにアクセスできるよう、コンテナの起動設定ファイルに add_devices 行を追加する例を説明しています:
> https://manual.atmark-techno.com/armadillo-x2/armadillo-x2_product_manu…
> https://armadillo.atmark-techno.com/resources/documents/armadillo-x2/ma…
>
> これを参考にして、/dev/fb0 や /dev/input をコンテナからアクセスできるように設定してみてください。
ありがとうございます。
Armadillo-X2 の製品マニュアルで、「画面表示を行う」の節にある「X Window System を扱う」から
イメージをダウンロードしようとしており、
「アットマークテクノが提供するイメージを使う」の
「6.2.5.3. ビルド済みのイメージを使用する」を参照しました。
その中の「Armadillo-X2コンテナ」のリンク(Armadillo-X2 コンテナ | Armadilloサイト)から
コンテナイメージ(Debian11(bullseye)サンプルコンテナイメージ)をダウンロードしたのですが、
拡張子が"md5"になっています。
「6.2.5.3. ビルド済みのイメージを使用する」では、サンプルコンテナイメージの拡張子は"tar"なのですが、
"md5"→"tar"に変換する方法を教えてください。
ahirata
失礼しました。
「Armadillo-X2コンテナ」のリンク(Armadillo-X2 コンテナ | Armadilloサイト)のイメージ本体ではなく、md5の方をダウンロードしていただけでした。
解決しましたので、ご回答は不要です。
> > Armadillo-X2 の製品マニュアルで、「画面表示を行う」の節にある「X Window System を扱う」で、コンテナ内の X サーバーがフレームバッファデバイスや入力デバイスにアクセスできるよう、コンテナの起動設定ファイルに add_devices 行を追加する例を説明しています:
> > https://manual.atmark-techno.com/armadillo-x2/armadillo-x2_product_manu…
> > https://armadillo.atmark-techno.com/resources/documents/armadillo-x2/ma…
> >
> > これを参考にして、/dev/fb0 や /dev/input をコンテナからアクセスできるように設定してみてください。
>
> ありがとうございます。
> Armadillo-X2 の製品マニュアルで、「画面表示を行う」の節にある「X Window System を扱う」から
> イメージをダウンロードしようとしており、
> 「アットマークテクノが提供するイメージを使う」の
> 「6.2.5.3. ビルド済みのイメージを使用する」を参照しました。
>
> その中の「Armadillo-X2コンテナ」のリンク(Armadillo-X2 コンテナ | Armadilloサイト)から
> コンテナイメージ(Debian11(bullseye)サンプルコンテナイメージ)をダウンロードしたのですが、
> 拡張子が"md5"になっています。
>
> 「6.2.5.3. ビルド済みのイメージを使用する」では、サンプルコンテナイメージの拡張子は"tar"なのですが、
> "md5"→"tar"に変換する方法を教えてください。
ahirata
> > Armadillo-X2 の製品マニュアルで、「画面表示を行う」の節にある「X Window System を扱う」で、コンテナ内の X サーバーがフレームバッファデバイスや入力デバイスにアクセスできるよう、コンテナの起動設定ファイルに add_devices 行を追加する例を説明しています:
> > https://manual.atmark-techno.com/armadillo-x2/armadillo-x2_product_manu…
> > https://armadillo.atmark-techno.com/resources/documents/armadillo-x2/ma…
> >
> > これを参考にして、/dev/fb0 や /dev/input をコンテナからアクセスできるように設定してみてください。
上記のように設定して、rasp4Bを起動させたところ、
下記のようなエラーが出ました。
root@57ba7a3020df:/# X vt7 -retro X.Org x Server 1.20.11 X Protocol Version 11, Revision 0 (途中省略) (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 3 14:23:44 2025 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error : (EE) xf860penConsole : Cannot open virtual console 7 (no such file or directory)
rasp4B.confに設定した/dev/tty7がないと言われているようですが、
/dev/tty7が存在することは確認しています。
「6.2.9.2. X Window Systemを扱う」には、「add_devices /dev/tty7」の注意書き(黒丸1)に
「どこからも使われていないttyとします。」
と記載されていますので、/dev/tty7はどこかで使われているのかもしれません。
ここで質問ですが、
どこからも使われていないttyはどのようにして調べればよいのでしょうか?
at_shinya.koga
アットマークテクノの古賀です。
ahirataさん:
>>>これを参考にして、/dev/fb0 や /dev/input をコンテナからアクセスできるように設定してみてください。
>
>上記のように設定して、rasp4Bを起動させたところ、
>下記のようなエラーが出ました。
>
root@57ba7a3020df:/# X vt7 -retro ... Fatal server error : (EE) xf860penConsole : Cannot open virtual console 7 (no such file or directory)
>
>rasp4B.confに設定した/dev/tty7がないと言われているようですが、
>/dev/tty7が存在することは確認しています。
念のため、一点点確認させてください:
・「/dev/tty7が存在する」とおっしゃっているのは、コンテナ上でも存在することを確認された、という認識で合っているでしょうか?
つまり、コンテナの起動設定ファイルに 'add_devices /dev/tty7' の行を追加していらして、その結果、コンテナ上でも /dev/tty7 が存在している状況でしょうか。
>「6.2.9.2. X Window Systemを扱う」には、「add_devices /dev/tty7」の注意書き(黒丸1)に
>「どこからも使われていないttyとします。」
>と記載されていますので、/dev/tty7はどこかで使われているのかもしれません。
>
>ここで質問ですが、
>どこからも使われていないttyはどのようにして調べればよいのでしょうか?
ABOS(ホスト OS)上で、次のコマンドを実行してみてください:
# lsof | grep /dev/tty
このコマンド出力に現れないものを使ってみてくださいませ。
ahirata
ありがとうございます。
> 念のため、一点点確認させてください:
>
> ・「/dev/tty7が存在する」とおっしゃっているのは、コンテナ上でも存在することを確認された、という認識で合っているでしょうか?
> つまり、コンテナの起動設定ファイルに 'add_devices /dev/tty7' の行を追加していらして、その結果、コンテナ上でも /dev/tty7 が存在している状況でしょうか。
==>
下記のように回答します。
・コンテナの起動設定ファイルに'add_devices /dev/tty7' の行を追加しています。
・その結果、コンテナ上では /dev/tty7 は存在していませんでした。
root@51f7ba3db6b5:/dev# ls -al | grep tty crw-rw-rw- 1 root root 5, 0 Mar 4 11:10 tty
>ABOS(ホスト OS)上で、次のコマンドを実行してみてください:
# lsof | grep /dev/tty
==>
コマンドを実行した結果、下記のように出力されました。
tty7は現れませんでしたが、コマンド「X vt7 -retro」の実行結果は、同じくエラー(Cannot open virtual cosole 7)でした。
/dev/tty
/dev/tty1
/dev/tty2
/dev/tty3
/dev/tty4
/dev/tty5
/dev/tty6
/dev/ttymxc1
at_shinya.koga
アットマークテクノの古賀です。
ahirataさん:
>>念のため、一点点確認させてください:
>>
>>・「/dev/tty7が存在する」とおっしゃっているのは、コンテナ上でも存在することを確認された、という認識で合っているでしょうか?
>> つまり、コンテナの起動設定ファイルに 'add_devices /dev/tty7' の行を追加していらして、その結果、コンテナ上でも /dev/tty7 が存在している状況でしょうか。
>==>
>下記のように回答します。
>・コンテナの起動設定ファイルに'add_devices /dev/tty7' の行を追加しています。
>・その結果、コンテナ上では /dev/tty7 は存在していませんでした。
追加で確認ですが、コンテナの起動設定ファイルに 'add_devices /etc/tty7' の行を追加した後、podman_start コマンドを実行してコンテナを作り直されたでしょうか?
コンテナ起動設定ファイルの add_devices などによる設定は、コンテナを生成する際に使われるものであり、既に生成済みのコンテナの動作には影響しません。
実際、標準の podman コマンドの podman start や podman exec には、そのようなオプション引数が存在していないのです:
https://docs.podman.io/en/stable/markdown/podman-start.1.html
https://docs.podman.io/en/v5.1.2/markdown/podman-exec.1.html
ホスト OS のデバイスをコンテナからアクセスできるようにするには、podman run や podman create でコンテナを生成する際に --device オプションで指定しなければいけません。
https://docs.podman.io/en/v5.2.5/markdown/podman-create.1.html
https://docs.podman.io/en/latest/markdown/podman-run.1.html
ABOS 独自のコマンドである podman_start スクリプトは、内部で podman run や podman create を実行することにより、引数で指定されたコンテナを生成・始動します。
その際に、コンテナ起動設定ファイルの add_devices 行で指定されたデバイスを、podman run や podman create に渡す --device オプションの引数として設定する仕組みなのです。
# ABOS では、基本の動作として、コンテナを起動する際に毎回イメージから作り直し、
# コンテナを immutable なものにしています。これにより、コンテナ内容(つまり、
# コンテナのルートファイルシステムの内容)が、稼働中に変化することに伴う
# セキュリティリスクを抑えているのです。
ということで、もし、コンテナの起動設定ファイルに add_devices 行を追加した後、podman_start でコンテナを作り直していらっしゃらないのであれば、作り直してみてください。
ahirata
ありがとうございます。
コンテナの起動設定ファイルにadd_devices行を追加した後、podman_startを実行していませんでした。
podman_startを実行したところ、コンテナ上にも/dev/tty7が存在するようになりました。
その上で、下記コマンドを実行したところ、モニタ一全面がグレーの画面に変わりましたが、その他の画面は表示されませんでした。
また、マウスは反応していました。
X Window Systemを終了させようとして、[Ctrl]+[Alt]+[Backspace]キーを押下しましたが、グレー画面は終了しませんでした。
ACアダプタを抜き差しするしか復旧方法がありませんでした。
[armadillo ~]# podman exec -ti rasp4B bash →正常終了 [container ~]# apt install xorg →正常終了 [container ~]#X vt7 -retro
モニタ一全面がグレーの画面から進まないことの原因として考えられることを教えてください。
at_shinya.koga
アットマークテクノの古賀です。
ahirataさん:
>ありがとうございます。
>コンテナの起動設定ファイルにadd_devices行を追加した後、podman_startを実行していませんでした。
>
>podman_startを実行したところ、コンテナ上にも/dev/tty7が存在するようになりました。
了解しました。ご確認有り難うございます。
>その上で、下記コマンドを実行したところ、モニタ一全面がグレーの画面に変わりましたが、その他の画面は表示されませんでした。
>また、マウスは反応していました。
>X Window Systemを終了させようとして、[Ctrl]+[Alt]+[Backspace]キーを押下しましたが、グレー画面は終了しませんでした。
>ACアダプタを抜き差しするしか復旧方法がありませんでした。
[armadillo ~]# podman exec -ti rasp4B bash →正常終了 [container ~]# apt install xorg →正常終了 [container ~]#X vt7 -retro
>
>モニタ一全面がグレーの画面から進まないことの原因として考えられることを教えてください。
X サーバーしか起動せず、クライアントを何も起動していないのが原因です。
gdm3 (GNOME Display Manager) などのウィンドウマネージャも X クライアントであり、何か X クライアントを動かさないと、全画面グレー表示されるだけの状態となります。
startx スクリプトを実行すれば、X サーバーと X クライアントを起動してくれますので、startx を実行してみてくださいませ。
ahirata
>startx スクリプトを実行すれば、X サーバーと X クライアントを起動してくれますので、startx を実行してみてくださいませ。
ありがとうございます。
startxを実行しました。
[armadillo ~]# podman exec -ti rasp4B bash →正常終了 [container ~]# apt install xorg →正常終了 [container ~]# startx
その結果、下記のような出力があり、エラー終了しました。XサーバーとXクライアントは起動しませんでした。
X.Org X Server 1.20.11 X Protocol Version 11, Revision 0 (途中省略) (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar 5 14:50:21 2025 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error : (EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or directory) ←/dev/tty7を設定しているが、なぜか/dev/tty0が表示されている (EE) (EE) Please consult the Teh X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. xinit : giving up xinit : unable to connect to X server: Connection refused xinit : server error Couldn't get a file descriptor referring to the console. [container ~]#
その後、「startx」ではなく「X vt7 -retro」を実行すると、全画面グレー表示になりました。
[container ~]#X vt7 -retro
startxの設定が悪いのでしょうか?
at_shinya.koga
アットマークテクノの古賀です。
X サーバーを直接起動していらした件ですが、2/18 のコメントで僕が紹介した X2 のマニュアルの説明が、そうなっていますね。ごめんなさい:
https://manual.atmark-techno.com/armadillo-x2/armadillo-x2_product_manu…
ahirataさん:
>>startx スクリプトを実行すれば、X サーバーと X クライアントを起動してくれますので、startx を実行してみてくださいませ。
>
>ありがとうございます。
>startxを実行しました。
[armadillo ~]# podman exec -ti rasp4B bash →正常終了 [container ~]# apt install xorg →正常終了 [container ~]# startx
>
>その結果、下記のような出力があり、エラー終了しました。XサーバーとXクライアントは起動しませんでした。
X.Org X Server 1.20.11 X Protocol Version 11, Revision 0 (途中省略) (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar 5 14:50:21 2025 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error : (EE) parse_vt_settings: Cannot open /dev/tty0 (No such file or directory) ←/dev/tty7を設定しているが、なぜか/dev/tty0が表示されている (EE) (EE) …
…
>startxの設定が悪いのでしょうか?
startx を引数無しで実行すると、/dev/tty0 が使われてしまいますので、次のように実行してみてください:
[container ~]# startx -- vt7 -retro
ahirata
at_ohsawa
2025年2月3日 15時51分
rpiのディスクイメージの構造がhowtoで想定していない状態のようです。
もともとのディスクイメージをどうやって作ったorどこからダウンロードしたものか
教えてもらえるでしょうか。
ツールを利用している場合はそのバージョンも教えてほしいです。