Qbilinux 日記

Linux に関係することだけではなく,最近は一般的なコンピュータやガジェット関係についても記載してます.

Mac mini 2018 (2020) のメモリを交換して 64GB に

先日購入した Mac mini 2018 (2020) のメモリ交換を行ってみました.

といっても詳細な手順は下記に記載がありますので省略します.

jp.ifixit.com

必要な工具類は上記のホームページに記載されていますが,TR6, T6, T5, T10 あたりのトルクスレンチと裏蓋をこじ開けるための工具って感じでしょうか?私自身はちょっと前に購入した下記のものを使っています.

 あと,使った交換用のメモリは秋葉館のホームページなどでも crucial のものが良いよみたいな記載があったので crucial の CT2K32G4SFD8266 を購入してみました.過去,デスクトップ Mac のメモリ交換はいろいろと行いましたがあんまり相性が悪かったことに当たったことがないので普段は気にしないのですが,今回は業務用に使うということで値段よりも信頼性を重視しました.

f:id:toshi-mtk:20210112010134j:plain

上記に挙げたメモリ交換方法が記載されているホームページに基づいて作業を行いましたが,Mac mini 2012 などに比べるとずいぶんと面倒になっている印象ですね.元々,ユーザーによるメモリ交換を想定してないので当然かな.

と言う感じで,サクッと交換してちょっとドキドキしながら電源オン.

無事,64GB になりました.ふう.

f:id:toshi-mtk:20210112010720j:plain

けど,CPU は i3 なのでオーバースペックな気もしますけど,仮想環境などを割とよく使いますのでそのためかなという感じで 64G までしてみました.このスペックなら最後の intel Mac として長い間使えるかなぁと言うことで.

OS が Mojave になっているのは,購入時からダウングレードしたためですが,方法は気が向いたら後日記載します.購入時には Catalina がインストールされていました.はい.

まぁ,簡単ですけどそんな感じです.

Qbilinux 開発について(その57): 色々とパッケージ更新

ぼちぼちと Plamo Linux 6.x のソース一式からブランチして,Qbilinux という linux ディストリビューションを作成.

いつまで続くのか.

いじってる Qbilinux のホームページは https://qbilinux.org/ に,ビルドスクリプトは https://github.com/qbilinux/qbilinux,バイナリは https://qbilinux.org/pub/ 以下にあります.

年末年始にインストーラーをいじる前にしていた作業の概要でも.

ここ最近はセキュリティフィックスを中心に修正していたんだけど,つい KDE とかのアップデートに手を出したり.ついでに Qt も更新したり.emacs も新しいのが出たので差し替えたり.

そうしているうちに泥沼にはまって言ってしまったのでした.

ことの発端は Gnome.

KDE をアップデートしたついでに Gnome も新しいものが出たので同梱しようかなと思ってしまったのが沼の始まり.

これまで収録していた Gnome 関連のモジュールをアップデートするのはそれほどトラブルなく終了.

で,Gnome を立ち上げるために追加で必要になるパッケージ類をコンパイルしていたのですが,エラー続出.kerberos 関連でいろんなものが定義されていないってエラー.これまでは Plamo からの流れで heimdal を使っていたんだけど,どうやらこれが原因みたい.少し調べてみた感じ,他のディストリビューションのビルドスクリプトを見てみても heimdal だとダメだから...みたいなコメントがあるし,根本的にダメっぽい.

ソース修正することも少し考えたけど,手間がかかりそうだしあんまりよくわかってないので,heimdal から MIT Kerberos への載せ替え作業をすることに.

手元で kerberos 認証は使っていないので一時的に設定ファイルは後回しにしてヘッダファイル,ライブラリだけ差し替えてみたら,案の定,heimdal ライブラリをリンクしているバイナリ類が全滅....

それらのバイナリを全部作り直し....

という状況で大幅な入れ替えが発生してしまったのでした.

途中でまずいことになってしまったなぁとは思ったんだけど,引き返す手間と進む手間を考えて結局載せ替え作業を進めることにしたのでした.

