Asahi Linux (Arch Linux ARM) に関する動向

Asahi Linux は ALARM (Arch Linux ARM) の公式サポートを "not recommended"^[1] としています. また, そもそも Asahi Linux がマイナーなのもあり^[2], 文献の比較的多い Arch Linux でも Asahi Linux もとい Apple Silicon 搭載の MacBook についての言及は (x86_64 に比べ^[3]) 圧倒的に少ないと言えます. 私としては細かくない記録は記事化しています^[4] が細かい記録は記事化するより垂れ流せる場所があった方が良いかなと思い場を設けました.

注意ですが, 各コメントは随時更新されます. ただ, 原則として追記のみ行う形に留めるようにします.

脚注

https://github.com/AsahiLinux/asahi-installer/blob/8bbbb8ca5a347d99b243e10f24358573f1587df0/data/installer_data.json#L152 ↩︎
主観による ↩︎
そもそも Arch Linux ってのは x86_64 向けであり, ARM 向けは ALARM の範疇って話があり, そして Apple Silicon が登場するまで ARM でデスクトップ的に使えるのは精々 Raspberry Pi 4 とかその辺しか無かったというのがあり... ↩︎
ダイマ: https://qiita.com/Nanai10a ↩︎

Nanai10a 1ヶ月前に更新

linux-asahi 及び mesa-asahi-edge を最新に追従させる為に PKGBUILDs^[1] にパッチを当てていたのでその記録.

大前提：環境構築

カーネルビルド時には必ず Rust サポートを入れなければなりません^[3]. ですので makepkg する前に今の環境で Rust がカーネルビルド向けに使えるのか確認をしましょう. ちなみに特に意識してなければ十中八九使えません.

ビルド対象とするカーネルソースを展開した直下に移動します. 例えば asahi-6.6-15 のソースを落として展開します. ここで make rustavailable を実行します^[4].

期待される出力はこれです. これになる必要があります.

alarm% make rustavailable
Rust is available!

出力を見てよくわかんねえなと思った場合はこちらを参照して下さい.

Rust に慣れてる場合はこうお伝えすれば解決出来るでしょう.

cd <カーネルソースのディレクトリ>
rustup override set <期待されるバージョン>
cargo install --version <期待されるバージョン> bindgen-cli

また bindgen を pacman で入れている場合は $PATH で競合する場合があります. これの対処案は取り敢えず 2 つあります.

extra/rust-bindgen を remove して makepkg の出すエラーを --nodeps で無視する
$PATH の結合順を変えて, ~/.cargo/bin を優先するようにする

`linux-asahi` のパッチ

ここでは asahi-6.5-15 から asahi-6.6-15 への更新を考えます.

_rcver で元のカーネルのバージョンを指定します.

PKGBUILD

-_rcver=6.5
+_rcver=6.6

_asahirel でハイフン以後のバージョンを指定します. 今回は変更ありませんが.

PKGBUILD

 _asahirel=15

Asahi Linux が公式で提供しているリポジトリのパッケージと共存する為に名前を変更します. 置き換えたい場合はこの手順は不要です.

PKGBUILD

-pkgbase=linux-asahi
+pkgbase=linux-asahi-new

あとこれも.

PKGBUILD

 echo "Setting version..."
+echo "-new" > localversion.06-new
 echo "-$_asahirel-$pkgrel" > localversion.10-pkgrel

そしたらチェックサムを更新しましょう. 一番楽なのは, 一旦 makepkg を実行してカーネルソースを落としてから, 整合性チェックが落ちて異常終了した後に updpkgsums^[5] することです. そうでない場合は... 頑張って編集してください.

そしたら後はビルドして導入して GRUB の設定更新しておしまいです. 導入時には makepkg -i を使った方が楽だと思います. 3 つのパッケージ^[6] をわざわざ pacman -U で指定する利点って無いと思いますし.

`mesa-asahi-edge` のパッチ

ここでは mesa-asahi-20230904 から mesa-asahi-20240214 への更新を考えます.

やることは超単純. _asahiver を使いたい日付タグに合わせるだけ.

PKGBUILD

-_asahiver=20230904
+_asahiver=20240214

