コグノスケ


2024年5月3日

ROCK 3Cの青色LED点滅を止める

目次: Arduino

ゲーミングマシンの流行により、最近のコンピュータは意味もなくビカビカ光って点滅しています。個人的にはマザーボードや電源が七色に光る意味が全く見出せません……。電気を無駄にしてる感があります。

しかし組み込み機器の場合は話が別です。画面出力やUARTなどが確認できる機器なら状態がわかりやすいですが、外部出力に乏しい機器は動いているかどうかよくわかりませんので、生存確認方法の1つとしてLEDを交互に光らせる(もしくは点滅させる)というのは現代でも割と見かける方法です。

先日購入したROCK 3Cも生存確認で青色LEDが点滅するようになっています。ドライバで実装しているようで点滅が鬱陶しいなら、

ROCK 3Cの青色LED点滅を止める
$ sudo rmmod ledtrig_heartbeat

とすると点滅が止まります。二度と点滅しなくて良ければ/etc/modules-load.d/modules.confを編集してledtrig-から始まる4行を全てコメントアウトすれば良いです。ただし青色LEDは消灯ではなく常時点灯になってしまいます。消灯させる方法は、

ROCK 3Cの青色LEDを消灯
# echo 0 > /sys/class/leds/user-led1/brightness

もっとスマートに消灯させる方法はあるんだろうか……?

編集者:すずき(2024/06/17 02:42)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2024年5月10日

SDIの一覧

聞かれてぱっと思い出せなかったのでSDI(Serial Digital Interface)の規格一覧をメモしておきます。

SDIはデジタル動画の送信に使われるインタフェースです。SMPTE(The Society of Motion Picture and Television Engineers)という団体が規格を定めています。英語圏だと「シンプティ」みたいに発音するらしいですが、日本では聞いたことないです。

  • SMPTE ST 259M: SD-SDI、SDTV画質(例: NTSC/PAL)、143/177/270/360Mbps
  • SMPTE ST 292M: HD-SDI、HDTV画質(例: 1080i59.94, 720p59.94)、1.485Gbps
  • SMPTE ST 424M: 3G-SDI、プログレッシブHD(例: 1080p59.94)、2.97Gbps
  • SMPTE ST 2081: 6G-SDI、4K解像度(例: 4K 29.97p)、6Gbps
  • SMPTE ST 2082: 12G-SDI、4K解像度(例: 4K 59.94p)、12Gbps

SMPTEの仕様書の一覧はSMPTEのサイト(Standards Index - Society of Motion Picture & Television Engineers)にあります。ST 2081は見つかりますけど、それ以前の古い規格は見当たらないですね?別のところにあるんでしょうか。

編集者:すずき(2024/05/18 03:18)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2024年5月13日

Docker pullするときにプロキシを使う

目次: 自宅サーバー

Dockerの設定はいつも忘れますね。メモしておきます。

企業内ネットワークなど、Docker pullでイメージをダウンロードしてくるときにプロキシを参照したいときがあります。systemdの設定で指定できるようです。

Docker.serviceのプロキシ設定

#/etc/systemd/system/docker.service.d/http-proxy.conf

[Service]
Environment="http_proxy=http://192.168.1.1:8080/"
Environment="https_proxy=http://192.168.1.1:8080/"

この設定ファイルが存在しないときは、ディレクトリと設定ファイルを作成してください。反映方法は、

docker.serviceの設定反映と再起動
# systemctl daemon-reload
# systemctl restart docker.service

確認方法は、

docker.serviceの設定確認
# systemctl status docker.service