けど,そうやって苦労して作成した Gnome 環境もなんか挙動が怪しいので,現時点では収録パッケージから外しています.まぁ,今後の課題かなぁと言った感じで.

そんな感じで,少し前にパッケージ入れ替えを大幅に行った話でした.

手元で使っている Realforce キーボードのキートップを交換してみた

過去にも同じような記事を書いたことがありますが,似たような内容です.過去の記事はこの辺りかな.

toshi-mtk.hatenablog.com

最近,使っている Realforce キーボードのキートップがちょっと汚くなってきた.

取り外して洗剤で洗ったりアルコールで掃除すれば良いだけなんだけど,ふと「遊舎工房」さんのホームページを見たら Realforce 用の色々なグッズを販売しているのを発見.

yushakobo.jp

HHKB 用の交換キートップの他にも HHKB/Realforce に cherry キートップをつけるための部品なんかも販売しているね.

yushakobo.jp

cherry キートップをつけるための MX 軸への変換部品の詳細を見てみると,一回キーボードをばらさないとダメみたい.手元の Realforce はまだ購入してそれほど時間経ってないし,分解するのはもう少しぼろぼろになってからにしたいなと思ったので,キートップを購入してみることにしました.

選んだキートップは「KBDFANS EC9009 HHKB KEYCAPS SET」ってやつ.

yushakobo.jp

HHKB 用の余計な表記がない方が良いかなということでこれを選んでみました.ただ,テンキー表示がなくなるんだけど,まぁそれは良いかなということで.テンキー表示って言うのはちょっと説明しにくいんですが,通常キーボードをテンキーとして買う場合のためにキーボード側面にテンキーが印字してある表記のことです.

通販で購入しましたが,注文の翌日に発送の連絡が来てその翌日くらいに配送されました.

で,パッケージ.中華製っぽい.

f:id:toshi-mtk:20210110201726j:plain

中身.

f:id:toshi-mtk:20210110201731j:plain

f:id:toshi-mtk:20210110201736j:plain

ふむふむ.

交換前のキーボードはこんな感じ.

f:id:toshi-mtk:20210110201743j:plain

手元に転がっていたキートップ引き抜き工具を使ってキーボード交換.

f:id:toshi-mtk:20210110201754j:plain

f:id:toshi-mtk:20210110201804j:plain

互換キートップなのであとはパチパチとはめていくだけ.

完成.

f:id:toshi-mtk:20210110201809j:plain

全てを交換したわけではなく,アルファベットとスペース・リターンだけ交換してみました.

交換した印象ですけど,キートップを交換するだけでもやっぱりキータッチは変わりますね.オリジナルよりも若干軽い感じがします.

ただ,黒から白に変更したので見た目でそう感じるだけかもしれませんが.:-)

見た目もきれいになったし,割と良い感じで気に入ってます.

あ,一部キーボードがオレンジなのは Realforce 用の日本語キーボード用のキートップを使って一時期交換していたためです.そのあたりが気になる方は冒頭に挙げてある過去のブログ記事をみてください.

取り外したオリジナルキーボードは掃除してから保管しておいて,気が向いたときに再び交換するなどしたいと思っています.

簡単ですけどそんな感じです.はい.

 

ARCHISS キートップ引き抜き工具 Ergo Grip Keycap Remover AS-KREGP01

ARCHISS キートップ引き抜き工具 Ergo Grip Keycap Remover AS-KREGP01

  • 発売日: 2017/01/05
  • メディア: Personal Computers
 

 

Qbilinux 開発について(その56): 使用しているソースファイル一式の整理

ぼちぼちと Plamo Linux 6.x のソース一式からブランチして,Qbilinux という linux ディストリビューションを作成.

いつまで続くのか.

いじってる Qbilinux のホームページは https://qbilinux.org/ に,ビルドスクリプトは https://github.com/qbilinux/qbilinux,バイナリは https://qbilinux.org/pub/ 以下にあります.

公開しているファイルを整理しているのでちょっと注意書きを書いておきます.