あとは先に述べたチェックサムの更新をしたら makepkg しておしまい. こちらも makepkg -i を使えば 3 つのパッケージ^[7] をまとめて導入できます.

注意ですが, これのビルドより先に linux-asahi をパッチしたものを導入して起動することをおすすめします. 古いカーネル上で最新の mesa-asahi-edge をビルドしても上手く動かなかったと記憶しています. 必要なカーネルの機能が有効じゃなかったとかそういうオチかもしれませんが...

脚注

https://github.com/AsahiLinux/PKGBUILDs ↩︎
検証が足りていない為断定は出来ない. 前は動いた気もした… ↩︎
Asahi Linux の推奨する config に Rust の有効化が盛り込まれているので. wiki の Kernel config notes for distros などを参照 ↩︎
流石に make が無いとか無いよね...？ core/make で提供. 一般的には base-devel での導入を推奨 ↩︎
extra/pacman-contrib にて提供. ↩︎
linux-asahi, linux-asahi-edge, linux-asahi-headers ↩︎
mesa-asahi-edge, mesa-asahi-edge-debug, vulkan-swrast-asahi-edge ↩︎

Nanai10a 1ヶ月前に更新

paru という AUR helper / Pacman wrapper があります.

https://github.com/Morganamilo/paru

最近知ったのですが, これには任意の "PKGBUILD repository"^[1] を設定し運用できる機能があるようです. それによって, 自分でカスタムしたり bump したり新しく作った package を気軽に公開^[2] (GitHub など) した上で paru / pacman による管理下に置くことが出来ると考えました. そんな私は今まで書いたことのない PKGBUILD^[3] 執筆 (？) に当たって参考にしたり考えたことについて書き置きします. ~~でもこれ Asahi には直接関係ねえなとは思います.~~

まず大前提として PKGBUILD の書き方を知らないので聖書^[4] を参照することから始めました. あとは core/linux (x86_64) 辺り程度に複雑な PKGBUILD も参照すると参考になります. あとは同じ言語を扱う package のお作法を既存の PKGBUILD を参照してみるとか. 例えば Rust^[5] の aur/dust-git^[6].

https://spdx.org/licenses/

言わずと知れた SPDX license identifer ですが, license= に指定するライセンス名の形式はこれ になり始めた^[7] ようです. GitHub や GitLab といえ, これを完全に網羅しているわけではない且つ UI 上で SPDX license identifer を確認できる機能はないので, LICENSE とにらめっこして適切なものを探すようにしています.

https://guide.bash.academy/expansions/

Bash は現在のデファクトスタンダードな sh として有名ですが, Arch のインフラはこれにべったりな面があります. ABS^[8] も例外ではなく, PKGBUILD は formal なだけの Bash スクリプトです. 逆に言えば PKGBUILD 内では Bash 独自の拡張機能が使えるわけで, そこらの PKGBUILD を漁り見ると特に変数展開構文^[9] はかなり活用されている印象でした. でそれを目の当たりにした私はこの構文を未履修だった^[10]のでこのサイトとにらめっこしながら色々試してました. 未履修の方にはおすすめしますし, 履修済みの方もチートシートとして使ってみるのはいかがでしょうか.

これは私も追々って感じですが, Arch には package guideline という PKGBUILD の書き方等に関する作法があります. ただ, あくまでも AUR に投稿しない以上これを厳守するつもりはありません. これを厳守しようとすると折角 AUR から離れて自分の PKGBUILD repository を立てても遵守が面倒で及び腰になってしまうからです. ただ, Arch 周辺のコミュニティではこういった作法を個々がよく意識することで品質の向上^[11] に役立てていると私は思うので, 出来る限り従っておきたいなーとは思っています.

https://github.com/AsahiLinux/PKGBUILDs

そもそもですが多分そのまま運用できるであろう PKGBUILD repository が Asahi にはあります. ビルドしたものを公開する mirror が立っているので規定ではそちらから package を導入することになるでしょうが, それが古く保守されてない^[12] から困ってこんなことしてるんですよね. ですからこれを置きかえるのが現在のモチベーションです. 万人向けではなく私のしたいようにカスタムもする見込みですが.

