CLI のファイルマネージャー、 ranger が なかなかよい。 やはり vim のキーバインディングは素敵だ。 じつは、ranger はこれまで数年使っているが、 売りの１つの画像の表示がうまくいった試しがないので、 ついつい mc (Midnight Commander) に戻ってしまう。
今度こそ・・・本腰をいれて ranger に取り組んでみようと決心した。 default の w3m-img 以外のレンダリングソフトを試そうとしたが、 インストールでつまずいてしまう。 w3m-img でとおすこととした。
もしかしたら、w3m-img とターミナルの相性の問題か と思って、いくつかのターミナルをインストールして調べてみた。 gnome-term も gtkterm もだめだ。 rxvt-unicode は対応していたのだが、 なぜか見た目がとても不細工になってしまう。
mlterm がちょうどいいことを発見した。
ctrl を押しながら、 左クリック（あるいは右クリック）をするとメニューがでるので、 そこでフォントの大きさも指定できる。
Linux、wsl (Windows Subsystem for Linux)、そして crostini (Linux on Chromebook) すべてにおいて合格だった。
ほぼ問題ないのだが、 (1) （mlterm の）tmux の上で ranger を使うと表示が乱れる。 (2) 頻繁にクラッシュする。 (2) に関しては、 ある特定のファイルに焦点があたった時に落ちる。 別のターミナル上の ranger で試してみると、 そのファイルに焦点をあてても落ちない。 明確に ranger と mlterm との問題である。
Pixelbook を復活させた件については既に述べた。 Google Pixelbook で使うのは基本的に Linux である --- ChromeOS 上の Linux は crostini と呼ばれている。
さて、Pixelbook の crostini で google-drive-ocamlfuse がインストールできなかった --- というわけで Google Drive を crostini にマウントする方法がない。 自作のシェルスクリプトでこのマウント・ポイントはしばしば使用するので、 ぼくとしてはマウントできない状況はけっこう辛い。
さてさて・・・
ちょっとググったら、 このサイト (hatenadiary) をみつけた --- Google Drive をマウントする簡単な方法が記載されていた。 なんと・ま、Goole Drive の crostini へのマウントは、 ChromeOS がサポートしているのだ。
ツールバーのファイル・アイコンをクリックする。 Google Drive をクリックし、 さらに MyDrive を右クリックしてプルダウンメニューを出す。 このプルダウン・メニューから "Share with Linux" を選ぶ。
これだけだ。
Google Drive は、 /mtn/chromeos/ の下にマウントされる。 具体的には /mtn/chromeos/GoogleDrive/MyDrive に マウントされている。
しばらく使っていなかった Snufkin (crostini on Google Pixelbook) （2017年か18年に買った）をもう一度使い始めることにする。 ターミナルから Linux が立ち上がらない。 ターミナルは INSTALL_IMMAGE_LOADER_TIMEOUT と いうエラーメッセージを吐いて、 それ以上なにもできない。
しかたないので、設定から Linux をいったん削除して、 再インストールした。
クリーンインストールからの仕事環境の再構築は すでにメモしてあるし、 シェルスクリプトをいくつか作ってある。 手順としては、 (1) ネット関連を整備する（ssh 環境をととのえっる）、 (2) apt install ... で必要なパッケージを インストールする、 そして最後に、 (3) git clone ... で作業ディレクトリを 復活させる。
wsl (Window's subsystem for Linux) も わるくないのだが・・・ どうも Windows は OS のくせに前面にでてきたがる。 とても邪魔くさい。 それに対して ChromeOS は飽くまで黒子に徹していて きもちがいい。
数日前からの Intel NUC (i5 32GB) のアップグレードをまとめておこう。
Intel NUC (i5 32GB) はその時点で Mint の 20.3 （Ubuntu の 20.04 相当）が走っていた。
(1) 最初は一番手頃な mintupgrade をつかってのアップグレードである。 この方法は、ホットアップグレード、 すなわち操業しながらのアップグレードである。
これで Mint 21 (Ubuntu 22.04) になる筈だ。 簡単にすすむと思っていたのだが、 アップグレードが何度も躓く。 躓く箇所は ppa を使ったところだったようだ。 躓くたびに ppa をつかったアプリをスキップする。 gh (github cli) でも躓いたので、 おなじように処理（スキップ）しようとしたら、 簡単にはいかない。 泥沼にはまってしまった。
(2) 翌日、 Mint の ISO (Mint 21.3) をつかってのインストールをすることにした。 これはクリーンインストール (clean install) である。 なお、 /home ディレクトリはすべて git で保存してあるので、 もとに戻すのに問題はない。
クリーンインストールは ホットインストールより時間はかかるだろうが、 その分問題も起きにくい（筈だ・・・と思う）。
さて、USB メモリーをつきさして、 インストーラの言うがままに作業をつづける。
なんと・・・「mint installer がこわれました」という エラーメッセージがでて、 インストールがとまってしまった。 もう一度ためしたが、まったく同じ結果だ。 これでは、手の出しようがない。
(3) こんなこともあろうかと Ubuntu 24.04 の ISO を USB メモリーに焼いておいた。
Ubuntu 24.04 インストールに関しても いくつかのアクシデントがあった。 これらについては すでに述べた ので、そこを参考にしてほしい。
問題は、すでに述べたように、 google-drive-ocamlfuse がらみである。 最初の起動で authentication ができなかったのは、 ものの本（ウェブ）によれば、 GUI 環境がととのっていない場合の反応らしい。 次回クリーンインストールする時は、 mate （マテ）などの desktop environment をいくつか インストールして、 それらをとっかえひっかえしながら、 authentication ができるかをチェックしたい。
とまれ・・・なんとか Ubuntu 24.04 を Intel NUC (i5 32GB) にインストールできた。
このエントリーは Intel NUC (i5 32GB) への Ubuntu 24.04 LTS インストールの 後日談である。
Ubuntu 20.04 （相当）から 24.04 へ一気にアップしたので、 いくつも不具合がでてしまった。 それらの報告である。
(1) もっとも大変だったのは emacs だ （まだ解決していない）。 emacs でなにか作業するたびに "Warning" がでるのだ。 もっとも頻度が高いのが lookup と org-mode 関連での操作だと思う。 しかし（不思議なことに） 2日ほど emacs on Ubuntu 24.04 を使いつづけていると、 Warning がでなくなった。
よくわからない。
emacs とりわけ org-mode と Ubuntu 24.04 については いずれ整理しておきたいと思う。 なお、org-mode 関連の Warning は "Org version mismatch." というものだ。
(2) つづいての問題は TUI (text user interface) のファイルマネージャー、 mc (Midnight Commander) だ。 新バージョンで cofig ファイルの書式がかわってしまっているのだ。 要は、ちまちま書き換えればいいだけの問題だが、 いささか面倒くさい。
とりあえず（config ファイルを書き終える迄は） ファイルマネージャーとして ranger を使うことにした --- いくつか問題はあるが、 とても軽くて使いやすい。
おもわぬ拾い物 --- これまで（ranger の売りだった）コンソール上での画像のプレビューが 可能になっていた。 これは嬉しい！ もう mc に戻らなくてもいいかな・・・
(3) 最後に（これは想定内なのだが）pandoc と citeproc の問題がある。 pandoc は 2.5 を最後に、 citeproc を本体にとりこんでいるのだ。 Ubuntu 24.04 の pandoc は 3.1.3 なので、もちろん、 本体内に citeproc をもっている。 そのことによる問題は （他にもいろいろ問題はあったと思うのだが・・・） Makefile を書き換えなければいけない、ということだ。 問題は、 ぼくがラップトップPC として使っている PC (Ubuntu 22.04) では、 pandoc と citeproc が独立しているバージョンを使っている、ということだ。 おなじ Makefile を使うわけにいかないのだ。 ［--git で管理している--］
最初の解決策は Pandoc を 2.5 にダウングレードする、というやり方だ。 かつて一回行なったことがあるので、自信はある。 pandoc は github で 開発されているので、 他のバージョンを使う（ダウングレードする）のは簡単な筈である。 github の pandoc のリポジトリ内の Releases のページに行って、 適当なバージョン（今回は 2.5）をダウンロード／インストールすれば いいだけだ。
ところが・・・
たしかに pandoc は問題なかったのだが、 pandoc-citeproc の方で用意されているのがソースコードだけだった。
いろいろ考えたが、ダウングレードはあきらめることにした。
もっと簡単な方法は、 そして正当なやり方だと思うが、 該当する Makefile のある git リポジトリに Noble Numbat (Ubuntu 24.04) 用の branch を作ればいいのだ。
当該リポジトリで、 branch 名 noble で branch を切った。 pandoc の新しいバージョンに整合的な （filter としての citeproc をつかわない様な）Makefile は この branch で開発していけばいいのだ。 こうすればダウングレードなどという不自然なことを する必要がなくなる。
いずれ、ぼくの他の PC も Ubuntu 24.04 にアップグレードした時 （Pandoc を version 3 以上にした時）、 Makfile リポジトリの noble ブランチを merge すればいいだけなのだ。
・・・
というわけで、 なんとか Ubuntu 24.04 で新装開店した Intel NUC (i5 32GB) が無事に動きはじめている・・・ という報告でした。
こないだから Intel NUC (i5 32GB) のアップデイトを試みている。 現在インストールしてあるのが mint の 20.3（Ubuntu でいうと 20.04）なので ずいぶんと古くなっている。 今日の午前中は mintupgrade をつかっての アップグレードをはかった。 これがけっきょく失敗した。
午後は Ubuntu 24.04 のインストールにチャレンジする。 深い深い泥沼にはまってしまい、出てこれなくなる。
この時の困難をまとめようと思ったのだが、 パニックになってしまい、 メモがとってあるのだが、 それも意味がわからないくらいに断続的だ。 躓いたのは（どうやら） google-drive-ocamlfuse （Google Drive をマウントするアプリ） らしい。 問題なくインストールできている。 いつもなら初回の起動において、 自動的にウェブブラウザがたちあがって authentication ができる。 今回はそうはならずに「id と secret を指定しろ」と言ってくる。 ここから、ウェブをしらべながら、 いろんなことをやって午後いっぱいを無駄にすごした。
さいしょから遣り直すしかないと思っていたら、 なぜか（原因はまったく分からない） ブラウザが立ち上がって、 いつものように authentication がおわった。
なんとか、インストールを終了する。
きのうの夜で一通り Linux 化は試した。 （USB メモリーの不具合だろうので） 新しい USB メモリーで、 同じことをもう一度繰り返すべきだとは思うが、 めんどうだ。
というわけで、Linux 化はあきらめて、 ウィンドウズの中で wsl (Windows Subsystem for Linux) を 立ち上げることとする。
ほぼ問題なく使える。 背後にひかえる Windows が邪魔だが、 ま・これで emacs を使えるのでいいだろう。
《More . . .》Chuwi Minibook X N100 が気になってしかたなかった。 暫く迷っていたが、昨日注文した。 なんと早速届いた。 大きさは思ったとおりだ --- とてもうれしい。
Linux にする予定だが、 失敗したときに Windows に戻す（wsl を使う）方法を 調べた。 これが分からん。 どうやらマシンの素性を調べるためにプロダクト・キーやらなんやらを 調べなければならないらしい。 調べれば調べるほど分からん。
とりあえず Ubuntu を USB メモリーからブートして、 調整なしでどのくらい使えるかをチェックすることにした。 「いざとなれば、 デュアルブートでもいいか・・・」
さて、Chuwi を再起動して F2 を連続して叩いて、 BIOS 画面に至る。 「急速立ち上げ」を無効にして、 なんとかを UEFI から Legacy に戻す。 そして、ブート順のトップに USB メモリーを置く。 Save and Exit. さて、Ubuntu 23.10 を USB メモリーにいれた。
なんと・ま・なんというアンチクライマックス・・・ Error がでて Ubuntu が立ち上がらない。 この時点で午前1時くらいだったので、 寝ることとする。
現在 ikiwiki は、 ぼくが借りている レンタルサーバー (www.merapano.net) をつかって運営している。 ikiwiki を github をつかって運営する方法があるのを 発見したので、試してみる。
ikiwiki は wiki の一種である。 ぼくはこれ（ikiwiki）をつかってデータの整理につかっている。 理論関係の抜粋およびまとめには phil-web という wiki を、 フィールドワークのまとめには flores-web を、 科研で調査したティモール島のデータには timor-web を、 そして、コンピューター関連のメモには comp-web を使っている。
ikiwiki がどのようなものか、 そしてじっさいにどのように ikiwiki を使うかについてはいずれ 述べることにする。 とりあえず、 comp-web のパスワードを変更するので、 じっさいにアクセスして参考にせよ --- ユーザーID を foo、 パスワードを bar に変更する予定である （数日後に変更し、 その一週間後くらいしたらもとに戻す）。
さて、 公式のページにもとづいて、 ikiwiki を github だけをつかってデプロイしてみた。 ところがうまくいかない。 失敗の状況を Comp-Web のここ に書いておいた。
うまくいく方法を考えた --- Comp-Web のここ にやり方を書いておいた。
ただし ikiwiki の plugin が動かないので、 あまり役にたたない。
Lenovo Yoga 770に Ubuntu を走らせてみた。 Windows 上で wsl2 が動いているので、 Lenovo Yoga 770 のウィンドウズにとくに不満はないものの、 やはり Linux を直に走らせたほうが、 ウィンドウズからの邪魔（アップデイトやらなんやらかんやら）が なくて気持ちがいいだろう。 ・・・というわけで、 一度失敗した〈Lenovo Yoga 770 のLinux 化〉をもう一度ためしてみる。
Ubuntu 22.04 の kernel では Ryzen 6000 シリーズでキーボードを 認識できない。 Lenovo Yoga 770 は Ryzen 6000 をつかっているので、 Ubuntu 22.04 を走らせることはできなかった。 これが「一度失敗した」経緯だ。 Ubuntu に Ver 6.0 の Kernel が採用されるのを待っていたが、 どうやら Ubuntu 23.04 には最新の Kernel が採用されているという。 さっそく Lenovo Yoga 770 で 23.04 を （インストールはしないで、トライするだけのモードで）走らせてみた。
キーボードを認識した。 ところが、 ディスプレイが物理的な動きに追随できなかった。 ［--もしかしたら、自動はだめでも、CTRL-ATL-上矢印（みたいなやり方）で画面を回転させることができたかもしれない--］ もっともがっかりしたのは音だ。 ぼくは Lenovo Yoga 770 の音がとても気にいっている。 ところが、Ubuntu の上ではかすかすの音だった。 耳がとりわけて良いわけではないぼくの耳でも分かるほどに、 びっくりするほど安っぽい音だった。
まだ暫くの間は「ようすみ」をすることとした。
今回買ったあたらしいマシン (Lenovo Yoga 770) は Ryzen マシンだったので、 Linux (Ubuntu) がうまく動かなかった。 （2022-10-07 の日誌を参照にせよ。） Kernel 6.0 からは Ryzen 6000 にも対応したという。 （いい機会でもあるので） Ubuntu がこのバージョンの kernel を採用する迄の間 wsl (Windows Susbsystem for Linux) を （正確には wsl2 を） ためしている。
大きな問題は、 wsl2 の上で emacs を使うと emacs がキー入力をうまくひろわないという点だった。 その状況を救うために、 Windows のリモートデスクトップ (xrdp) を立ち上げて、 その上で wsl をつかっていた。 動くので問題はないのではあるが、 ChromeOS の crostini に比べ、 いささかもってまわったやり方だなぁと思っていた。
・・・
いったいいつからなのだろうか、 この頃は xrdp を通さないでも emacs が正常に動くようになっていた --- キーの拾い間違いがなくなったのだ。
不思議だ・・・
終わりよければ全て良し、ということで 細かいことは気にしないこととした。
Ubuntu 22.04 のライブUSBで、 Lenovo Yoga 770 で Ubuntu をためしてみる （こないだは Mint だ）。
今回もキーボードを受け付けない。 ・・・。
ウェブをさがすと、 こんなサイトがみつかった。 こんどは外付けキーボードをつけて試す？ いったいどのファイルに書き込むんだ？
上のは解決にならないようだ。
Ryzen 6000 が Linux でキーボード問題を起こすのは よく知られた事実のようだ。 解決法がかかれているのかわからないが、 "Ubuntu Ryzen 6000 Keyboard" でヒットした サイトを列挙する。
Linux 6.0 Fixes Broken Keyboards On Ryzen 6000 Laptops, Power Management Additions
Keyboard in Multiple Ryzen 6000 Laptops Not Functional in Linux
Kernel 5.20 patch for Ryzen 6000-series laptop keyboards. --- パッチがでているんだ。
Keyboard not working on Lenovo Laptop
いまからこれらを読んでおこう。
《More . . .》