https://qbilinux.org/pub/source/ 以下に Qbilinux 一式をビルドするために使っているソースも置いてありますが,ファイルの整理を行いました.使用しているサーバーのハードディスク容量が逼迫しているためです.ハードディスクを増やせばいいんですけど,費用が....

ということで,現在は current をビルドするためのソースだけを置くようにしましたのでご注意ください.current には含まれていない kterm などのソースは削除しました.

ファイル自体は手元には残してありますので,ソースファイルがどうしても必要なんだけどというものがあれば連絡等いただければ置くようにいたします.

ただ,普通にネットに転がっているファイルを集めているだけなので,あまり需要はないかもしれないですが,もしこのディレクトリを参照している人がいるかもしれないなぁということで一応連絡でした.

あれ,一部,手元で少しいじって再パッケージしたものもあるかもしれないけど,まぁ,それらのファイルは消していないので大丈夫かなと思います.

そんな感じです.

Qbilinux 開発について(その55): インストーラ周り触って久しぶりにインストーラーイメージ作成

ぼちぼちと Plamo Linux 6.x のソース一式からブランチして,Qbilinux という linux ディストリビューションを作成.

いつまで続くのか.

いじってる Qbilinux のホームページは https://qbilinux.org/ に,ビルドスクリプトは https://github.com/qbilinux/qbilinux,バイナリは https://qbilinux.org/pub/ 以下にあります.

ひさしぶりのブログ更新.

つい忙しくなってしまうと,更新がおろそかになってしまいます._o_

年末年始に少し余裕ができた時間を使ってインストーラーを更新中.

gihyo でこじまさんが行なっている Plamo に関する連載とか debian とか arch のインストーラ関係の文章を参考にして色々と試行錯誤.

なかななむづかしい.

virtual pc を使って動作チェックしていたんだけど,ブートに失敗しててどうしてなのかなぁと悩んでいたんだけど,実機で動作チェックしたら問題なかったりとか.virtual pc 用のデバイスドライバが組み込まれていないだけなのかな?

また,iso ファイルを usb メモリに書き込んでブートすると efi でうまくブートできなかったり.xorriso のオプションが問題みたいだけど,どうすればいいんだろう.

あとは nvme のパーティションがうまく認識してくれなかったり.デスクトップだとうまく認識できないんだけど,Thinkpad X270 を使うと普通に認識できてるので kernel の config が問題なのか?

まぁ,色々とありますが,新しい x86_64 用のインストーラーイメージを作成して https://qbilinux.org/pub/isos-current/qbilinux-0.4a3_x86_64_20210104_dvd.iso に置きました.

iso-current ディレクトリ以下においてあった古いファイルはあんまり意味がなくなったかなと思って削除しました.

新しい iso ファイルですがファイルサイズが 5.2G くらいあるので1層 DVD には入りきりません.はい.

一部,パッケージにちょっと不具合はあるけど,手元のデスクトップに新規インストールできることは確認してあります.色々問題あるので説明しているドキュメントなしにインストールするには難易度は高いかと思いますけど.

前回のバージョンからかなり日数が空きましたし,不具合のあるパッケージと iso ファイル作成コマンドの調整ができれば一旦締めることにしたいと思っています.ちょっと綺麗に整理したいなと思っていたけど,キリがないかなぁとも思うのである程度妥協するしかないかな.

とりあえず今月末くらいをめどにできれば良いかなと思っています.

容量も DVD の容量を超えてしまっているので,USB メモリ用のインストールイメージだけにしようかなということも考え中だったり.

前回の blog 記事を書いた時から,収録パッケージ周りも相当いじってますが,それらに関しては気が向いたら後日書きます.git の方の log を見ればある程度はわかるかなぁとは思いますけど....

最近の作業はそんな感じです.

いまさらながら Mac mini 2018/2020 を注文

最近,CPU が変更になった新しい Mac mini が発売されましたね.

ARM な Apple M1 プロセッサに変更になったやつです.

ちまたの状況を見ているとなかなか評判はよさそうですね.