とは言いつつも貴重な PKGBUILD なのでよく読んで (時には引用して) 上手くやっていきたい. あとこれは有益情報ですがコレの fork や Pull Requests に先駆者のパッチが紐付いています. Asahi の upstream へ merge されない以上, 敬意を示しつつ私の PKGBUILD へ取り込む他ないなみたいな気持ちに…

そんな私の PKGBUILD repository はこちら (ダイマ). 充実させていきたい.

https://github.com/Nanai10a/nra

脚注

分かる人向けに言えば, "カスタム AUR" みたいな感じ？ ↩︎
AUR に公開すると容易に Arch 遣いの手に渡るので責任が (自己責任とは銘打っても流布される事実は変わらないわけで...) 生じる上, そもそも ALARM 向けの package を x86_64 向け distri である mainstream Arch 向けに (arch=(aarch64) 指定だとしても) 公開するのは何か違うなーというもやもやを抱えていました ↩︎
https://wiki.archlinux.org/title/PKGBUILD ↩︎
ArchWiki のこと. 宗教的な意味合いがあるわけじゃない...よね？ https://wiki.archlinux.org/ ↩︎
Asahi は積極的に Rust を使うので, sh の次にメジャーな記述言語が Rust ...だと思います (主観) ↩︎
Package Actions の View PKGBUILD から閲覧できます. また, これは VCS^[13] package と呼ばれるもので少し特殊な package ではあります https://wiki.archlinux.org/title/VCS_package_guidelines ↩︎
厳密にはまだ移行中らしい. 執筆時現在はそういった記述が wiki にある https://wiki.archlinux.org/title/PKGBUILD#license ↩︎
https://wiki.archlinux.org/title/Arch_build_system ↩︎
正しい言い回しが分かりません ↩︎
これでも私 zsh 信者 (という割に使ってるだけのエセだけど) な上 "拡張" って嫌いで, 且つ POSIX 互換以外の機能にあんま好印象を持っていなかったので, "Bash 独自の拡張？知るかそんなもん！拡張に頼りだしたら移植性もクソも無ぇだろうが！" と頑なに履修していませんでした. ちなみに字面通りの過激な感じではなく, ふんわり懐疑的な気持ちってだけです ↩︎
品質というのは formal ってだけでなく, 例えば ABS の仕様上で効率的とされる方法を採るとか, 少ない労力でより良く保守されるようにするだとか, 読みやすく他者と共有しやすい形にするだとか, 色々… ↩︎
少なくとも Fedora Asahi Remix に比べれば保守は放棄されているも同然だと思っている ↩︎
Version Control System ↩︎

Nanai10a 1ヶ月前

Fedora Asahi Remix は Asahi Linux 公式が唯一サポートする distribution です. また, Asahi Linux プロジェクトにおける最新の成果もこれにのみ反映されます. 関連するソフトウェアのソースコード他は GitHub やらで公開されていますが, 導入手順なんかはドキュメントされていないことが多いです. そして当然 ALARM 向けには更新されません. ですから Fedora Asahi Remix 向けのビルドスクリプトやらなにやらを参照すれば解決策が見えてくるのではないかという, そういうことです.

https://pagure.io/group/fedora-asahi

前者はビルドシステム, 後者はソースコードリポジトリです.

特に @asahi/mesa / fedora-asahi/mesa は見ています. ただ, 原文の spec は読みづらいのでその実行結果であるビルドログを読んでみたりもしています. ビルドログには実行されたコマンドも載っているので, 結果論としては分かりやすいという感じです.

Nanai10a 1ヶ月前

Asahi Linux 周りの設定は色々と難儀なもので, 従来のツールがそのまま運用できないケースが存在します. 最たる例は efivarfs でしょうか, そもそも UEFI で一元管理されている訳ではない^[1] ので, 例えば
efibootmgr を使っても従来のマシンのような有意な操作が出来ません. そういった Asahi Linux 固有のテクニック^[2] について述べられている場面は少ないです. ですので, これについて言及されている場面を集めてみています.

https://github.com/AsahiLinux/docs/wiki

他の何よりも熟読すべきもの.

Fedora Asahi Remix の前身…という訳でもないユーザーによる Fedora インストールのためのリポジトリですが, これの README にユーザスペースで有用な情報が多く書き記されています. 例えば, 起動時の音を消音する方法など.