docker.service - Docker Application Container Engine
    Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset>
    Drop-In: /etc/systemd/system/docker.service.d
             `- http-proxy.conf    ★Drop-Inの行が出現していればOK

設定ファイルの場所がややこしい以外はそんなに難しくないですね。

編集者:すずき(2024/05/18 03:02)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2024年5月15日

cntlmを経由してプロキシを使用する

目次: 自宅サーバー

プロキシのアドレスが拠点やゾーンによって異なる場合があります。プロキシを使用するサービスが1つならそのサービスの設定ファイルを書き換えれば良いのですが、サービスが複数ある場合は各サービスのプロキシ設定を全て書き換えて回る必要があって面倒です。

このようなときはcntlm(Cntlm Authentication Proxy - SourceForge.net)にてローカルにプロキシを置くと便利です。各サービスは常にcntlmをプロキシとして設定しておけば良く、cntlmの設定ファイルを書き換えるだけでプロキシ設定の変更に対応できます。

このときの通信経路は[各サービス] - [cntlm] - [プロキシ] - [インターネット]となります。

ちなみにcntlmは認証やトンネリングに対応している高機能なプロキシで、設定もたくさんあります。が、プロキシの中継をするだけなら設定は2行です。

cntlmの設定

#/etc/cntlm.conf

Proxy		192.168.1.1:8080

...

Listen		172.17.0.1:3128

反映方法は、

cntlmの設定反映と再起動
# systemctl restart cntlm.service

確認するときは、環境変数にcntlmのListenに指定したアドレスとポートを設定し、プロキシを必要とするソフトウェアが正常に動作するか見ると良いでしょう。

cntlmの設定確認方法
$ export http_proxy="172.17.0.1:3128"
$ export https_proxy="172.17.0.1:3128"

$ (httpを使用するコマンド、curlなどが動作することを確かめる)

各サービスのプロキシ設定も同様です。例えばDockerなら、

Docker.serviceのプロキシにcntlmを指定する
#/etc/systemd/system/docker.service.d/http-proxy.conf

[Service]
Environment="http_proxy=http://172.17.0.1:3128/"
Environment="https_proxy=http://172.17.0.1:3128/"

こんな感じです。Dockerのプロキシ設定、確認方法は以前(2024年5月13日の日記参照)紹介したのでそちらをご覧ください。

編集者:すずき(2024/05/18 03:02)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2024年5月16日

イマドキ?のlocale設定方法

目次: 自宅サーバー

Localeの設定方法は未だによくわかってないのですが、最近ROCK 3CのDebian 11 (bullseye)でLocaleを設定したときの方法をメモしておきます。

ロケールの作成と設定
# localedef -i /usr/share/i18n/locales/ja_JP -f UTF-8 /usr/lib/locale/ja_JP.UTF-8
# localedef --add-to-archive /usr/lib/locale/ja_JP.UTF-8
# localectl set-locale LANG=ja_JP.UTF-8

これで切り替わりました。作成、登録、選択という感じ?です。Cロケールに戻すときはLANG=C.UTF-8です。

タイムゾーンの設定方法

一緒に変えたくなるであろうタイムゾーンの設定方法も書いておきます。

タイムゾーンの設定
# timedatectl set-timezone Asia/Tokyo

作成や登録の手間はなく簡単です。UTCに戻すときはEtc/UTCと指定します。注意点として、

大文字小文字に注意
# timedatectl set-timezone asia/Tokyo
Failed to set time zone: Invalid or not installed time zone 'asia/Tokyo'

タイムゾーン名は大文字小文字を区別するのでTypoにご注意ください。私は最初asia/Tokyoと打っているのに気づかずエラーになって困惑しました……。

編集者:すずき(2024/05/21 01:23)

コメント一覧

  • hdkさん(2024/05/21 08:55)
    システム全体のlocale設定はDebian系ならdpkg-reconfigure localesでいけると思いますよ! 覚えやすいし公式Wikiにも載っています!

    タイムゾーンは公式WikiのTimeZoneChangesを見ると変更後にdpkg-reconfigure tzdataを実行するのが正しいっぽい? Asia/Tokyoの他にJapanというのもあります。
  • すずきさん(2024/05/21 11:41)
    あー、確かにdpkg-reconfigureの方が楽だし正規の手続きですね。locale-genの内部を見たら、localedefを使っているみたいでした。localectlは使っていないのかなあ。
open/close この記事にコメントする



2024年5月17日

TwitterがXに置換された

今日?あたりからtwitter.comにアクセスするとx.comにリダイレクトされるようになりました。twitter.comとの違いとしては、x.comはFirefoxにてTracking contentをブロックしているとこんなエラーが出て全く使えません。


Tracking contentをブロックしたときのx.comのエラー

エラーを回避するにはEnhanced Tracking ProtectionのException設定にx.comを追加します。


Tracking contentの設定変更

そんなにトラッキングしたいんですかね?x.comはイケてないな……。

ツイート内容の置換

Xは以前からTwitterという文字を滅ぼしたがっているようで、先月辺り(?)からツイートにあるtwitter.comをx.comに置換するようになりました。そのせいで下記のようにx.comとtwitter.comという文字が両方入っているニュースがおかしなことになっています。


twitter.comをx.comに置換したためにツイートと代替テキストが食い違う様子

しかも画像の代替テキストは置換が行われないため、ツイートと画像の代替テキストが食い違うおかしな現象まで発生しています。twitter.comというドメインを手放さない限り、どうせリダイレクトするのであれば一括置換する必要なかったんじゃないの……?手放したら手放したで悪用されまくると思いますし。

編集者:すずき(2024/05/18 20:34)

コメント一覧

  • hdkさん(2024/05/18 22:16)
    ドメインを変えたせいで別サイト扱いになってトラッキングプロテクションに引っ掛かるんですかねぇ。手元のFirefoxだとEnhanced Tracking ProtectionはStandardのまま、Exception追加しなくてもアクセスできています。
  • すずきさん(2024/05/19 03:41)
    Standardだと下記の設定になっているのでTracking Protectionが効いてないのかなと思います。
    Firefox blocks the following:
    - Social media trackers
    - Cross-site cookies in all windows
    - Tracking content in Private Windows ★★★★これ
    - Cryptominers
    - Fingerprinters

    私はCustomかつ、Tracking Protection: In all windowsにしているのでエラーになってしまうようです。Only in private windowsにするとx.comのエラーは消えます。
  • hdkさん(2024/05/19 07:45)
    なるほど、そういうことなんですね。ExceptionといってもせめてStandardにはしたいところですかね...
  • すずきさん(2024/05/20 13:16)
    そうですねえ、普通はStandardなので何も問題ないと思います。私もChromeやEdgeは特に何も設定変更してません。
    メインブラウザのFirefoxだけ一番厳しい設定にして、CookieやTrackingを全部ブロックしたときの色々な挙動(今回の日記の話とか)を観察してます。
open/close この記事にコメントする



2024年5月19日

Yocto - まとめリンク

目次: Yocto

編集者:すずき(2024/06/04 00:44)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2024年5月21日

Linux 6.1からLinux 6.6に手抜き更新したらハマった

目次: 自宅サーバー

Linux Kernelのlongtermバージョンが代替わりしてからしばらく経ちますが、更新をサボりにサボっていました。重い腰を上げて自宅サーバーのLinux 6.1をLinux 6.6に更新したところ、起動しなくなりました。悲しい。

Linux 6.1に戻せば起動しますからHWの故障などではないです。Kernelコンフィグが悪さをしていそうで、ドライバの有無を色々疑ったんですが、結果的にはCONFIG_UNIXがtristate(設定値にy/n/mを取れる)からbool(設定値にy/nを取れる)が原因でした。こんな経緯で起動しなくなったと思われます。

  • ある時点(※)でCONFIG_UNIXをmにできなくなった
  • menuconfigはCONFIG_UNIX=mにできないので、CONFIG_UNIX=nにする
  • Unixドメインソケットが使えないKernelが爆誕
  • 何ひとつ(systemdすら)起動できない

CONFIG_UNIX=mにできなくなったことなんて知りませんでした。気づけたのはmake oldconfigのおかげです。

make oldconfigが出すエラー
# make oldconfig

.config:917:warning: symbol value 'm' invalid for UNIX    ★★エラーが出ている★★
*
* Restart config...
*
*
* Configure standard kernel features (expert users)
*
Configure standard kernel features (expert users) (EXPERT) [N/y/?] n
  Load all symbols for debugging/ksymoops (KALLSYMS) [Y/?] y
    Test the basic functions and performance of kallsyms (KALLSYMS_SELFTEST) [N/y/?] (NEW)

私がいつもやっている手順ですと

  • 古いLinux Kernelのconfigを新しいLinux Kernelにコピー
  • make menuconfig

こんな感じなので、最初はCONFIG_UNIX=mに対するエラーに全く気づいていませんでした。もしmake oldconfigが存在しなかったら迷宮入りしていたと思います。

どこで変わったのか?

せっかくなので仕様が変更されたポイントを調べます。git annotateでnet/unix/Kconfigを見て、変更のもとになったコミットを調べます。コミットログは下記です。

CONFIG_UNIXがtristateからboolになったコミット
commit 97154bcf4d1b7cabefec8a72cff5fbb91d5afb7b
Author: Alexander Mikhalitsyn <alexander@mihalicyn.com>
Date:   Thu Jun 8 22:26:28 2023 +0200

    af_unix: Kconfig: make CONFIG_UNIX bool

    Let's make CONFIG_UNIX a bool instead of a tristate.
    We've decided to do that during discussion about SCM_PIDFD patchset [1].

    [1] https://lore.kernel.org/lkml/20230524081933.44dc8bea@kernel.org/

...以下略...

このコミットが本線に取り込まれたのはLinux 6.5みたいです。

コミットが取り込まれたバージョン探し
$ cd linux
$ git log v6.4...v6.5 | grep 97154bcf4d1b7

commit 97154bcf4d1b7cabefec8a72cff5fbb91d5afb7b

ちなみにLinux 6.1の次のLongterm kernelはLinux 6.6ですから、今日でなくてもいつか私はこの問題にハマる運命だったと言えましょう……。

編集者:すずき(2024/05/23 23:19)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2024年5月26日

JTSA Unlimited大会参加2024

目次: 射的

JTSA Unlimitedの大会に参加しました。去年は選手登録をし忘れる痛恨のミスで参加できませんでしたが、今年は忘れずに登録&参加できました。

「木」ステージだけ全然ダメダメでしたが全体的に良い調子だったためか、結果は76.75秒で自己ベストを更新しました。実は大会で自己ベストが出る人は練習不足という話もあったりしますが、そもそもガチ勢じゃないしあまり気にしても仕方ないでしょう。


JTSA Unlimited練習会+大会の記録

練習会の記録を見ても80秒を切るか切らないか……程度でフラフラしていてあまり早くなっている感じはしません。来月からはLimitedが始まるのでゆるゆると続けていくとしましょう。

編集者:すずき(2024/06/22 17:16)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2024年5月27日

Hello Yocto

目次: Yocto

Yoctoのメモです。なおYoctoのバージョンはScarthgap(5.0.1)とします。他のバージョンだと当てはまらない場合があります。

買ったのに使ってないZybo Z7-20を使おうと思い立ったものの、XilinxのARMコアでLinuxを動かすときはPetaLinuxというYoctoの改造ツールを使うらしいです。ベースとなったYoctoもbitbakeコマンドを実行する程度の知識しかないのでPetaLinuxと並行してYoctoも調べたいと思います。

YoctoのQuick Build(Yocto Project Quick Build - The Yocto Project)なるドキュメントによればビルド方法はたったこれだけです。

Yoctoのビルド方法
$ source oe-init-build-env
$ bitbake core-image-sato

正常に動いているうちは良いですが、まともに動かなくてデバッグするときはYoctoの超複雑なシステムが災いをもたらします。bitbakeって何?どこを見たら良いの?全くわかりません。

次回からYoctoを破壊&直しながら、Yoctoを構成する要素を調べていこうと思います。

編集者:すずき(2024/06/03 23:46)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2024年5月28日

Yoctoのセットアップスクリプトとビルドディレクトリ

目次: Yocto

Yocto Scarthgap(5.0.1)のメモです。Yoctoの使い方は以下の2手でした。

Yoctoのビルド方法
$ source oe-init-build-env
$ bitbake core-image-sato

今回は最初のsource oe-init-build-envを調べます。Yoctoのドキュメント(Source Directory Structure - The Yocto Projectの4.1.10 oe-init-build-env)によると、OpenEmbeddedのビルド環境をセットアップし、ビルドディレクトリを作成するスクリプトです。

コードを読んで依存関係を調べるのは時間が掛かるし辛いので、簡易的な調査手法として全ファイルを消してエラーを観察し、エラーの原因となるファイルを復活させて次ステップに進める手法で調べます。調べた結果oe-init-build-envを実行するには、

  • scripts/oe-buildenv-internal
  • scripts/oe-setup-builddir

が必要です。2つ目のoe-setup-builddirスクリプトによりビルドディレクトリが作成されます。次回はビルドディレクトリはどこから来るのか?を紹介します。

編集者:すずき(2024/06/04 00:02)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2024年5月29日

Yoctoのビルドディレクトリとテンプレートディレクトリ

目次: Yocto

Yocto Scarthgap(5.0.1)のメモです。Yoctoの使い方は以下の2手でした。

Yoctoのビルド方法
$ source oe-init-build-env
$ bitbake core-image-sato

テンプレートディレクトリを元にしてビルドディレクトリ(正確にはbuild/confディレクトリ)を作成します。Yoctoのドキュメント(Creating a Custom Template Configuration Directory - The Yocto Project)によると、テンプレートディレクトリのパスはTEMPLATECONFという環境変数で指定できるとあります。

もし何も設定しないと.templateconfファイル内に書かれた設定をデフォルトの設定として使います。何が書いてあるかというとこんな感じです。

テンプレートディレクトリの位置が書かれた.templateconfファイル
$ less .templateconf

# Template settings
TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf/templates/default}

テンプレートディレクトリの中にあるファイルはこんな感じ。

テンプレートディレクトリ内のファイル一覧
$ ls meta-poky/conf/templates/default/

bblayers.conf.sample  conf-summary.txt   local.conf.sample.extended
conf-notes.txt        local.conf.sample  site.conf.sample

テンプレートファイルからビルドディレクトリを作成する際は、単なるコピーではなく##OEROOT##のような変数をパスに展開した内容がコピーされます。下記はOEROOTの展開例です。

テンプレートファイルの展開例

$ diff -u meta-poky/conf/templates/default/bblayers.conf.sample build/conf/bblayers.conf

--- meta-poky/conf/templates/default/bblayers.conf.sample       2024-05-30 13:17:58.926938821 +0900
+++ build/conf/bblayers.conf    2024-05-31 14:58:51.741378271 +0900
@@ -6,7 +6,7 @@
 BBFILES ?= ""

 BBLAYERS ?= " \
-  ##OEROOT##/meta \
-  ##OEROOT##/meta-poky \
-  ##OEROOT##/meta-yocto-bsp \
+  /home/katsuhiro/share/projects/oss/poky/meta \
+  /home/katsuhiro/share/projects/oss/poky/meta-poky \
+  /home/katsuhiro/share/projects/oss/poky/meta-yocto-bsp \
   "

ぱっと見だとテンプレートディレクトリの場所はどこでも良さそうですがそんなことはありません。テンプレートがpoky/meta-poky/conf/templates/defaultだとしたら、

テンプレートディレクトリを配置できる場所の条件
poky/meta-poky/conf/templates/
の2つ上のディレクトリの下のconf/layer.confすなわち、
poky/meta-poky/conf/layer.conf
が必要です。

一言で言えばテンプレートがあるディレクトリの2つ上(Yoctoを例にすればmeta-poky)にconf/layer.confが存在しないとエラーになりますという意味ですが、そんな制約知らんわー……。

ちなみにテンプレートディレクトリを作成する場合は手で作成するのではなく、bitbake-layers save-build-confコマンドを使用するそうです(ドキュメント参照)。

ビルドディレクトリの中身

セットアップディレクトリによって、ビルドディレクトリbuildが生成され、BBPATHとBUILDDIRがビルドディレクトリを指すようになります。ビルドディレクトリ下には、テンプレートディレクトリからbuild/confディレクトリが生成されます。ファイルの中身を見ると、

ビルドディレクトリ内の設定ファイルの内容
#### build/conf/bblayers.conf

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /home/katsuhiro/share/projects/oss/poky/meta \
  /home/katsuhiro/share/projects/oss/poky/meta-poky \
  /home/katsuhiro/share/projects/oss/poky/meta-yocto-bsp \
  "


#### build/conf/conf-notes.txt

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal
    core-image-full-cmdline
    core-image-sato
    core-image-weston
    meta-toolchain
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86-64'.

Other commonly useful commands are:
 - 'devtool' and 'recipetool' handle common recipe tasks
 - 'bitbake-layers' handles common layer tasks
 - 'oe-pkgdata-util' handles common target package tasks


#### build/conf/conf-summary.txt

This is the default build configuration for the Poky reference distribution.


#### build/conf/local.conf

(設定項目がたくさんある、ここでは省略)


#### build/conf/templateconf.cfg

meta-poky/conf/templates/default

セットアップスクリプトの時点でもシステムの複雑さの片鱗が見え隠れしています。まともにコードで追うのを諦めて正解でした。そんなことしていたら日が暮れてしまいます。今回登場したファイル、ディレクトリは、

  • poky/oe-init-build-env
  • poky/.templateconf
  • poky/meta-poky/conf/templates/default/*
  • poky/meta-poky/conf/layer.conf
  • poky/build/conf/*

こんなもんでしょうか。次回はいよいよbitbakeに突入です。

編集者:すずき(2024/06/04 00:09)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2024年5月30日

Bitbakeのレイヤー

目次: Yocto

Yocto Scarthgap(5.0.1)のメモです。Yoctoの使い方は以下の2手でした。

Yoctoのビルド方法
$ source oe-init-build-env
$ bitbake core-image-sato

今回はBitbakeです。前回同様、コードを読んで依存関係を調べるのは大変時間が掛かるので、簡易的な調査手法として全ファイルを消してエラーを観察し、エラーの原因となるファイルを復活させて次ステップに進める手段を用います。

このbitbakeというコマンドはPython 3で実装されていて、poky/bitbake/lib/bb/parse以下にあるスクリプトと連携して動作しています。bitbakeのエラー曰く、bblayers.confのBBLAYERS変数に列挙されているmetaなんとかディレクトリ下にconf/layer.confが必要です。

ここで出てくるmeta-なんとかというディレクトリはOpenEmbeddedの概念でレイヤーと呼ばれます。レイヤー = レシピの集合体、レシピ = 何らかのソフトウェアをビルド、構成する方法を記述したものです。Yoctoは独自の単語が多いので、公式ドキュメントの用語集(Yocto Project Terms - The Yocto Project)が参考になります。

レイヤーの一覧(BBLAYERS)の定義
# build/conf/bblayers.conf

BBLAYERS ?= " \
  /home/katsuhiro/share/projects/oss/poky/meta \
  /home/katsuhiro/share/projects/oss/poky/meta-poky \
  /home/katsuhiro/share/projects/oss/poky/meta-yocto-bsp \
  "
レイヤーの設定ファイル(layer.conf)が見つからないエラー
$ bitbake core-image-sato

ERROR: Unable to parse /home/katsuhiro/share/projects/oss/poky/bitbake/lib/bb/parse/__init__.py
Traceback (most recent call last):
  File "/home/katsuhiro/share/projects/oss/poky/bitbake/lib/bb/parse/__init__.py", line 145, in resolve_file(fn='/home/katsuhiro/share/projects/oss/poky/meta-poky/conf/layer.conf', d=<bb.data_smart.DataSmart object at 0x7fb271c5bc10>):
         if not os.path.isfile(fn):
    >        raise IOError(errno.ENOENT, "file %s not found" % fn)

FileNotFoundError: [Errno 2] file /home/katsuhiro/share/projects/oss/poky/meta-poky/conf/layer.conf not found

3つのレイヤーのうち、テンプレートディレクトリを持っているmeta-pokyにはmeta-poky/conf/layer.confが存在します(でないとoe-setup-builddirのチェックに引っかかるはず)。残りの2つmeta/conf/layer.confとmeta-yocto-bsp/conf/layer.confを元に戻して実行します。

ちなみにOpenEmbeddedのサイトで利用可能なレイヤーの一覧(OpenEmbedded Layer Index)を確認できます。便利ですね。

話がそれましたがmeta/conf/layer.confとmeta-yocto-bsp/conf/layer.confファイルを戻してbitbakeを実行すると、

Bitbakeのスクリプトが見つからないエラー
$ bitbake core-image-sato

ERROR: Unable to parse /home/katsuhiro/share/projects/oss/poky/bitbake/lib/bb/parse/ast.py
Traceback (most recent call last):
  File "/home/katsuhiro/share/projects/oss/poky/bitbake/lib/bb/parse/ast.py", line 290, in PyLibNode.eval(data=<bb.data_smart.DataSmart object at 0x7f4f4d45bf50>):
             try:
    >            bb.utils._context[self.namespace] = __import__(self.namespace)
                 toimport = getattr(bb.utils._context[self.namespace], "BBIMPORTS", [])
ModuleNotFoundError: No module named 'oe'

エラーを見るとmeta/lib/oeが無いと言っているのでこれも元に戻しましょう。oeはたぶんOpenEmbedded(※)の略ですね。

(※)bitbakeはOpenEmbeddedのビルドツールで、PokyはOpenEmbeddedのリファレンス(reference distribution)とされています。YoctoはPokyを開発しているプロジェクト名です。Yocto, Poky, OpenEmbeddedの関係はbitbakeのヘルプとかYoctoのヘルプで説明されています(1 Overview - Bitbake dev documentationTechnical Overview - The Yocto Project)。

次のエラーを見るとbitbake.confがないと言われます。

bitbake.confが見つからないエラー
$ bitbake core-image-sato

ERROR: Unable to parse /home/katsuhiro/share/projects/oss/poky/bitbake/lib/bb/parse/__init__.py
Traceback (most recent call last):
  File "/home/katsuhiro/share/projects/oss/poky/bitbake/lib/bb/parse/__init__.py", line 139, in resolve_file(fn='conf/bitbake.conf', d=<bb.data_smart.DataSmart object at 0x7faff2cc38d0>):
             if not newfn:
    >            raise IOError(errno.ENOENT, "file %s not found in %s" % (fn, bbpath))
             fn = newfn
FileNotFoundError: [Errno 2] file conf/bitbake.conf not found in /home/katsuhiro/share/projects/oss/poky/meta-poky:/home/katsuhiro/share/projects/oss/poky/build:/home/katsuhiro/share/projects/oss/poky/meta:/home/katsuhiro/share/projects/oss/poky/meta-yocto-bsp

指摘された通りmeta/conf/bitbake.confを元に戻します。他のレイヤー(metaなんとかディレクトリ)にはbitbake.confがありません。1個しかないものなのかな?bitbake.confは他の*.confを大量にrequire/includeしていて同じく見つからないというエラーになりますので、*.confファイルも元に戻します。

今回登場したファイル、ディレクトリは、

  • poky/meta/conf/layer.conf
  • poky/meta-yocto-bsp/conf/layer.conf
  • poky/meta/conf/bitbake.conf
  • poky/meta/conf/*.conf
  • poky/meta/lib/oe

こんなところです。次回はクラスを見ます。

編集者:すずき(2024/06/04 00:35)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2024年5月31日

Bitbakeのクラス

目次: Yocto

Yocto Scarthgap(5.0.1)のメモです。前回同様、コードを読んで依存関係を調べるのは大変時間が掛かるので、簡易的な調査手法として全ファイルを消してエラーを観察し、エラーの原因となるファイルを復活させて次ステップに進める手段を用います。

引き続きBitbakeを実行してエラーを見て、足りないファイルを元に戻していくという方法で各パーツや設定の動作を見ます。

クラスが見つからないエラー
$ bitbake core-image-sato

ERROR: Unable to parse /home/katsuhiro/share/projects/oss/poky/bitbake/lib/bb/parse/parse_py/BBHandler.py
Traceback (most recent call last):
  File "/home/katsuhiro/share/projects/oss/poky/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 71, in inherit(files=['base'], fn='configuration INHERITs', lineno=0, d=<bb.data_smart.DataSmart object at 0x7f7a85863c50>, deferred=False):
             if not os.path.exists(file):
    >            raise ParseError("Could not inherit file %s" % (file), fn, lineno)

bb.parse.ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass

なにやらclassesというディレクトリと、*.bbclassというファイル名が出てきました。これはクラス(Classes - The Yoct Project)といってレシピ間で処理を共有するための仕組みです。ドキュメントによると3種類あるそうです。

  • classes-recipe/ - レシピに個別に継承されることを意図したクラス
  • classes-global/ - グローバルに継承されることを意図したクラス
  • classes/ - 使用コンテキストが明確に定義されていないクラス

Yoctoのクラス(*.bbclassファイル)は全部meta/classes-globalかと思ったらそうでもなく、一部のクラスはmeta/classesディレクトリに配置されています。

エラーメッセージはmeta/classes/base.bbclassがないと言っていますが、ファイルの実際の在処はmeta/classes-global/base.bbclassです。どういうことでしょう?Bitbakeのソースコードを見ると、

Bitbakeのクラスの検索処理

# bitbake/lib/bb/parse/parse_py/BBHandler.py

def inherit(files, fn, lineno, d, deferred=False):
    __inherit_cache = d.getVar('__inherit_cache', False) or []
    #if "${" in files and not deferred:
    #    bb.warn("%s:%s has non deferred conditional inherit" % (fn, lineno))
    files = d.expand(files).split()

    #★★files配列には'base'だけが入っている★★
    for file in files:
        classtype = d.getVar("__bbclasstype", False)    #★★classtype = global★★
        origfile = file

        #★★classes-global/base.bbclassがなければ、classes/base.bbclassを探す★★
        for t in ["classes-" + classtype, "classes"]:
            file = origfile
            #★★パスと拡張子を連結★★
            if not os.path.isabs(file) and not file.endswith(".bbclass"):
                file = os.path.join(t, '%s.bbclass' % file)

            if not os.path.isabs(file):
                bbpath = d.getVar("BBPATH")
                abs_fn, attempts = bb.utils.which(bbpath, file, history=True)
                for af in attempts:
                    if af != abs_fn:
                        bb.parse.mark_dependency(d, af)
                if abs_fn:
                    file = abs_fn

            if os.path.exists(file):
                break

        #★★どちらもないと最後に探したパス名でエラーメッセージを出してくる★★
        if not os.path.exists(file):
            raise ParseError("Could not inherit file %s" % (file), fn, lineno)  #★★エラーメッセージを発生させる行★★

Bitbakeはclasses-globalとclassesの両方を探し、どちらにも目当てのクラスがない場合は最後に探したパス名でエラーメッセージを出力します。従ってエラーメッセージのパスは必ずmeta/classesになります。

今回登場したファイル、ディレクトリは、

  • poky/meta/classes-global/base.bbclass
  • poky/meta/classes-global/*.bbclass
  • poky/meta/classes/*.bbclass

こんなとこ。次回はディストリビューションを見ます。

編集者:すずき(2024/06/04 00:43)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報