ベンチマークは現行の intel 版を凌駕してるみたいだし,メモリ効率もよさそうだし,発熱もしないらしいし.

少し前から新しい Mac を調達しようかなと思っていたのですが,ARM 版を出すって発表があったからしばらく待っていたんですよね.

で,状況を一通り見た状況で,結論はタイトル通り 2020 (2018) 版の intel Mac mini を注文しました.スペックは Core i3, メモリ 8G, SSD 256GB.2020 モデルの吊るし最安モデルかな.中古ではなく新品.購入価格は77,000円くらいかな.

M1 な Mac mini と比べて数千円安いくらいだけど.^^;

どうして intel を選んだかっかというと,

  • すぐに開発用などの作業にがっつり使いたい.
  • M1 が評判が良いとは言いつつ,やっぱり色々とトラブルは出ている様子.
  • メモリの選択肢が 8/16G しかないけど,いろんなアプリでの ARM 対応した時のメモリ状況がまだ不明.
  • アップル製品の新しい製品の場合,切り替わった後の 2番目に出てくるものが改良されてかなり良いものになる場合が多い.

などという理由です.

Mac mini 2020/2018 を選んだのは

  • MacBook 12inch 2016 を持っているのでノートではなくデスクトップが良かった.
  • 場所もないし,モニタは今使ってるやつでよいので iMac は不要.
  • Mac Pro は値段高杉.
  • メモリ増設が自由にできる.
  • USB な SSD などを使えばストレージも自由.
  • 手元でいまだに使っている Adobe CS6 もまだ動作する.

な感じ.

Core i3 にしたのは

  • そうはいっても,やっぱり ARM 版に置き換わっていく過渡的な状況なので費用はかけないほうがいいかなと.
  • 第8世代 intel Core シリーズなのでベンチマーク上では Mac mini 2014 の i7 モデルより早い(らしい).

な感じかな.

最初は Mac mini とか iMac の中古もいろいろと調べてみたんだけど,スペックの割に高いなぁという印象もあったので.

それなら新品のほうが少し値段は高いけどいろいろな保証もつくし良いかなぁと.

Mac mini i3 モデルが残っているのは現在の流通在庫のみなので決断を早くしないとな,という理由もありましたね.

2年程前くらいまで,Mac mini 2014 i5/8G/1T を使っていましたが,性能的にはそれほど不満はなかったし,まぁこれで良いかなと.手元にある Macbook 12inch 2016 では本格的に開発につかうのはちょっと辛かったので.

今更2年前のモデルだけど,諸事象により届くまでに少し時間がかかる状況.ちょっとワクワクかな.

