20200623のLinuxに関する記事は8件です。

あらためて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を実行して変わるのはバージョン以降に付与したリリース番号である。
rpm-version.PNG
ここまでしつこく書く理由は、kernelやglibcなどのコアコンポーネントは、アプリケーションの動作保証で極めて重要だからだ。

だから出どころの分からない野良リポジトリを使ってはいけないし、RHEL6用のRPMパッケージをRHEL7にインストールするような強引なことはしてはいけない。

余談
筆者が経験したホラーストーリーがある。とある障害の支援でRHEL6の設定を確かめていたときの出来事だ。いくつかの基本コマンドが動かない。おかしいと思い、以下のコマンドでRed Hat以外のパッケージを探すと、たくさん出てきた。

VenderがRedHat以外のパッケージを表示するコマンド
rpm -qa --qf "%{name} %{vendor}\n"  | grep -v "Red Hat"

それもglibcなどのコアコンポーネントがFedoraやScientific Linuxになっている。それもリリース番号違いでなくバージョン番号違い。本来インストールできないものをnodepsforceでインストールしたようだ。そんな強引なことをしたら、正常動作しなくて当然だ。逆に動いていたことが不思議でならない。

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 -y

7系Linux OS

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y

6系Linux OS

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm -y

3-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: 32961

amzn2extra-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=priority

3-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: 89546

repoファイルの定義を確認すると、リージョンごとに用意した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を無効化しておき、必要なときだけ有効化する。

  1. EPELを無効化する。これでyumを実行してもEPELのパッケージは利用できない。
sudo yum-config-manager --disable epel

2.EPELにあるパッケージをインストール/アップデートするときだけ--enablerepoオプションで有効化する。

sudo yum --enablerepo=epel install <パッケージ名>

4-2. トラブルシュート

余力のあるとき執筆予定

5. まとめ

  • 標準リポジトリにないパッケージがあるときはEPELを探そう
  • 野良リポジトリは使わないこと。使うときは人柱覚悟で
  • RPMパッケージの依存性を崩すような強引なことはしないこと
  • AWSではEPELを有効にする独自コマンドが提供されている
  • Oracle Cloud InfrastructureのOracle Linux 7では独自のEPELリポジトリが提供されている
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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

でいけました!!

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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やカーネルについてもっと勉強するべきだな...
本日は以上です。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

個人的 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-stable
sudo ln -s /mnt/c/Windows/Fonts /usr/share/fonts/windows
sudo fc-cache -fv

GSuiteの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
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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/')"
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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):パッケージ検査

目次とかってどうやって作るんだろ、、終わり

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[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`
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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

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.dtsi
        interrupts = <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.dtsi
        clock-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 renderD128

Lima 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 を組み込む予定です。何かいいアイデアを募集しています。

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む