<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>備忘録 on Arch使いの日記</title>
    <link>https://blog.grainrigi.net/categories/%E5%82%99%E5%BF%98%E9%8C%B2/</link>
    <description>Recent content in 備忘録 on Arch使いの日記</description>
    <generator>Hugo -- gohugo.io</generator>
    <copyright>Copyright © 2022, grainrigi; all rights reserved.</copyright>
    <lastBuildDate>Mon, 28 Nov 2022 21:20:35 +0900</lastBuildDate><atom:link href="https://blog.grainrigi.net/categories/%E5%82%99%E5%BF%98%E9%8C%B2/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>RockyLinux9でEPELリポジトリを有効化する</title>
      <link>https://blog.grainrigi.net/post/rocky9-epel/</link>
      <pubDate>Mon, 28 Nov 2022 21:20:35 +0900</pubDate>
      
      <guid>https://blog.grainrigi.net/post/rocky9-epel/</guid>
      <description>
        
          
            CentOS系のOSではおなじみのEPELリポジトリをRockyLinux9で有効化してみる。 基本的な手順はCentOS8以前と同じだが、一部気をつけるべき点も存在する。
なお、今回用いた環境は以下。
OS: RockyLinux9.1 Arch: x86_64 OSのアップデート RockyLinux9は基本的にRHEL9準拠なので、yumの代わりにdnfが標準となっている。 といっても、基本的なコマンド体系はyumに非常に近いので迷うことは少ないだろう。
EPELを入れるのに先立って、以下のコマンドでシステムの全パッケージをアップグレードしておく。
1$ sudo dnf upgrade dnf updateとdnf upgradeの違い 自分は今までCentOS系でパッケージを更新するときにはyum updateを使っていたのだが、ドキュメントにはupgradeが記載されていたため今回はこちらを用いた。 調べてみたところ、dnf updateはdnf upgradeの完全なエイリアスであり機能に違いはないらしい。 (yumの場合、yum upgradeはyum --obsoletes updateの意味だったため違いがあった) また、dnfの場合はupgradeが推奨されているそうだ。
参考: Update and Upgrade Commands are the Same - Changes in DNF CLI compared to YUM
CRBの有効化 今までになかった手順なのだが、EPELリポジトリを使用する際はCodeReady Linux Builder(CRB)リポジトリの有効化が推奨されている。 CRBリポジトリとは簡単に言うと「〇〇-devel」系のビルド用のパッケージが含まれるリポジトリであり、 EPELに含まれるパッケージの中にはCRBに依存しているものが結構あるので、有効化しておいたほうがいいということらしい。
CRBは以下のコマンドにより有効化できる。
1$ sudo dnf config-manager --set-enabled crb EPELの有効化 いよいよEPELリポジトリを有効化する。例によってfedoraprojectのrpmファイルを直接インストールする。
1$ sudo dnf install \ 2 https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm \ 3 https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-9.noarch.rpm あとはプロンプトに従ってインストールを続行すれば完了である。
          
          
        
      </description>
    </item>
    
    <item>
      <title>Logicool G600 をLinux上で使う</title>
      <link>https://blog.grainrigi.net/post/g600-on-linux/</link>
      <pubDate>Sat, 26 Nov 2022 21:31:49 +0900</pubDate>
      
      <guid>https://blog.grainrigi.net/post/g600-on-linux/</guid>
      <description>
        
          
            FF14をプレイする上で手放すことが出来ないものの一つが多ボタンマウスである。 Logicool G600は言わずと知れた多ボタンマウスの名機で、 側面に12個のボタンを備えている上、G-shiftボタンを押しながら使うことにより、 さらに追加で12個のアクションを切り替えて使うことが可能となっている。