...他にも,仕事用に MacBook Pro 13inch 2020 第8世代i5 なモデルも手元に転がってるのは内緒.借りものなので自分のものじゃないのでね.この子は i5/32G/1T なんだけど,キーボードは新しいので良いんだけど,ちょっと負荷かけるとファンが全開になって,あんまり(ry

とりあえずそんな感じです.

 

linux kernel 5.4 用の utf8 漢字コンソール対応パッチ (cjktty patch)

先日,linux kernel 5.9 用の utf8 漢字コンソール対応パッチの話を書きましたが,ついでに LTS でもある 5.4 用のパッチも手元で修正しておきました.

ざっと ls などで日本語が表示される程度は確認してあります.

ファイル一式は https://github.com/qbilinux/qbilinux/tree/master/qbilinux/00_base/kernel 以下においてあります.

例のごとく,Qbilinux のパッケージビルド環境用になっています.

そんな感じです.

linux kernel 5.9 用の utf8 漢字コンソール対応パッチ (cjktty patch)

linux のコンソール画面で utf8 の日本語を表示するために,これまで gentoo あたりでメンテされているパッチ (https://github.com/Gentoo-zh/linux-cjktty) を使っていましたが,最近の kernel では reject が出るようになっていますね.

どうやら kernel からソフトウエアのスクロールバック機能がドロップされて,その影響みたい.

最新カーネルだけではなくってそのパッチが LTS にも適用されているようなので,5.4 系でも最近の kernel では reject が出るようです.

で,仕方ないなと思ってソースコードをざっとチェック.

drivers/video/fbdev/core/fbcon.c 中にあったソフトウエアのスクロールバック機能がごっそりなくなっているだけで,それ以外はあんまり変わっていない雰囲気.fbcon_update_softback / fbcon_redraw_softback / fbcon_softback_note / fbcon_scrolldelta 関数なんかがが削除されて,関連記述に変更が入っている感じか.

そのあたりに適用している箇所だけを削除すればよさそうなのでざっと作業.そんでもってコンパイル.

コンパイルしてるときに,ほかに作業している人がいないのかなぁとちょっと検索したら色々出てきた.

5.9 用のパッチを作られている方もいらっしゃったようなので,その中身を見てみましたが,手元で作業したのと同じ方法で修正している感じですね.コンパイル途中でしたが,手元でデバッグするのも面倒かなぁということで,その方のパッチをもらってくることにしました.gentoo からブランチして修正したって書いているので,権利関係も問題ないかなぁと.

でも,個人的にはそのままでは使えないので,これまで使っていたのと同じ形に修正してコンパイル & 差し替えて動作チェック.

数分触ったくらいだけど,問題なく動作している雰囲気だね.

f:id:toshi-mtk:20201108150354j:plain

ということで,作成したパッチ,コンパイル環境一式を https://github.com/qbilinux/qbilinux/tree/experimental/experimental/kernel59 以下においておきました.

github.com

個人的に作成している Qbilinux ってディストリビューション用のビルドファイルになっているのでご注意を.現状では experimental branch 以下に置いてありますが,そのうち master brnach の方にマージします.

とりあえず,気分転換に久しぶりにカーネルソースをいじってみた話(?),linux kernel 5.9 用の utf8 漢字コンソール対応パッチをいじってみた話でした.

Qbilinux 開発について(その54): kvm/libvirt 回りをいじったり一部動作しないパッケージをいじったりしながらインストーラも


ぼちぼちと Plamo Linux 6.x のソース一式からブランチして,Qbilinux という linux ディストリビューションを作成.

いつまで続くのか.

いじってる Qbilinux のホームページは https://qbilinux.org/ に,ビルドスクリプトは https://github.com/qbilinux/qbilinux,バイナリは https://qbilinux.org/pub/ 以下にあります.

前回,これからはインストーラ回りを...といいつつパッケージの方の作業をしていたりします.

とりあえず,ずっと気になっていたので perl/python まわりの整理とか.python2 っていつになったら削除できるのかなぁ?

他には,一部,うまく動作しないなぁと思いつつ放置していたパッケージ類をきちんと動作するように整理したり.

2ch ビューワーまわりのパッケージを同梱していましたが,全く動作しない状態でした.今回,一通り環境を整備したので,その辺りの環境もきちんと動作するようになりました.jdim と 2chproxy が qbilinux-cuurent では普通に動作するようになっています.ただし,2chproxy はデフォルトで 8080 ポートを使いますが,8080 ポートをほかの用途に使うようにしている場合には 2chproxy の方の設定変更などが必要になりますけどね.

ついでに気分転換として kvm/libvirt 回りのパッケージもいじってみたり.

virt-manager が動作する程度にパッケージを作成してみましたが,なんだか動作が怪しい.

暇をみて調整してみますが,時間がかかりそうなら同梱するのは先送りするかもです.はい.

...

で,インストーラの方のはなし.

以前は EFI 環境で動作していたはずなんだけど,いつのまにか動作しなくなってました.なぜそうなったのか不思議なんですけど,パッケージを更新している途中で何か環境を壊してしまったのかなぁ?

ということで,復習を兼ねて Plamo Linux で実装されているインストーラー動作まわりの仕組みなどを,こじまさんが gihyo で書いているドキュメントとかをみてもう一度確認中.

gihyo.jp

平行して,arch linux のドキュメントなんかもチェックしたり,先日購入した ThinkPad X270 に debian をインストールして debian では EFI 回りのインプリがどうなっているのかなを確認したり挙動とか実装のチェックをしてみたり.

きちんと作ろうとすると色々と面倒なことがありそうですね.署名の話とか....

最終的にどこまで対応するかは置いておいて,とりあえず必要最低限だけ動作するレベルに持っていきたいなとは思っていますので,色々と調べつつ作業を進めていく感じ.

とりあえずそんな感じです.はい.

docker + qemu で raspberry pi の開発環境構築

個人的に Qbilinux ってディストリビューションを作成しています。その環境の上で色々な作業をしてますが,ARM の開発環境をもっと効率の良い物にでないかなぁっと昔から思っていました.

過去,クロスコンパイラを作ってみたり,qemu 上で動作させてみたり.

で,今回,Qbilinux 上で docker が動作するようになったので,docker 上に ARM 開発環境を構築できないかなと思い立ち.

少し検索してみたところ,下記のページを発見.すばらしい.

qiita.com

元ネタはここらしい.

blog.guiraudet.com

ふむふむ.

とりあえず,最初はドキュメント通り試してみようかなということで raspbian を使って上記説明のとおりに作業してみました.日本語のページでは docker 上の debian で作業していますが,手元に linux 環境があるので,static な qemu バイナリだけを拾ってきて,普通に linux 上でゴニョゴニョと作業.static な qemu イメージの有る場所は http://blog.guiraudet.com/raspberrypi/2016/03/03/raspbian-image-for-docker.html の方に記述されているものを拾ってきました.

作成したイメージを docker に登録してドキドキしながら実行.....うまく動作しない.^^;

$ docker run --privileged -it raspbian-x86_64:20200213 /bin/bash
standard_init_linux.go:211: exec user process caused "exec format error"

と出てダメ.

うーむ.何でだろう?

いろいろと調べてみたところ,https://github.com/multiarch/qemu-user-static があって,ここにあるドキュメントによると

$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes

で直るらしい.ってことで実行.

無事実行できるようになりました.ふう.

$ docker run --privileged -it raspbian-x86_64:20200213 /bin/bash
root@9f9ad0a61de9:/# uname -a
Linux 9f9ad0a61de9 5.4.50-x64 #1 SMP Sun Jul 5 09:45:28 JST 2020 armv7l GNU/Linux
root@9f9ad0a61de9:/# arch 
armv7l
root@9f9ad0a61de9:/#

multiarch/qemu-user-static って何なんだろう?って思ったら https://github.com/multiarch/qemu-user-static のページの下の方に説明がありました.

とりあえず,raspbian が動作したので,今度は本命の自分で作ってる Qbilinux 環境を動かせないか試してみました.

Qbilinux verion 0.3 の aarch64 用の SD カードイメージを https://qbilinux.org/pub/isos/qbilinux-0.3_aarch64_sd.img.xz に公開しているので,それを unxz して圧縮展開.ld.so.preload は使っていないので修正は必要ないかな.で,raspbian の時と同様に qemu を同梱.

それを tar でかためて docker にイメージを登録.

ドキドキしながら実行.

$ docker run -it --privileged qbilinux-aarch64:0.3 /bin/bash
root@4ab972979376:/# uname -a
Linux 4ab972979376 5.4.50-x64 #1 SMP Sun Jul 5 09:45:28 JST 2020 aarch64 GNU/Linux
root@4ab972979376:/# cat /etc/qbilinux-release 
qbilinux release 0.2
root@4ab972979376:/# arch
aarch64
root@4ab972979376:/#

あっさり動作しました.:-)

CPU やメモリはこんな感じで見えます.

root@4ab972979376:/# cat /proc/cpuinfo       
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 23
model           : 17
model name      : AMD Ryzen 5 2400G with Radeon Vega Graphics
stepping        : 0
microcode       : 0x810100b
cpu MHz         : 3428.868
cache size      : 512 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
cache_alignment : 64
address sizes   : 43 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate eff_freq_ro [13] [14]

- snip -

processor       : 7
vendor_id       : AuthenticAMD
cpu family      : 23
model           : 17
model name      : AMD Ryzen 5 2400G with Radeon Vega Graphics
stepping        : 0
microcode       : 0x810100b
cpu MHz         : 1355.281
cache size      : 512 KB
physical id     : 0
siblings        : 8
core id         : 3
cpu cores       : 4
apicid          : 7
initial apicid  : 7
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid
 extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca
bugs            : sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips        : 7186.50
TLB size        : 2560 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 43 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate eff_freq_ro [13] [14]

root@4ab972979376:/# cat /proc/meminfo 
MemTotal:       16346912 kB
MemFree:          776184 kB
MemAvailable:   13863160 kB
Buffers:          693456 kB
Cached:         11844408 kB
SwapCached:            0 kB
Active:          6330576 kB
Inactive:        8169764 kB
Active(anon):    1689744 kB
Inactive(anon):   427304 kB
Active(file):    4640832 kB
Inactive(file):  7742460 kB
Unevictable:        9340 kB
Mlocked:            9340 kB
SwapTotal:      33554428 kB
SwapFree:       33554164 kB
Dirty:               588 kB
Writeback:             0 kB
AnonPages:       1971972 kB
Mapped:           606052 kB
Shmem:            178796 kB
KReclaimable:     883404 kB
Slab:             971948 kB
SReclaimable:     883404 kB
SUnreclaim:        88544 kB
KernelStack:       12864 kB
PageTables:        19380 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    41727884 kB
Committed_AS:    5859872 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       27420 kB
VmallocChunk:          0 kB
Percpu:             2176 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      240100 kB
DirectMap2M:    10192896 kB
DirectMap1G:     7340032 kB
root@4ab972979376:/# top
top - 19:49:51 up 11:46,  0 users,  load average: 0.11, 0.36, 0.30
Tasks:   2 total,   0 running,   2 sleeping,   0 stopped,   0 zombie
%Cpu0  :   0.7/0.0     1[|                                                                            ]
%Cpu1  :   0.0/0.0     0[                                                                             ]
%Cpu2  :   0.0/0.0     0[                                                                             ]
%Cpu3  :   0.0/0.7     1[|                                                                            ]
%Cpu4  :   0.0/0.0     0[                                                                             ]
%Cpu5  :   0.0/0.0     0[                                                                             ]
%Cpu6  :   0.7/0.0     1[|                                                                            ]
%Cpu7  :   0.0/0.0     0[                                                                             ]
GiB Mem : 15.3/15.6     [                                                                             ]
GiB Swap:  0.0/32.0     [                                                                             ]

  PID USER      PR  NI    VIRT    RES  %CPU  %MEM     TIME+ S COMMAND                                  
 9938 root       0   0  217.4m   9.1m   0.0   0.1   0:00.00 0 /bin/top                                 
    1 root      20   0  218.6m  13.3m   0.0   0.1   0:00.30 S /usr/bin/qemu-aarch64-static /bin/bash   



CPU は 8個見えてます.使っている PC の CPU スペックが docker からそのまま見えています.Ryzen 5 2400G ですけど.:-)