脚注

iBoot から m1n1 を経由して U-Boot が UEFI をエミュレートしているので, つまりそこらのマシンにおける UEFI は Apple Silicon マシンの iBoot に相当し, iBoot は UEFI とは別物です. ↩︎
ハックではない. どちらかというと固有の, 共通化されていない技術というだけ ↩︎

Nanai10a 27日前

Asahi Linux がスピーカーのサポートをしたのは比較的記憶に新しいですが, これを有効化するには少し手間が要ります. 正確に言えば "不要に有効化して使用するとハードウェア的損傷を与える可能性があるので無効化されている" という所ですが, それはそれとして使いたいものが使えないのは困ります. あくまで自己責任ですが, Asahi Linux のスピーカーに関する備忘録です.

PipeWire と WirePlumber 向けの設定ファイル群です. これを動かすためには色々必要なものがある^[1] わけですが, つまるところスピーカー周りのトップレベルのモジュールに相当します.

Rust で書かれたスピーカー保護デーモン. 詳しいことは知りませんがとにかく危ねえ入力から保護するための実装だそう. 逆に今まで使っていたスピーカーはどうやって保護されていたのか気になる所…

https://github.com/chadmed/bankstown

Rust で書かれた低音強化 LV2 プラグイン. その, 実際に Asahi Linux を使うと分かるのですが, macOS の DSP はかなり強力で, 比喩抜きで魔法の様な感じがします. これを再現する…とかではありませんが, 少なくともチープ過ぎる音からグレードアップさせる DSP をしている, のだと思います.

ALSA UCM の設定. 詳しくは知りません…

さてここから本筋です. スピーカーのドライバは当然カーネルソースに含まれていますが, この中でスピーカーは全て無効化された状態になっています. このままビルドしても当然使うことはできません. しかし Fedora Asahi Remix 他で使うことができますが, これは何故か？

ここを変更する必要があります. 1 列目の真偽値が false であれば必ずスピーカーは無効化されるようになっています.

親の顔程みたエラーメッセージがこんなところに…

asahi-diagnose より, 私の使っているモデルは…

## Device information
    Model:          Apple MacBook Pro (16-inch, M1 Pro, 2021)
    Compatible:     apple,j316s apple,t6000 apple,arm-platform

J316^[2] ですので, 少なくともその設定は有効化する必要があります.

そしてここに Fedora Asahi Remix で使われているカーネルソースがあります^[3].

コミット履歴を見ていくと, 以下のような 2 つのコミットが見つかります.

macaudio: Enable first round of models
macaudio: Enable second round of models

例えばこのような.

さて, 私は別に Asahi Linux の専門家ではないので, 何が危険たらしめ且つ安全たらしめるのか解りません. ですので GitHub の AsahiLinux/linux に上がっているカーネルソースと GitLab の fedora-asahi/kernel-asahi で差分を取り, それらしい変更が無さそうであればパッチを抽出して適用してやろうと考えました.

パッチを抽出する過程は端折るとして, 何故コミットの差分を流用しないかといえば, 当然その macaudio.c の他の部分にも変更が加わることがあるからです. てか変更があります. 何なんですか (八つ当たり). ですから安直に true を書き込むより公式でサポートされているソースにきちんと従っておくべきかなという思考です.

パッチ適用自体は AsahiLinux/PKGBUILDs の PKGBUILD でもプロセスが組まれているので, パッチを作ったら PKGBUILD と同じ階層に置けば勝手に適用されます.

最後にですが, asahi-diagnose は定期的に実行しましょう. もしもスピーカー周りで危険な設定が存在する場合, これを検出して報告してくれます. 例えば, こういうページへ案内してくれたりします.

脚注

ちなみに, これを網羅する意図はありません ↩︎
j316s って何すか？これ, 末尾の s って無視して良いよね…？ ↩︎
余談ですが, fedora-asahi/rust-kernel の description には "This is a fork of the Fedora Rust package for building kernel." とあります. ここから辿り着きました… ↩︎

Hidden comment

大前提：環境構築

linux-asahi のパッチ

mesa-asahi-edge のパッチ

`linux-asahi` のパッチ

`mesa-asahi-edge` のパッチ