ただ、得てしてこの手のデバイスはWindows専用のソフトやドライバが必要になるものである。 今回はそんなG600をLinuxで扱う方法について見ていく。
なお、今回このデバイスを使うに当たって、Linux上にインストールしたFF14を用いる。 FF14をLinux上にインストールする方法については以下の記事を参照。
FF14をArchLinuxで動かす(DirectX11対応) | Arch使いの日記
概要 Logicool公式から提供されるG600のドライバはWindows用のものしかないのだが、 「オンボードメモリモード」というG600の機能を用いることで専用ドライバがなくとも側面ボタンを使えるようになる。
具体的には以下の手順によりLinux上でG600を使えるようにする。
Windows上に、Logicool Gaming Softwareをインストールする Logicool Gaming Softwareでオンボードメモリモードを有効にする Logicool Gaming Softwareで各ボタンにキーを割り当てる 設定したマウスをLinuxに接続して使用する このように、G600の最初の設定の段階でどうしてもWindows環境が必要となる。 もしWindoows環境を持っていない場合でも、 Windows10のインストールイメージはMicrosoft公式から入手することができるため、 これを一時的に用いて設定を行うといいだろう。
1. Logicool Gaming Softwareのインストール Logicool Gaming Software(以下LGS)は、Logicoolのゲーミングデバイスを設定するためのユーティリティである。 現在では新しい設定ユーティリティのGHUBに置き換えられているのだが、GHUBだとG600の一部の設定がうまく出来ないため、 今回はLGSの方を用いる。
なお、公式からは既にダウンロードできなくなっているが、Internet Archiveから引き続き入手が可能である。
32bit: LGS_9.02.65_x86_Logicool.exe 64bit: LGS_9.02.65_x64_Logicool.exe ダウンロードしたらインストーラーを実行してインストールする。 インストールが完了したら再起動を求められるが、ここで再起動せずに次の手順に進んでも特に問題はない。
2. G600をオンボードメモリーモードに切り替え G600をPCに接続し、LGSを起動する。 すると、下のような画面が表示されるので、右上のトグルスイッチでオンボードメモリモードに切り替える。
オンボードメモリモードに切り替えることで、G600は専用ドライバのない環境でも通常のキーボード・マウスのように振る舞うようになる。 スタンドアロンだから機能が著しく制限されるということはなく、柔軟なプロファイルを本体に書き込むことができるようになっている。 次項で実際に各ボタンにキーボードアクションを割り当てていく。
3. 各ボタンにキーを割り当てる 下のツールバーから設定ページに移動する。
すると、以下のように各ボタンに割り当てられているアクションを見ることができる。
画像上の各ボタンをダブルクリックすると、キーの割当画面が開く。
「Clear」を押して既存の設定を消去し、設定したいキーをキーボードで入力することで好きなキーを割り当てることができる。 (ちなみに、GHUBだとここで設定できるキーが制限されている。今回LGSを使ったのはここで好きなキーを割り当てるためである。)
今回は、FF14の3x4のホットバーに割り当てることを想定して、 まず各ボタンに通常の1〜0,-,^キーを割り当て、 G-shift状態の各ボタンにはNum1〜Num0,-,*キーを割り当てた。
左: 通常状態、右: G-shift 修飾キーの割当について 実は、最初は各ボタンにNumパッドのキーを割り当て、G-shiftにはAlt+Numパッドキーを割り当てていたのだが、 Altキーを加えた割当をした場合、途中からAltキーが送信されなくなるという不具合が発生してしまった。 このため、通常状態とG-shift状態で別々のキーを割り当てるようにしてこの問題を回避している。
          
          
        
      </description>
    </item>
    
    <item>
      <title>Linux &#43; NVIDIAグラフィックカードで音が途切れる現象について</title>
      <link>https://blog.grainrigi.net/post/nvidia-sound-cutoff/</link>
      <pubDate>Sat, 26 Nov 2022 18:39:55 +0900</pubDate>
      
      <guid>https://blog.grainrigi.net/post/nvidia-sound-cutoff/</guid>
      <description>
        
          
            数年前からずっと悩まされていた問題なのだが、 NVIDIAのグラフィックカードのDisplayPort(HDMI) Audioで音声を出力した場合に、 音がときどき途切れてしまうという問題が生じていた。 以前に調べた際には有効な情報を見つけることが出来なかったのだが、 今回この現象の原因及び解決策を見つけることが出来たため、備忘録として記事に残しておく。