メモリも 16G 見えていますが,これも使っている PC のメモリがそのまま表示されますね.

次,ソフト類のコンパイルが問題なくできるかチェック.とりあえず docker 中から普段使っている /home をマウントして作業.

root@4ab972979376:/# mount /dev/sdb4 /home/
root@4ab972979376:/# df   
Filesystem      1K-blocks       Used Available Use% Mounted on
overlay        2767622980 2268102844 358862504  87% /
tmpfs               65536          0     65536   0% /dev
tmpfs             8173456          0   8173456   0% /sys/fs/cgroup
shm                 65536          0     65536   0% /dev/shm
/dev/sdb4      2767622980 2268102844 358862504  87% /home

適当なディレクトリを作成して,とりあえず file コマンドをコンパイルしてみることに.

root@4ab972979376:/# cd home
root@4ab972979376:/home# mkdir tmp
root@4ab972979376:/home/tmp# cd tmp
root@4ab972979376:/home/tmp# cp ../archives/source/file-5.37.tar.gz .
root@4ab972979376:/home/tmp# ls -al
total 897024
drwxr-xr-x  2 root root   4096 Jul 16 19:40 ./
drwxr-xr-x 12 root root   4096 Jul 16 19:40 ../
-rw-r--r--  1 root root 887682 Jul 16 19:40 file-5.37.tar.gz
root@4ab972979376:/home/tmp# tar xf file-5.37.tar.gz 
root@4ab972979376:/home/tmp# cd file-5.37
root@4ab972979376:/home/tmp/file-5.37# ./configure 
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes

