Blog

  • nvidiaのドライバーを更新したのでdocker環境も再インストールしたよ

     一つまえの記事でUbuntu(20.04)のnvidia関連パッケージを一度すべて削除してしまったので、docker関係の環境も再インストールしなければいけなかった。

     下記に従って実行してみた。自分の記載はあやしいのと、当然下記のnvidiaのリンク先のほうが記載が新しくなってる可能性があるので、なにか変だと思ったらnvidia.comにあたったほうが良い。
    https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html

    1.パッケージのインストール

    $ sudo apt install nvidia-container-toolkit

    2.設定の変更

    $ sudo nvidia-ctk runtime configure --runtime=crio

    3.dockerデーモンの再起動

     $ sudo systemctl restart docker

    4.確認する

    下記でGPUの情報が ホストでnvidia-smiを実行したときと同じように表示されればOKのはず

    $ sudo docker run –rm –runtime=nvidia –gpus all nvidia/cuda:11.6.2-base-ubuntu20.04 nvidia-smi
    Sat Apr  6 16:34:33 2024       
    +—————————————————————————————–+
    | NVIDIA-SMI 550.54.15              Driver Version: 550.54.15      CUDA Version: 12.4     |
    |—————————————–+————————+———————-+
    | GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
    | Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
    |                                         |                        |               MIG M. |
    |=========================================+========================+======================|
    |   0  NVIDIA GeForce RTX 3060        Off |   00000000:04:00.0  On |                  N/A |
    |  0%   49C    P8             11W /  170W |     539MiB /  12288MiB |      0%      Default |
    |                                         |                        |                  N/A |
    +—————————————–+————————+———————-+

    ホストOS上でnvidia-smiを実行したときが下記。大丈夫そう。

    $ nvidia-smi
    Sun Apr  7 01:40:48 2024       
    +—————————————————————————————–+
    | NVIDIA-SMI 550.54.15              Driver Version: 550.54.15      CUDA Version: 12.4     |
    |—————————————–+————————+———————-+
    | GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
    | Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
    |                                         |                        |               MIG M. |
    |=========================================+========================+======================|
    |   0  NVIDIA GeForce RTX 3060        Off |   00000000:04:00.0  On |                  N/A |
    |  0%   50C    P5             18W /  170W |     560MiB /  12288MiB |      2%      Default |
    |                                         |                        |                  N/A |
    +—————————————–+————————+———————-+

     

  • Ubuntuをアップデートしたら起動しなくなったけど色々やったら起動するようになった(nvidiaドライバー)

     久しぶりにUbuntu(20.04)を起動したのでパッケージのアップデートをしようとおもった。

     「ソフトウェアの更新」を実行すると、「部分的にしかアップデートできない」旨の表示が出た。が、特に気にせず、依存関係か何かで何回かに分けてアップデートしないといけないのかなとおもいってそのまま実行、再起動を行った。

    起動メニュでUbuntuを実行すると、黒いコンソールの 画面までは進むが、たぶんデスクトップに切り替わるタイミングで画面がフリーズして起動しないという現象に遭遇した。

    理由はわからないが、はじめにUbuntu環境をインストールしたときのGPUがGTX1070で、そのままRTX3060に換装して使い続けていたので、なにか不整合が起きてしまっていたのかもしれない(表面上は動いていた、と思う)。

    困った。ということでいろいろ調べながらやって復旧した(たぶん)なのでやったことメモ。LinuxおよびUbuntuに詳しい訳ではないので、余計なことをやったりしているかもしれません。実際にはもっといろいろ試行錯誤しているが、結果的に整理すると意味あったのは以下だけだと思う。

    1.Ubuntuをリカバリーモードで起動

     これは環境によってやり方がまちまちかもしれない。私の場合はGRUBのメニューの”Advanced options for Ubuntu”みたいなやつを選んで、とにかくRecoveryモードでUbuntuを起動する。まずNetworkを選択するとネットワークが使えるようになるらしいので、それを選んだあとにRootを選んでプロンプトを表示。

     ※このとき苦し紛れにメニューにあるdpkg項目を選んで、gcc関係のパッケージの修復?が行われたようなのだが、これが関係あったかどうかはわからない(たぶんない)

    2.起動ログを確認

    # journalctl -p err -b

    で、起動時のエラーログを見ることができるらしい。気になったのは、

    Failed to start nvidia-powered service
    とかいうあたりで、ググったりした結果Nvidiaのドライバが壊れてるんだろうとあたりをつけた

    3.nvidiaのドライバ類をすべて削除

    # sudo apt-get remove –purge ‘^nvidia-.*’
    # sudo apt autoremove

    で、いちどnvidia関連のパッケージをすべて削除した。
    ついでにdockerのnvidia関連パッケージも消えてしまったがこの際作り直すことにしていったん忘れる。

    (※こうするとnouveauドライバが有効になるはずだぜという記事もみつけたのだが、少なくとも自分の環境では起動しなかった(soundがどうとかいうエラーが残っていた。これも調べるとnvidia関連が原因に見えた)。 miniPC+eGPUという環境なのも影響しているのかもしれないし、それでなにか設定が残ってしまっていたのかもしれない)

    4.nvidiaのドライバを再インストール

    仕方ないのでリカバリーモードのままnvidiaのドライバの再インストールをした。
    Nvidiaのサイトのままに、

    # sudo ubuntu-drivers install

    を実行して、自動的に最適なドライバを検出してもらった。ここは問題なくインストールが完了した。よく考えたらリカバリーモードでrootに入っているのでsudoいらんことに気づいた(今)。

     5.再起動

    # sudo  reboot

     で再起動をかけると、無事に起動してデスクトップが表示された。

     

    TODO:docker関係の構築をやりなおさなければいけない。


  • NVidia Container Toolkitでgpu-enabledなdocker imageで作業したときの作業メモ

    GPUを利用する機械学習系の環境を構築する際に 、CUDAとフレームワーク等のバージョンの整合性で困ることがある。必ずしも最新版にしておけばいいというわけではないことが結構ある(気がする)

    dockerコンテナ内でgpuが利用できるようになるNvidia Container TookitをNvidiaが提供してくれているので、これを利用すると任意のCUDAバージョンの環境が構築できるようになりますという作業メモ。

    1.Nvidia Container Toolkitをインストール

    ホストOS側に、Nvidia Linux DriverとNvidia Container Toolkitをインストールして、docker runtimeにnvidiaランタイムを認識してもらうまで下記のマニュアルに沿って設定。

    ホスト側にはNvidia Linux DriverおよびNVidia Container Toolkit だけで良いので、CUDAで気を病む必要がない(たぶん)

    https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html

     

    2.gpuが認識されているかの確認方法

    これも書いてある通りだが、

    $ sudo docker run –rm –runtime=nvidia –gpus all nvidia/cuda:11.6.2-base-ubuntu20.04 nvidia-smi

    のようにして、ホストOSと同様にgpuの情報が表示されればOK。

     

    3.dockerイメージはどこにあるの

     https://hub.docker.com/r/nvidia/cuda

    ここに任意のベースOSとCUDAのバージョンの組み合わせのtagがあるので、必要なものを使えば良い。

     

    4.必要なコマンドとかが見当たらないんだけど…?

    上記のDocker Imageは、NVidia関係のツールが準備されている一方、curl gitなどもインストールされてないし、python もインストールされていないっぽい。なので実際には、上記イメージをベースにして下記みたいに共通で使うパッケージをインストールしたイメージを作っておくのが良いと思う。

    ———————————

     $ cat Dockerfile
    FROM nvidia/cuda:11.6.2-base-ubuntu20.04

    # Install needed packages
    RUN apt-get update &&
        apt-get install -y –no-install-recommends curl git python3 python3-pip &&
        rm -rf /var/lib/apt/lists/*

    # Make python3 default
    RUN update-alternatives –install /usr/bin/python python /usr/bin/python3 1

    ———————————

    上記のうち最後の行は、Ubuntuの標準パッケージではpythonコマンドではpython2系が起動してしまうっぽいので、それを切り替える方法(詳しくはupdate-alternativesで検索せよ)。本当はpyenvとかでcuda同様に必要なpythonランタイムを選択したほうが良さそうな気もするが、とりあえずこのようにする

     

    5.作業はどんなふうにすれば?

    docker image内に入って作業するには以下のようにすれば良い。
    (image名)のところは作成した任意のimage名にする。あとの注意点は–gpus
    allとかのオプションをつけないとだめなのと、一時的に作業とか確認したいだけのときには–rmオプションもつけないとゴミのコンテナがたくさんであとで困る(rmオプションは実行終了後に当該コンテナが自動で削除される)。

    $ docker run –rm -it –gpus all (image名)

  • Stable Diffusion WebUIをubuntu, pyenv virtualenvの環境でインストールした

     Stable Diffusion WebUIをUbuntuとpyenv-virtualenvの環境でインストールした。
    公式のマニュアルどおりではうまく行かなかったので、正しいのかはわかってないけどとりあえず動いたので差分のメモをしておきます。試したのは2023/3/25。

    Ubuntuの環境は以下の通り
    $ cat /etc/os-release
    NAME=”Ubuntu”
    VERSION=”20.04.3 LTS (Focal Fossa)”

    1. まずpyenv virutualenvで専用の環境を作る。現時点で要求のpythonのバージョンが3.10.6とのことだったので従う

    $ pyenv virtualenv 3.10.6 stable-diffusion-webui
    みたいにして、3.10.6をベースにしたvirtualenv環境を作っておく。

     

    2. “Automatic Installation on Linux”のコマンドでは起動時にstable diffusionが見つからないと出て起動できなかった。仕方がないのでここのドキュメントにあるManual Installの方を試した。

    3.これは単純に私が理解してないだけだと思うけど、Manual Installの最後の意味がわからなかった(何をどこに配置すればいいのかがわからなかった)

     # (outside of command line) put stable diffusion model into web ui directory

    # the command below must output something like: 1 File(s) 4,265,380,512 bytes
    dir model.ckpt
     
    結論としては、 ダウンロードするモデル(checkpointファイルと呼び、.ckptファイルというらしい)は
    このあたりからダウンロードして、配置先は
    $(stable-diffusion-webui-base)/models/stable-diffusion/ の配下に置いた。
     
    4.最後に
    $ python webui.py
    を実行すれば起動するとあるのだが、
    AssertionError: Couldn't find Stable Diffusion in any of: ['/home/xxx/src/stable-diffusion-webui/repositories/stable-diffusion-stability-ai', '.', '/home/xxx/src']
    みたいなエラーが出て起動できなかった。ぐぐってみるとなんかのバグか環境依存な気もしたんだけどよくわからなかった
     
    5.困ったので、
    $ python launch.py
    を実行してみた(launchと書いてあるんだからとにかく何かが起動するんだろうと思っただけ)
    そうすると
    $ python launch.py
    Python 3.10.6 (main, Mar 25 2023, 07:43:47) [GCC 9.4.0]
    Commit hash: a9fed7c364061ae6efb37f797b6b522cb3cf7aa2
    Installing open_clip
    Cloning Stable Diffusion into ...(略)
    みたいに出て、何やら追加でモジュールがダウンロードされているように見えた。
    最終的に
    Running on local URL: http://127.0.0.1:7860
    と表示されて、ここのURLにアクセスするとStable Diffusion WebUIがブラウザ上で表示できた
    さらに、以降は
    $ python webui.py
    でも起動できたので、インストールの最後の段階でpython launch.pyを実行することが必要だったのだろう(きっと)。


  • Windowsでvim環境を構築するための道のり:終章

    昨日Windowsでhowmをもう一回使いたくてvimでやってみるかと思ったんだけど、今日調べていたらVSCodeで類似の拡張があることがわかった。もともとhowmはちょっと機能多すぎてメモとTODOぐらいできればいいんだけどな、、という感じだったのでむしろちょうど良いぐらいかもしれない。
    vscode-memo-life-for-you
  • Windowsでvim環境を設定するための道のり:設定はどこに書けばいいのか

    昔Emacsでhowmというツールを使っていたのを思い出したんだけど、もうEmacsとか使うの気が重いな、、と思っていたところvimにQFixHowmというプラグインがあるらしいので、そちらでセットアップしてみることにしました。いったんWindows Subsystem for Linuxのコンソール上のvimでセットアップしてみたんだけど、日本語切り替えとモード切替がめんどくさすぎて無理っぽかったので、gvimで再トライです。gvimはまともに使ったことが無いので、設定ファイルはどこに置けばいいのだ、、?からスタートです。
    • 閑居う変数としては、$VIMと$HOMEが存在する。
    • 確認するときは
      :echo $VIM
      または
      :echo $HOMEで表示される
    • windows上では、.vimrcでなく_vimrcと_gvimrcとして作成する(これは単にWindows上のファイル名規則の制限かな)
    • _gvimrcはGUI版のvim上でだけ有効
    • $VIM_vimrcと$VIM_gvimrcは編集に管理者権限が必要になるのと、$HOME_vimrcまたは$HOME_gvimrcが存在すればそちらが優先(上書きされるので、これを作成すれば良い。
    ためしに$HOME_gvimrcに
    colorscheme slate
    と書いて起動したらカラー設定が変更されたので、OKとします。
    見たサイト:https://oki2a24.com/2016/03/11/put-vim-setting-file-in-windows/
    本当はvscodeでhowm的な機能があればいいなと思ってます。
    あとはhowm(的なもの)が使えればいいというのがゴールなのでやっぱりEmacsというセンも捨ててはいないです。
  • ファイルが含まれているrpmパッケージの情報を表示する

    $ rpm -qf {ファイルパス}|awk -F’-[0-9]’ ‘{print $1}’|xargs yum info

  • pylintがcv2のメンバを見つけてくれない

    ・VSCode 1.29.1
    ・pipenv 2018.7.1
    ・opencv-python 3.4.3.18
    ・pylint 2.1.1

    上記の環境でpylintをかけるとcv2のメンバがいないと怒られる。
    (実際はVSCode自体は関係ない。pylintコマンド直接でも同様。)

    https://stackoverflow.com/questions/50612169/pylint-not-recognizing-cv2-members

    上記に従って、pylintに –extension-pkg-whitelist=cv2 というオプションを渡して上げれば良い。VSCode上だとpython.linting.pylintArgsというオプションで渡す。

    cv2のメンバはCのモジュールで定義されているから(?)の模様である。

  • pipenv2018.7.1とpip18.1の組み合わせはエラーになる

    不具合に遭遇したのでメモ。

    現象

    $ pipenv install {some_package}
    すると、エラー終了する。
    Pipfileやパッケージのインストール自体は完了している
    lockfileの作成あたりでコケている模様?

    原因

    エラーメッセージでググると同様の事象を見つけた。
    https://github.com/pypa/pipenv/issues/2871

    pipenv2018.7.1とpip18.1の組み合わせがエラーを起こしている模様。

    解決方法

    workaroundとしてはpipを18.0にする。
    ポイントとしては、pipenvの環境のほうのpipを18.0にする。

    $ pipenv run pip install pip==18.0

  • Pythonの環境構築にpipenvを使う

    pipenvというPythonの仮想環境構築ツールを使い始めました。詳細は公式を見れば良いとして分かりづらかったところのメモ書き。

    Pipenv: 人間のためのPython開発ワークフロー

    書いている時点のバージョンは以下
    $ pipenv –version
    pipenv, version 2018.7.1

    インストール

    繰り返しだが詳細は上記の公式サイトのドキュメントを読めば良い。macOSの場合Homebrewとpipを使う方法があるようですが、私はPythonのバージョン管理にpyenvも使っていてHomebrewの方で入れるとバージョンが変になりそうな気がしたのでpipの方でインストールしました(Homebrewで試してはいない)。

    $ pip install pipenv
    すると、下記のようにpyenv配下にpipenvがインストールされてる模様。
    $ which pipenv
    /Users/hkuro/.pyenv/shims/pipenv

    使い方

    任意のディレクトリで
    $ pipenv shell
    とすると、”カレントディレクトリの名前-{hash}”という名前のvirtualenvが~/.local/share/virtualenvs/配下に作成される。hashの部分は詳しく調べてないけど何らかのハッシュみたいなので、別の同名ディレクトリでpipenv shellしても別のvirtualenvとして作成される(そりゃそうか)。

    環境変数を設定することでカレントディレクトリに作成されるようにすることが可能(

    PIPENV_VENV_IN_PROJECT)。これは環境によって違いそうなのでpipenv shellするときのオプションであったほうが便利そうな気もする。
    カレントディレクトリにPipfileを作成してくれて、pipenv経由でパッケージをインストールするとPipfileの更新なども同時にやってくれる。これまでだとpip freezeとかいちいちしないといけなかった部分が、PHPでいうところのcomposerみたいな感じになっているということ、なんだと思った。

    9/21追記:任意のディレクトリでpipenv shellして環境が作成されたあと、そのディレクトリを別のパスに移動したあとにpipenv shellすると新規のvirtualenvが作成される、元の場所に戻すと前のvirtualenvに戻れるので、やはりsuffixのハッシュはカレントディレクトと連動している模様。

    virtualenvから抜けるには

    pipenv shellした環境はvirtualenvでsource activateした場合と違ってサブシェル中で動作しているようなので、環境を抜けるにはCtrl+Dかexitする必要がある。deactivateしてしまうとvirtualenvな環境からは実質抜けてるけどpipenvが起動したサブシェルからは抜けられないみたいな中途半端な状態になってしまうので注意する。

    環境の削除

    普通のvirtualenvなので、上記の~/.local/share/virutualenv/配下の該当ディレクトリを丸ごと削除すれば良さそうだけど、もしくはpipenv shellしたのと同じディレクトリでpipenv –rmとすれば対応する環境は削除される。

    その他

    繰り返しだが作成されるのは普通のvirtualenvなので、
    $ source ~/.local/share/virtualenv/hogehoge/bin/activate
    とかすれば任意のディレクトリで特定のvirtualenvに入ることもできる。