- 投稿日:2020-06-23T23:34:48+09:00
あらためてEPELリポジトリの使い方をまとめてみた
1. はじめに
RHEL系ディストリビューションにおける、拡張パッケージのリポジトリ「EPEL」を使っている人は多いだろう。筆者もこれまでの記事で何度か紹介してきた。ところがクラウドでは状況が微妙に異なる。そこで使い方をまとめることにした。
1-1. TL;DR
- クラウドでは、デフォルトで有効になっていることや、独自のインストールコマンドが提供されていることがある
- 記事で毎回EPELの使い方を説明するのは無駄
1-2. 前提条件
- RHEL系Linuxディストリビューション。FedoraやCentOS、Amazon Linux、Oracle Linuxなど
2. EPELとは
EPELを使う手順は簡単だ。すぐにインストールしたいときは「3. EPELリポジトリを有効にする」に進んでほしい。ここではEPELの概要や使用するうえでの注意事項を説明する。
2-1. もっとも有名なサードパーティー・リポジトリEPEL
EPEL(Extra Packages for Enterprise Linux)は、Fedoraプロジェクトの有志がビルドした、Red Hat Enterprise Linux (RHEL) 系Linuxディストリビューション向けオプションパッケージ群だ。LinuxのメディアやYumリポジトリに含まれないパッケージ入手先の第1候補になる。
EPELのように、ディストリビューション本家以外が提供するリポジトリを「サードパーティー・リポジトリ」と呼ぶ。EPEL以外にも、以下のリポジトリも有名である。
2-2. なぜサードパーティー・リポジトリが必要か?
理由は簡単で「使いたいアプリケーションが標準のYumリポジトリに含まれていない」もしくは「含まれていてもバージョンが古い」からだ。これはディストリビューションのサポート上の理由だ。
- ディストリビューションベンダーは製品をサポートする責任があるので、標準リポジトリに含めるパッケージを制限している
- 互換性の問題で、同一メジャーバージョン内で新しいバージョンを取り入れられない
これらの問題は、RHEL7までのSoftware Collections(SCL)や、RHEL8のAppStreamで改善するが、すべての問題が解決するわけではない。
2-2-1. ソースからインストールする?
これらの問題が起きたときソースからビルドする人もいるだろう。ソースコードからのインストールは否定しないが、パッケージ管理ステムのメリットが損なわれる。十分な理由のあるときだけに限ったほうがいいだろう。
ソースからビルドしたときのデメリット
- 依存関係を保ったシステム管理が難しくなる
- ソースRPMからビルドしたバイナリRPMはサポート対象外になる
2-2-2. 互換性の話
以下の表は、RHELバージョンごとのkernelとglibcのバージョンをまとめたものだ。同一メジャーバージョン内では、アップデートパッケージを適用してもパッケージのバージョンは変わらない。
ディストリビューション kernel glibc RHEL6 2.6.32 2.12 RHEL7 3.10.0 2.17 RHEL8 4.18.0 2.28 Amazon Linux 2 4.14 2.26 RPMパッケージは以下のように命名される。kernelやglibcなどのコアコンポーネントの場合、
yum update
を実行して変わるのはバージョン以降に付与したリリース番号である。
ここまでしつこく書く理由は、kernelやglibcなどのコアコンポーネントは、アプリケーションの動作保証で極めて重要だからだ。だから出どころの分からない野良リポジトリを使ってはいけないし、RHEL6用のRPMパッケージをRHEL7にインストールするような強引なことはしてはいけない。
余談
筆者が経験したホラーストーリーがある。とある障害の支援でRHEL6の設定を確かめていたときの出来事だ。いくつかの基本コマンドが動かない。おかしいと思い、以下のコマンドでRed Hat以外のパッケージを探すと、たくさん出てきた。VenderがRedHat以外のパッケージを表示するコマンドrpm -qa --qf "%{name} %{vendor}\n" | grep -v "Red Hat"それもglibcなどのコアコンポーネントがFedoraやScientific Linuxになっている。それもリリース番号違いでなくバージョン番号違い。本来インストールできないものを
nodeps
やforce
でインストールしたようだ。そんな強引なことをしたら、正常動作しなくて当然だ。逆に動いていたことが不思議でならない。3. EPELリポジトリを有効にする
EPELを使用するには
epel-release
パッケージをインストールすればよい。ただし使用するクラウドサービスやLinuxディストリビューションによって以下の注意事項がある。EPELのWebサイトも見てほしい。
- RHEL7では
optional
リポジトリやextras
リポジトリを有効にする必要がある- RHEL8では
codeready-builder
リポジトリを有効にする必要がある- AWSのAmazon Linux 2ではEPELを有効にする専用のコマンドがある
- Oracle Cloud InfrastructureのOracle Linux 7では、専用のEPELリポジトリがデフォルトで有効になっている
3-1. EPELを有効にする(基本)
「クラウドでRHELやCentOSを使うとき」や「オンプレミス環境」では
epel-release
をインストールする。これが基本になる。8系Linux OS
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y7系Linux OS
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y6系Linux OS
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm -y3-2. EPELを有効にする(AWS)
Amazon Linux 2ではEPELを有効にする専用のコマンドが用意されている。AWSでもRHELやCentOSでは、前述の方法を利用する。
sudo amazon-linux-extras install epelインストールに成功すると「amzn2extra-epel」と「epel」リポジトリが追加される。
$ yum repolist enabled repo id repo name status amzn2-core/2/x86_64 Amazon Linux 2 core repository 19791 amzn2extra-docker/2/x86_64 Amazon Extras repo for docker 28 amzn2extra-epel/2/x86_64★ Amazon Extras repo for epel 1 epel/x86_64★ Extra Packages for Enterprise Linux 7 - x86 13141+192 repolist: 32961amzn2extra-epelリポジトリのパッケージ数が1なのが気になる。調べてみるとepel-releaseだけが含まれていた。
repoファイルの定義を確認すると、EPELのミラーサイトを参照しており、クラウド内にAWS独自のミラーサイトがあるわけではない。ログを確認するとcloudfrontから取得している。
/etc/yum.repos.d/epel.repo[epel] name=Extra Packages for Enterprise Linux 7 - $basearch #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch★ミラーサイトを取得 failovermethod=priority3-2. EPELを有効にする(Oracle Cloud Infrastructure)
Oracle Cloud InfrastructureのOracle Linux 7では「ol7_developer_EPEL」という専用のEPELリポジトリが用意してある。そのため追加作業は不要だが、他のOSでは前述の方法を利用する。
EPELリポジトリが有効になっているか、次のコマンドで確認するといいだろう。
$ yum repolist repo id repo name status ol7_UEKR5/x86_64 Latest Unbreakable Enterprise Kernel Rele 217 ol7_addons/x86_64 Oracle Linux 7Server Add ons (x86_64) 433 ol7_developer/x86_64 Oracle Linux 7Server Development Packages 1349 ol7_developer_EPEL/x86_64★これ Oracle Linux 7Server Development Packages 32336 ol7_ksplice Ksplice for Oracle Linux 7Server (x86_64) 7356 ol7_latest/x86_64 Oracle Linux 7Server Latest (x86_64) 18986 ol7_oci_included/x86_64 Oracle Software for OCI users on Oracle L 321 ol7_optional_latest/x86_64 Oracle Linux 7Server Optional Latest (x86 13984 ol7_software_collections/x86_64 Software Collection Library release 3.0 p 14564 repolist: 89546repoファイルの定義を確認すると、リージョンごとに用意したOracle独自のEPELを参照している。
/etc/yum.repos.d/oracle-epel-ol7.repo[ol7_developer_EPEL] name=Oracle Linux $releasever Development Packages ($basearch) baseurl=http://yum$ociregion.oracle.com/repo/OracleLinux/OL7/developer_EPEL/$basearch/ol7_developer_EPELからインストールした
pwgen
パッケージを確認すると、ビルドホスト(Build Host)やベンダ(Vendor)が「fedora」ではない。そのためEPELからソースパッケージを取得して再ビルドしていることが分かる。$ rpm -qi pwgen Name : pwgen Version : 2.08 Release : 1.el7 ★中略 Source RPM : pwgen-2.08-1.el7.src.rpm Build Date : Tue Aug 14 22:24:07 2018 Build Host : x86-ol7-builder-01.us.oracle.com ★ Relocations : (not relocatable) Vendor : Oracle America ★ URL : http://sf.net/projects/pwgen Summary : Automatic password generation ★以下省略重要
「EPELからソースパッケージを取得してビルド」という手順を踏んでいることから、EPELとol7_developer_EPELは厳密には同じバイナリではない。またバージョン等のタイムラグの可能性がある。依存性などの原因でol7_developer_EPELにあるパッケージのインストールに失敗するときは、EPELに切り替えてみよう。
4. さらなるEPELの使いこなし
4-1. EPELの有効化/無効化を切り替える
EPELに限らず追加のリポジトリを使用するときは、「常時有効にする」「一時的に有効にする」の二通りの方法がある。EPELを使い始めたら常時有効にするのが一般的だが、EPELのパッケージを明示的に区別したいときは「一時的に有効にする」ことで区別できる。
常時有効にする
yum repolist
で表示されるときは有効になっている。またrepoファイルはenabled=1
になっている。一時的に有効にする
この方法ではEPELを無効化しておき、必要なときだけ有効化する。
- EPELを無効化する。これでyumを実行してもEPELのパッケージは利用できない。
sudo yum-config-manager --disable epel2.EPELにあるパッケージをインストール/アップデートするときだけ
--enablerepo
オプションで有効化する。sudo yum --enablerepo=epel install <パッケージ名>4-2. トラブルシュート
余力のあるとき執筆予定
5. まとめ
- 標準リポジトリにないパッケージがあるときはEPELを探そう
- 野良リポジトリは使わないこと。使うときは人柱覚悟で
- RPMパッケージの依存性を崩すような強引なことはしないこと
- AWSではEPELを有効にする独自コマンドが提供されている
- Oracle Cloud InfrastructureのOracle Linux 7では独自のEPELリポジトリが提供されている
- 投稿日:2020-06-23T22:30:01+09:00
gcrypto20が原因でHash Sum mismatchになる話
はじめに
Virtual Box 上の Kali 2020.2 で apt-get update をしたら
Hash Sum mismatch
が出てハマってしまいました。
解決策として試したのは以下の3つの方法ですが、どれも同じようにハッシュのエラーが出てしまい、解決に至れませんでしたが、とある方法で試したところ、解決できたので備忘録として残しておきます。試してダメだったのは以下の方法です。
解決策①
$ sudo apt-get update --fix-missing解決策②
$ sudo apt-get clean または sudo rm -rf /var/lib/apt/lists/* $ sudo apt-get update解決策③
/etc/apt/sources.list
の設定ファイルを編集して、レポジトリのURLを
http://mirrors.ocf.berkeley.edu/kali kali-rolling main non-free contrib
に変更してからapt-get update
解決策
では最終的になにが原因だったのかというと、ヒントはHash値がMD5Sumのみが一致しているところにありました。
$ sudo apt-get update Get:1 http://linux3.yz.yamagata-u.ac.jp/pub/linux/kali kali-rolling InRelease [30.5 kB] Get:2 http://linux3.yz.yamagata-u.ac.jp/pub/linux/kali kali-rolling/main amd64 Packages [16.6 MB] Err:2 http://linux3.yz.yamagata-u.ac.jp/pub/linux/kali kali-rolling/main amd64 Packages Hash Sum mismatch Hashes of expected file: - Filesize:16590427 [weak] - SHA256:00ccf318db598c4ddcd7094d28442cdb30088ab7de8cff6c0294de484a102146 - SHA1:12776612134b22e45ffd84538bcc493c87e881a4 [weak] - MD5Sum:b9db76fb5ce9653b1d721068963a1787 [weak] Hashes of received file: - SHA256:4d733b1f1ead1ce850dbd4ff906a1eb959380b181afb6eba0b9898652f58a2a1 - SHA1:b14761cbb2748365e608bbd57db3f1c41be04a53 [weak] - MD5Sum:b9db76fb5ce9653b1d721068963a1787 [weak] - Filesize:16590427 [weak] Last modification reported: Tue, 23 Jun 2020 12:03:38 +0000 Release file created at: Tue, 23 Jun 2020 12:04:33 +0000どうやら新しいLinuxで使用されている
gcrypto20
が原因でSHA256やSHA1のハッシュ値が異なってしまうようです。
参考に載せたサイトをもとに以下の手順で解決することができました。(心から感謝です、、、!)$ sudo bash # mkdir /etc/gcrypt # echo all >> /etc/gcrypt/hwf.denyこの設定を施した後に
$ sudo apt-get updateでいけました!!
参考
- 投稿日:2020-06-23T22:09:46+09:00
Macを新調したらBashがZshになっていた
Macを新調したらbashがzshになっていた
bashとかzshってのはシェル(shell)の一種らしい
shellってなんだ
shellはOSと対話するためのインターフェスを提供するソフトウェアのこと。
ユーザーからのコマンドを受け付けてOSの中核であるカーネルとやり取りして、カーネルのプログラムを呼び出す。
カーネルはアプリケーションの動作で使われるリソースを管理してます。つまりshellはユーザーが叩いたコマンドをカーネルがわかるように解釈してくれるソフトウェア。
bashとzsh
shellについてはなんとなくわかったのでこの二つについて。
zshはbashの上位互換??
いくつか調べてみたがこのように書いてあるページが多かった。
Zshの何がいいの?
・軽量
・カスタマイズが可能
・bashやtcsh, kshのいいとこ取りをしたシェル
・補完機能がすごい!
・機能が豊富こんな感じでzshの特徴がなんとなくわかった。
そもそもshellやカーネルについてもっと勉強するべきだな...
本日は以上です。
- 投稿日:2020-06-23T15:32:49+09:00
個人的 Ubuntu & WSL2セットアップまとめ
WSL2のセットアップ
https://qiita.com/momomo_rimoto/items/51d533ae9529872696ce
GUI関係で必要なら
https://qiita.com/momomo_rimoto/items/2841f1f15d364c2377a1
Chromeを入れる
https://qiita.com/develop/items/350f5487b4825d716d9d
sudo sh -c 'echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google-chrome.list' sudo wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add - sudo apt update sudo apt install google-chrome-stable日本語化
wsl(2)のみ。シンボリックリンクはるという手段。
https://nakomii.hatenablog.com/entry/wsl_ubuntuアップデートするなら
Ubuntu共通
sudo apt update sudo apt --only-upgrade install google-chrome-stablesudo ln -s /mnt/c/Windows/Fonts /usr/share/fonts/windows sudo fc-cache -fvGSuiteのGoogleドライブのマウント
https://qiita.com/cabbage_lettuce/items/c4544b3e5cd28caf04bc
sudo add-apt-repository ppa:alessandro-strada/ppa sudo apt-get update sudo apt-get install google-drive-ocamlfuse-bash: add-apt-repository: コマンドが見つかりません
のときは
sudo apt install software-properties-common認証。これまでにChromeかFirefoxなどをいれておく
google-drive-ocamlfuseマウント
mkdir ~/google-drive google-drive-ocamlfuse /home/ubuntu/google-drive
アンマウント
fusermount -u /home/ubuntu/google-drive
Pythonを入れる
https://qiita.com/ysdyt/items/5008e607343b940b3480
git clone https://github.com/pyenv/pyenv.git ~/.pyenv echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc echo 'eval "$(pyenv init -)"' >> ~/.bashrc source ~/.bashrc(Anacondaを使うべき状況にいるので)
pyenv install anaconda3-hogehoge
- 投稿日:2020-06-23T14:35:27+09:00
rJavaをR3.6環境のLinuxにインストールする。
rJavaをR3.6環境のlinux にインストールする
というか、そういうDockerImageを作るDockerfileを書く必要があったが、
結構エラーがでて詰まった。
ネットを探してもドンピシャがなかなか出てこなかったで、メモ。#rJavaインストールのための準備 RUN apt-get update && apt-get install -y openjdk-8-jdk RUN R CMD javareconf # install packages(DB接続用追加) RUN R -e "install.packages(c(\ 'rJava' \ ), repos='https://cloud.r-project.org/')"
- 投稿日:2020-06-23T13:30:18+09:00
yumとrpm
パッケージを管理するyumとrpm。
その違いとコマンドについてちょろっと。yum
・パッケージ管理ツール
→OSへのソフトウェアの導入と削除、依存関係の整理などを行うツール
・rpmより高機能
→統合的に管理運用するシステムが備わっている<代表的なコマンド>
--info(-i):パッケージグループの詳細表示
--list(-l):パッケージグループ一覧表示
--provides(-p):ファイルなどを指定して、該当ファイルを提供するパッケージ検索
--quiet(-q):実行時にメッセージを表示しない
--verbose(-v):詳しいメッセージ出力rpm
・パッケージ管理ツール
→OSへのソフトウェアの導入と削除、依存関係の整理などを行うツール<代表的なコマンド>
--install(-i):パッケージをインストール
--erase(-e):パッケージアンインストール
--query(-q):パッケージ情報の表示と検索
--verify(-V):パッケージ検査目次とかってどうやって作るんだろ、、終わり
- 投稿日:2020-06-23T12:14:28+09:00
[WIP] プロセス調査
# CPU使用率の降順で表示 $ ps aux --sort -%cpu # CPU使用率の昇順の表示 $ ps aux --sort +%cpu # RSSの降順で表示 ps aux --sort -rss # RSSの昇順で表示 ps aux --sort +rss # 親子 # ちなみに、子を殺せば親も死ぬ $ ps auxf # USR1 は USeR defined なシグナル # このシグナルを受けた時のプロセスの挙動は、アプリケーションが自由に設定する事ができる $ kill -USR1 `pgrep nginx` # 強制停止 # メモリ使い切った時など(スワップすると CPU を使うようになって、、)緊急性が高い $ kill -9 `pgrep nginx`
- 投稿日:2020-06-23T11:21:11+09:00
Ultra96/Ultra96-V2 向け Debian GNU/Linux で Lima Driverを動かす
はじめに
Linux Kernel 5.2 からメインラインに Lima Driver が追加されました。Lima Driver は Mali-400/450 用のオープンソースなカーネルドライバです。この記事では、linux-xlnx v2020.1 (Linux Kernel 5.4 ベース) で Lima Driverを動かす方法を示します。
なお、現時点では実験的に Lima Driver の起動を確認しただけです。その上で動作する Mesa Graphics Library まで動作させたわけではないことに注意してください。
Lima とは
Lima とは Mali-400/450 用のオープンソースなグラフィックドライバです。Lima には、Linux のカーネルドライバである Lima Driver と、Mesa Graphics Library のドライバである Mesa Lima があります。
Fig.1 Lima
Lima に関する詳しい情報は以下の URL を参照してください。
紛らわしいのですが、Lima Driver とは別に Mali Driver というのもあります。Mali Driver は ARM が提供しているオープンソースの Mali Ulgard GPU Kernel Driver です。Mali Driver を使うには ARM の Web ページにアクセスして、エンドユーザーライセンスに同意する必要があります。Ultra96/Ultra96-V2 に Mali Driver を組み込む方法に関しては次の記事を参照してください。
Lima Driver のビルド
Kernel への組み込み
Linux Kernel 5.2 からはメインラインに Lima Driver が組み込まれています。ドライバのソースコードは drivers/gpu/drm/lima にあります。
linux-xlnx v2020.1 は Linux Kernel 5.4 をベースにしているので、Lima Driver が追加されています。しかしUltra96/Ultra96-V2 用に提供されているカーネルコンフィギュレーションファイル(xilinx_zynqmp_defconfig) では Lima Driver が組み込まれません。arch/arm64/configs/xilinx_zynqmp_defconfig に CONFIG_DRM_LIMA=y または CONFIG_DRM_LIMA=m を追加するか、 make menuconfig で Device Drivers > Graphics support > LIMA (DRM support for ARM Mali 400/450 GPU) を選択してください。
Device Tree の設定
linux-xlnx v2020.1 の zynqmp 用の Device Tree には次の記述があります。
arch/arm64/boot/dts/xilinx/zynqmp.dtsi: (中略) : gpu: gpu@fd4b0000 { status = "disabled"; compatible = "arm,mali-400", "arm,mali-utgard"; reg = <0x0 0xfd4b0000 0x0 0x10000>; interrupt-parent = <&gic>; interrupts = <0 132 4>, <0 132 4>, <0 132 4>, <0 132 4>, <0 132 4>, <0 132 4>; interrupt-names = "IRQGP", "IRQGPMMU", "IRQPP0", "IRQPPMMU0", "IRQPP1", "IRQPPMMU1"; clock-names = "gpu", "gpu_pp0", "gpu_pp1"; power-domains = <&zynqmp_firmware PD_GPU>; }; : (後略)また、Ultra96 用の Device Tree には次の記述があります。
arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts/dts-v1/; #include "zynqmp.dtsi" : (中略) : &gpu { status = "okay"; }; : (後略)このことから、Ultra96 では GPU は有効になっているはずです。しかし、このままでは Lima Driver は動きません。実は、上で紹介した Device Tree は、Lima Driver 用ではなく Mali Driver 用だからです。
Device Tree を Lima Driver に対応させるためには、 gpu ノードのinterrupt-names プロパティとclock-names プロパティの値を変更する必要があります。
interrupt-names プロパティ
Mali Driver と Lima Driver では割り込みの名前が異なります。Lima Driver では interrupt-names プロパティを次のようにします。
arch/arm64/boot/dts/xilinx/zynqmp.dtsiinterrupts = <0 132 4>, <0 132 4>, <0 132 4>, <0 132 4>, <0 132 4>, <0 132 4>; interrupt-names = "gp", "gpmmu", "pp0", "ppmmu0", "pp1", "ppmmu1"; ;clock-names プロパティ
Mali Driver と Lima Driver とでは想定してるクロックが異なります。Mali Driver が想定しているクロックは "gpu"、"gpu_pp0"、"gpu_pp1" の3つですが、Lima が想定しているクロックは "bus"、"core" の二つです。
このように名前が異なるだけでなく、想定しているクロックの種類が異なるため、単純にクロックの名前を変えるだけでは「通常は」上手くいきません。「通常なら」 Lima Driver のソースコードレベルで変更が必要です。
しかし、ZynqMP に関しては少しトリッキーですが Device Tree を修正するだけで動かすことが可能です。具体的には次のように "gpu_pp0" を "core" に、"gpu_pp1" を "bus" に変更します。
arch/arm64/boot/dts/xilinx/zynqmp.dtsiclock-names = "gpu", "core", "bus";Lima Driver はまず "bus" の名前を持つクロックを有効にします。しかしこの Device Tree では実質的には "gpu_pp1" のクロックが有効になります。続いて "core" の名前を持つクロックを有効にします。しかし実質的には "gpu_pp0" のクロックが有効になります。
じゃあ "gpu" クロックはどうなるのか? という疑問がわきますが、ZynqMP の場合は問題ありません。というのも ZynqMP では "gpu_pp0"、"gpu_pp1"、"gpu" は階層構造になっていて、"gpu" -> "gpu_pp0"、"gpu" -> "gpu_pp1" のように "gpu" クロック出力は "gpu_pp0" クロックの入力および "gpu_pp1" クロックの入力に接続されています。Linux Kernel のクロックドライバは、あるクロックを有効にしたときに階層にさかのぼって有効にします。したがって、"gpu_pp0" クロックを有効にした時点で "gpu" クロックも有効になります。
Lima Driver の起動
Lima Driver を組み込んだ Linux Kernel を起動すると次のようなログがコンソール(or dmesg)にでます。
shell$ dmesg : (中略) : [ 7.269921] lima fd4b0000.gpu: IRQ pmu not found [ 7.274750] lima fd4b0000.gpu: IRQ ppmmu2 not found [ 7.279683] lima fd4b0000.gpu: IRQ ppmmu3 not found [ 7.284718] lima fd4b0000.gpu: gp - mali400 version major 1 minor 1 [ 7.291112] lima fd4b0000.gpu: pp0 - mali400 version major 1 minor 1 [ 7.297575] lima fd4b0000.gpu: pp1 - mali400 version major 1 minor 1 [ 7.304059] lima fd4b0000.gpu: IRQ pp2 not found [ 7.308708] lima fd4b0000.gpu: IRQ pp3 not found [ 7.313368] lima fd4b0000.gpu: l2 cache 64K, 4-way, 64byte cache line, 128bit external bus [ 7.330325] lima fd4b0000.gpu: bus rate = 499999995 [ 7.335463] lima fd4b0000.gpu: mod rate = 499999995 [ 7.360178] [drm] Initialized lima 1.0.0 20190217 for fd4b0000.gpu on minor 1 : (後略)また、/dev/dri の下に renderD128 が出来ます。
shell$ ls -la /dev/dri total 0 drwxr-xr-x 3 root root 120 Feb 14 2019 . drwxr-xr-x 14 root root 13820 Feb 14 2019 .. drwxr-xr-x 2 root root 100 Feb 14 2019 by-path crw-rw---- 1 root video 226, 0 Feb 14 2019 card0 crw-rw---- 1 root video 226, 1 Feb 14 2019 card1 crw-rw---- 1 root render 226, 128 Feb 14 2019 renderD128Lima Driver の問題点
Lima Driver を組み込んだ linux-xlnx v2020.1 を動かしてみましたが、現時点では次の二つの問題が生じました。
- zocl と共存できない
- 再起動に失敗する
zocl と共存できない
zocl は XRT(Xilinx Runtime) のカーネルモジュールです。zocl および XRT に関しては以下の記事を参照してください。
Lima Driver を組み込んだ状態で zocl を組み込むと、zocl のデバイスファイルが /dev/dri/renderD129 になります(renderD128 はすでに lima driver が使っている)。この状態で例えば ZynqMP-XRT-Example-1-Ultra96 のサンプルプログラムを起動しようとすると次のようにデバイスが見つからないと言われます。
shell$ ./streaming_lap_filter5.exe streaming_lap_filter5.xclbin Using FPGA binary file specfied through the command line: streaming_lap_filter5.xclbin XRT build version: 2.6.0 Build hash: 7104cc336e010e3e0755264ff832d811ff605e2c Build date: 2020-03-24 21:07:36 Git branch: 2019.2_Ultra96 PID: 610 UID: 1000 [Tue Jun 23 10:12:10 2020] HOST: debian-fpga EXE: /home/fpga/examples/ZynqMP-FPGA-XRT-Example-1-Ultra96/streaming_lap_filter5.exe [XRT] ERROR: No devices found ../src/krnl_streaming_lap_host3.cpp:71 Error calling err = cl::Platform::get(&platforms), error code is: -1どうやら /dev/dri/renderD128 が zocl に割り当てられてないとうまく動かないようです。試しに lima driver を rmmod してから zocl をロードして /dev/dri/renderD128 を zocl に割り当てると正常に動作しました。
再起動に失敗する
一度 Lima Driver を rmmod してから modprobe で再起動しようとすると、次のようなログがでて再起動に失敗します。
shell$ dmesg : (中略) : [ 1758.651570] lima fd4b0000.gpu: IRQ pmu not found [ 1758.656223] lima fd4b0000.gpu: mmu gpmmu dte write test fail [ 1758.662084] lima: probe of fd4b0000.gpu failed with error -5この件に関しては現在保留中です。
最後に
筆者は Ultra96/Ultra96-V2(ZynqMP) 向けに Debian GNU/Linux を提供しています1。しかし、現時点では前節で述べた問題があったので Lima Driver を組み込んでいません。これらの問題が解決し次第、Lima を組み込む予定です。何かいいアイデアを募集しています。
参考