- snip -

config.status: creating doc/Makefile
config.status: creating python/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
root@4ab972979376:/home/tmp/file-5.37# make -j8
/usr/bin/make  all-recursive
make[1]: Entering directory '/home/tmp/file-5.37'
Making all in src
make[2]: Entering directory '/home/tmp/file-5.37/src'
sed -e "s/X.YY/$(echo 5.37 | tr -d .)/" < ../src/magic.h.in > magic.h
/usr/bin/make  all-am
make[3]: Entering directory '/home/tmp/file-5.37/src'
  CC       buffer.lo
  CC       magic.lo

- snip -

make[2]: Leaving directory '/home/tmp/file-5.37/python'
make[2]: Entering directory '/home/tmp/file-5.37'
make[2]: Leaving directory '/home/tmp/file-5.37'
make[1]: Leaving directory '/home/tmp/file-5.37'
root@4ab972979376:/home/tmp/file-5.37#
root@4ab972979376:/home/tmp/file-5.37# file src/.libs/file
src/.libs/file: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=1b00b02cdf34f849aa5b9f3127e602cfd5a8d17d, with debug_info, not stripped
root@4ab972979376:/home/tmp/file-5.37#

コンパイル通りましたね.できあがったバイナリも aarch64 用になっていますね.

/usr/local/bin 以下にインストールしてみて動作確認.