TL;DR PCI Expressの世代をGen2に制限することで症状を抑制することができる。 これは、マザーボード・GPU間の通信速度の大きな変動を抑制できるためである。
環境 今回の問題が生じていた環境は以下の通りである。
OS: ArchLinux(x86_64) マザー: ASUS Z690FORMULA GPU: Gefore GTX 1080 Ti DisplayPortにより映像・音声を出力 GPUドライバ: nvidia 自分の環境ではプロプライエタリドライバを用いているが、 オープンカーネルモジュールでも同様の問題が生じていると思われる。
現象の原因 今回の現象については、Pipewireのリポジトリにて議論されており原因もここで突き止められている。
nvidia sound cutting out randomly on external screen (#2375) · Issues · PipeWire / pipewire · GitLab
ここの情報によると、マザーボード・GPU間の通信速度が大きく変動した際に音の欠落が発生するようである。
実際にそのような変動が発生している可能性があるかどうか確かめるために、以下のコマンドを実行してGPUの通信速度・動作速度等をモニターしてみる。
1$ nvidia-smi --query-gpu=timestamp,pstate,power.draw,pcie.link.gen.current,pcie.link.width.current,temperature.gpu,utilization.gpu,clocks.current.graphics,clocks.current.memory,clocks.current.sm --format=csv -lms 500 音の欠落が発生した際、モニターした結果は以下のようになっていた。
確かに途切れが発生したタイミングで動作クロックが大きく上昇している。 また、PCI Expressの通信世代も省電力状態でGen1だったのが途切れが発生したタイミングでGen3に切り替わっている。
解決策 音の途切れが発生する原因は通信速度の大きな変化であるため、以下のような解決策をとることができる。
通信速度を固定する 以下のいずれかの方法により、動作クロック(≒通信速度)を固定することができる。
メモリクロックを固定する(GTX16xx,GTX20xx以降のみ対応) 省電力設定を無効にする Pipewireのレポジトリで紹介されていたのは1のメモリクロックを固定する方法で、 これはnvidia-smi --lock-memory-clocks=5508,5508のようにメモリクロックの最大値と最小値に同じ値を指定することで実現できる。
2はPowerMizerの設定を変更する方法。詳細な設定方法に関しては今回は省略する。
これらの方法により音声の症状は改善するが、動作クロックが不必要に上昇するため、消費電力が無駄に増加することとなる。
PCI Expressの世代を制限する(おすすめ) もう一つの方法として、PCI Expressの世代を制限してしまうというものがある。 上記のモニタ結果を見れば分かるように、音の欠落が発生するのは、Gen1→Gen3と大きく世代が動いたときである。 よって、マザーボードの設定等によりPCI Expressの世代をGen2以下に制限してしまうことにより症状が緩和されると考えられる。
          
          
        
      </description>
    </item>
    
    <item>
      <title>Misskeyを32bit環境(Debian i386)で動かしてみる</title>
      <link>https://blog.grainrigi.net/post/misskey-on-i386/</link>
      <pubDate>Tue, 22 Nov 2022 19:47:21 +0900</pubDate>
      
      <guid>https://blog.grainrigi.net/post/misskey-on-i386/</guid>
      <description>
        
          
            昨今のTwitterに関する騒動の影響で、「ポストTwitter」になりうるプラットフォームが俄に注目を集めているらしい。 その一つがセルフホスト型のプラットフォームのMisskeyであり、Twitterを踏襲したタイムラインをサポートしつつ、 Slackライクなリアクションを投稿につけることが出来たり、UIの高度なカスタマイズが出来たりするなどいくつかのユニークな特徴を有している。 また、ActivityPubによる他インスタンスとの連携に対応しており、 他のMisskeyインスタンスだけでなく、Mastodon等とも連携可能な非中央集権型のプラットフォームとなっている。
MisskeyはNode.jsで書かれているため、本来はLinux x86環境で動かすことはできないのだが、 Node.jsの非公式ビルドを用いる等、様々な工夫をすることで32bit環境でも動かすことが出来た。 今回はその記録として構築手順を書いていこうと思う。
概要 今回用いる環境はDebian 11.5 (bullseye) i386である。(ArchLinuxは公式にはx86_64しか対応していない為。) また、検証に際してはVirtualBox上のVMにて作業を行っている。
Misskeyの構築手順としてDockerを使ったインストールが推奨されているため、今回はこれに従う。
Dockerを使ったMisskey構築 | Misskey Hub
やる必要のあること 32bit環境で動かすにあたって、以下の障壁をクリアする必要がある。
i386用のNode.js Dockerイメージの準備 prebuiltバイナリを用いるパッケージへの対処 @tensorflow/tfjs-nodeを使わないようにする sharpの依存ライブラリの手動ビルド 以下ではこれらの解決方法を解説する。
※ 構築手順のみを知りたい場合、完全な構築手順を参照
i386用のNode.js Dockerイメージの準備 Node.jsは公式でLinux x86をサポートしないため、Docker Hubの公式イメージにもlinux/386版は存在しない。 ただ、Node.jsの非公式ビルドでx86版が存在するため、 x86版Node.jsイメージを作ることは技術的には可能である。
この方法で作られたと思われる非公式のNode.jsイメージがBalena社から提供されているので、 今回はありがたくこれを使わせてもらうことにする。
balenalib/i386-node - Docker Image | Docker Hub
Misskeyの公式で使われている16.15.1-bullseyeもバッチリ存在している。 (ただし、slim版は無い模様)
@tensorflow/tfjs-nodeを使わないようにする Misskeyはオプション機能としてNSFW画像の自動判定機能が存在し、Tensorflowを用いて実装されている。 TensorflowのNode.js用ライブラリである@tensorflow/tfjs-nodeはネイティブのlibtensorflowに依存しているのだが、 このlibtensorflowはx86をサポートしていない。 このため、今回はNSFW機能の利用を諦めて@tensorflow/tfjs-nodeのインストールを回避するようにする。
なお、Misskey自体は既に@tensorflow/tfjs-nodeをoptionalDependenciesに移動しているため、 本来はパッケージのインストール時に--ignore-optionalを指定するのみで済む筈なのだが、 実際のnsfwjsのpeerDependenciesを正しく扱っていないためこのままだと依存関係エラーで起動しなくなってしまう。
nsfwjsのpeerDependenciesに含まれているのは@tensorflow/tfjsであり、 これ自体はlibtensorflowに依存していないため、単純にdependenciesに追加すれば解決する。
sharpの依存ライブラリの手動ビルド sharpはNode.js用の画像処理パッケージで、Misskeyではアップロードされた画像のリサイズ等に用いていると思われる。 このパッケージはネイティブのライブラリであるlibvipsに依存しており、 通常のインストールであればprebuiltバイナリが自動でダウンロード展開されるようになっているのだが、 x86の場合は手動でビルドした上でホスト上に直接インストールする必要がある。 (ビルド手順: Building libvips from source)
なお、Debianのリポジトリにもlibvips42というパッケージが存在するのだが、 こちらはバージョンが古く(これは8.10.5だが、sharpには8.11以降が必要)、 sharpのインストール時に必要なcmake関係のファイルも不足しているため、これを用いることは出来ない。
          
          
        
      </description>
    </item>
    
    <item>
      <title>FF14をArchLinuxで動かす(DirectX11対応)</title>
      <link>https://blog.grainrigi.net/post/ff14-on-linux/</link>
      <pubDate>Thu, 17 Nov 2022 00:30:34 +0900</pubDate>
      
      <guid>https://blog.grainrigi.net/post/ff14-on-linux/</guid>
      <description>
        
          
            (C) SQUARE ENIX CO., LTD. All Rights Reserved.
FF14はDirectXをヘビーに使っているソフトウェアであり、OpenGL等のオープンなAPI上では動作しない。 このため、これまでFF14をLinuxで動かそうとする際にはWine+Gallium9 Direct Rendering(Direct3D9の描画コマンドを直接送信するモードで、AMDのみ対応)等の特殊な技法を用いる必要があった。 しかし、近年のWineD3Dの活発な開発、およびDXVKの登場により、 Direct3D9はおろかDirect3D11までほとんどネイティブに近い速度で動作させることが可能となっているらしい。
ということで、今回はFF14をLinux(ArchLinux)で動かすのに必要なことをまとめてみる。
パッケージのインストール ランタイム(Wine + ドライバ) 以下をインストールする
wine系 wine wine-mono wine-gecko lib32-gnutls HTTPS System Errorを回避するため lib32のvulkan driver (以下のうちいずれか) NVIDIA lib32-nvidia-utils AMD lib32-vulkan-radeon lib32-amdvlk lib32-vulkan-amdgpu-pro (AUR) Intel lib32-vulkan-intel DXVK DXVKはWineプリフィックス内にインストールするものなので、セットアップスクリプト(setup_dxvk.sh)の形で提供されている。 最新版はAUR(dxvk-bin)からインストールしてsetup_dxvkコマンドとして利用可能。
AURからインストールするかGitHubからtar.gzをダウンロードしてsetup_dxvk(.sh)を実行できるようしておく。 (Wineプリフィックスへのインストールはまだ行ってはならない)
Note 最新のDXVK(2.0)を使う場合、GPUがVulkan1.3をサポートしている必要がある。 古いGPU(NVIDIA Kepler以前およびAMD Polaris以前)の場合はVulkan 1.2以前しかサポートしないため、 GitHubからDXVK 1.xをダウンロードして使う必要がある。
Releases - doitsujin/dxvk
FF14のインストール インストーラーのダウンロード 以下のページからインストーラー(ffxivsetup_ft.exe)をダウンロードする。
ファイナルファンタジーXIV フリートライアル | SQUARE ENIX
インストーラーの実行 インストーラーを立ち上げるとリージョン選択ダイアログが出るので、一番下の「日本語」(文字化けしている)を選択する。
起動後もほとんど文字化けしてしまっているが、基本的には真ん中右側の「次へ(N)」ボタンを押し続ければ良い。
初回起動 ランチャーの起動 ここまで出来たら、デスクトップアイコンからランチャーを起動する。 (デスクトップ上のアイコンを利用できない場合、wine &#39;~/.
          
          
        
      </description>
    </item>
    
    <item>
      <title>Hugo &#43; Clarityでブログを作ってみる</title>
      <link>https://blog.grainrigi.net/post/give-hugo-a-try/</link>
      <pubDate>Sat, 12 Nov 2022 19:10:40 +0900</pubDate>
      
      <guid>https://blog.grainrigi.net/post/give-hugo-a-try/</guid>
      <description>
        
          
            今までブログを書くのにはてなブログを利用していたが、 せっかく独自ドメインをとったし何か自前のブログを持ってみたいと思った。
WordPressはDB必須でデプロイが面倒そうだったので、 静的サイトジェネレータでは割と有名なHugoを使ってみる。
準備 hugoコマンドのインストール Hugoはhugoという単一のコマンドを使って記事の追加・ビルド等を行う。 よってまずはhugoコマンドをインストールする必要がある。
参考: Quick Start | Hugo
ArchLinuxの場合、hugoは公式リポジトリに存在する。
1sudo pacman -S hugo サイトの作成 1hugo new site myblog これでmyblogディレクトリに必要なファイルが準備される。
Clarityのセットアップ この後、Quick Startガイドに従うと、gitのsubmoduleとしてテーマをインストールするのだが、 テーマによっては全く別のインストール方法を用いる必要がある場合がある。
今回用いる「Clarity」というテーマは、Hugo modules(go moduleを活用した方式)を使ってのインストールが推奨されている。
参考: Getting up and running | chipzoller/hugo-clarity
goのインストール Hugo modules(hugo mod)を用いる場合、golangのインストールが必須となる。
1sudo pacman -S go 設定ファイル・雛形の取込み ClarityではexampleSiteの設定の取込みが必須となっている。 (最初、設定を取り込まずにセットアップしてしまったのだが、Code Blockの表示に不具合が生じた。)
1cd myblog 2hugo mod init myblog 3wget -O - https://github.com/chipzoller/hugo-clarity/archive/master.tar.gz | tar xz &amp;amp;&amp;amp; cp -a hugo-clarity-master/exampleSite/* . &amp;amp;&amp;amp; rm -rf hugo-clarity-master &amp;amp;&amp;amp; rm -f config.
          
          
        
      </description>
    </item>
    
  </channel>
</rss>