root@4ab972979376:/home/tmp/file-5.37# make install
Making install in src
make[1]: Entering directory '/home/tmp/file-5.37/src'
/usr/bin/make  install-am
make[2]: Entering directory '/home/tmp/file-5.37/src'

- snip - 

make[2]: Leaving directory '/home/tmp/file-5.37'
make[1]: Leaving directory '/home/tmp/file-5.37'
root@4ab972979376:/home/tmp/file-5.37#  /usr/local/bin/file /usr/local/bin/file 
/usr/local/bin/file: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=1b00b02cdf34f849aa5b9f3127e602cfd5a8d17d, with debug_info, not stripped
root@4ab972979376:/home/tmp/file-5.37#

動作しましたね.

ということで,docker の中でコンパイルできることが確認できました.ふう.

コンテナなので,システムに上書とか適当に書き換えてもコンテナを落とせば,元々の環境に戻るのも便利ですね.

コンパイルにかかった細かい時間は計測してないですが,体感ではそれほど早い感じはしないですね.ただ,CPU が 4C/8T なのでその分は高速かな.メモリもたくさん使えますし.

こいういう環境が整うと,新しくて早い CPU が欲しくなりますね.最近の Ryzen だと 12C/24T とかもあるから,それだとパッケージのビルド時間がかなり短縮できそうですね.

環境を整えて,開発用に使えるように徐々に調整していきたいと思います.

コンテナが動作するようになると,開発向けに一気にいろいろなことができるようになって便利になりますね.:-)

ざっと使ってみた感じは,個々のパッケージの作成はコンテナを使って,カーネルのビルドなどにはクロスコンパイラを使うのが効率的で良さそうかなと思っています.

まぁ,でも環境をきちんと整えてると時間がかかりそうなので,本格的に使うのはしばらく先送りかなと思ってます.

少し docker とか raspberry pi とかとは違う話もしましたが,そんな感じです.