完全なる画面ブラックアウト

今朝イチバンから、ログオン直後に左のようなダイアログがパラパラパラと出てきて、パネルなどのコンポーネントが全く表示されず、という状態になりました。

このダイアログを［Ｘ］で消すと画面はマウスカーソルのみが静かに佇む完全にブラックアウトしました。

[Ctrl] + [Alt] + [T] でコンソールは開くようで、いくつかサービスを見てみると起動してるっぽい。ＯＳとしては起動してるけど、デスクトップの表示だけがダメ、という状態のよう。

先日の記事に載せていた対処スクリプトを実行してみたりしましたが、まったく改善せず。もう１つのSSDからKubuntu 24.04.4 を起動して少し調べては試してみて「ああ、ダメか…」を何度も繰り返し…。

そろそろ嫌気がさしてきて、「さっくり消して新規にインストールし直すしかないか…」と諦めかけて「最後にもう１回だけジタバタしてみるか」ということで、~/.cache を丸ごとリネームして起動してみたら、なんとまぁ、デスクトップが戻ってきましたよ。

もちろん…と言うか当然ですが、デスクトップのテーマ類やアプリの設定とかがさっくり初期化されてしまいましたので、改めて設定し直しを…

先日書いていた「不定期に画面ブラックアウト」もこれで治ってくれればヨシ。

何事も経験するのがイチバンですね。

踏んだ場数と経験の量が技術と自信を高めますｗｗｗ

【後刻追記】

「直りました」と書いた直後に、再発しましたよ(爆)

なんだこれは…

こういう「よく分からん状態」に長く付き合ってるとメンタルが傷みますので、かような状態からは早々に退散することにします。はぁ…

ハンドルバー自体をカスタム

大した話ではありませんが、ハンドルバーエンドの未使用な２０ｍｍをカットしました。

ハンドルバーはDixna J-Fit Monroe FZですが、ショートリーチ化するために、おそらくメーカ意図から外れた「前下がり」にセッティングしているので、見てくれ上、バーエンド部がやたら長くなり、且つ、少し上向きなっていました。

そうした見かけ上の問題を解決するためにエンド部２０ｍｍをカットした、というワケ。

目的のもう１つは、ちょっと前に十三峠に行った際、頂上駐車場で風に煽られてばったり倒れてしまって、その時にバーテープが少し破れてしまったんです。それを「隠す」ためにねｗ

カット後に南河内方面にサイクリング行ってみましたが、まぁ全く問題無し。使ってない部分をカットしたので当たり前ですね。下ハンを持った時でも手より後ろにまだ１５ｍｍほど余裕があり、手がすっぽ抜けるなんてことも無さそう。

ストレートハンドルバーとかではカットするのは普通ですが、ドロップバーのカットはあまり見聞きしたことはないです。非可逆な加工に少しばかり不安がありましたが、とりあえずは問題なくて安心しました。

ならクルＣ７（の一部）を走ってみた

毎週末(土)か(日)の定例サイクリング、いつも通りに「いつものコース」へ。

法隆寺まで来て「よし。今日は松尾寺まで行ってみよ！」ってことで原因不明の意気込みをもって法輪寺横を過ぎ法隆寺カントリー倶楽部を通り抜けて、松尾寺アプローチの県道１２３号へ出た時、「よし。今日はやめとこ」と気持ちが萎えて(殴)そのまま東へＧｏ。

富雄川のところから県道２７４号＝ならクルＣ７を初めて辿ってみました。けっこう走りやすかったです。時折大きな道路を横切る格好になりますが、そこでＳＴＯＰ＆Ｇｏになるだけで、あとはのんびりと景色など見ながらポタリング…。

富雄川が大和川に合流する少し手前で「左岸に行け」と明日香方面を案内されますが、それは無視して直進。合流地点の新御幸橋は渡らず大和川右岸を進んで、川が「ぐわん！」と右に大きく曲がる箇所にある沈下橋を久しぶりに渡って左岸へ。渡る前に「記念撮影でも…」と思ったら、バイクが来るわクルマが来るわ…。こんな橋でも（失礼やな）利用は多いようで。

そんなこんなで、王寺を抜け三郷を抜け国分を抜けて大和川ＣＲ経由で帰宅しました。

とりあえず、ならクルＣ７はまぁまぁ良い感じでした。北端地点がどこなのかよく分かりませんが、輪行込みなら、近鉄奈良線の富雄をスタートして富雄川沿いを走るのも良いかもしれません。ゴールはＪＲの法隆寺か王寺か。コース上にはあまり目ぼしいものは無い感じですが、大和郡山でキンギョ釣りしたり、Hamp 3rdでランチしたり。

それか、近鉄奈良線の大和西大寺を起点に秋篠川沿いを南下して大和郡山から富雄川にトラバースして…というのも良いかもしれません。

自分的には「ロードバイクの全自走」が基本のポタリングなので、コースバリエーションを検討するにはもう少し工夫が必要です。

不定期に画面ブラックアウトしやがる

もう２年以上Kubuntu LTSを使ってきております(24.04→26.04）が、ずっと悩まされてるのが「画面が突然ブラックアウト」の症状。

予兆なく急に起こる。ですぐに戻る。

それが何度も連続することもあれば１度で終わる時もある。コールドブートしてログインした直後に起こることもあるしスリープから復帰した時に起こることもある。動画を再生してる時にマウス（ホイール）を操作すると発生する頻度が高いかも…いやそうでもないかも…。とにかく、よー分からん。

「すぐに戻る」と言っても、画面表示の信号が途絶えてブラックアウトして信号が復帰しても、液晶モニタ（三菱RDT232WX）の都合で表示が戻るまでに数秒待たされます。

という極めて鬱陶しい状況なんですが、ある時に見つけた情報より、現状は左のようなコマンドで対処しております。

KDE関連のキャッシュの消去＆再構築なんですが、これを行うと「しばらくの間」は平穏に過ごせるのですが、いつの日かまた起こるようになり…

ま、そういうことの繰り返しなワケです。

いいかげんこの症状に「おさらば」したいんですが、実際に何が原因なのか…。いくつかのログを眺めてみても「おおっ、これか！？」と思えるようなものは見当たらんし…（見当たらない原因は、おそらく私のスキル不足…）

っということで、少々辛い日をおくっております、という話。

＃ Kubuntuは諦めて素のUbuntuにして（＝逃げて）平和な日常を取り戻すか…

【後刻追記】

上記コマンド群に少し付け加えてスクリプトにしました。

#!/bin/bash kquitapp6 plasmashell rm -rf ~/.cache/plasmashell* rm -rf ~/.cache/org.kde.dirmodel-qml.cache rm -rf ~/.cache/kioexec rm -rf ~/.cache/ico if [ -f ~/.config/kwinoutputconfig.json.bak ]; then rm -f ~/.config/kwinoutputconfig.json.bak fi mv ~/.config/kwinoutputconfig.json ~/.config/kwinoutputconfig.json.bak kbuildsycoca6 --noincremental kstart plasmashell

【後日追記】

なんとなく…ですが「スリープから復帰する」と症状が出るみたい。

Lemonade ServerでRadeon RX9060XTを正しく使う

ふとした思いつきウェブ界隈を漁っておりましたら、「お？これは…」と思い当たる情報を目にして…

「やっとこさ」Docker環境下のLemonade ServerでGPUを正しく使ってもらえる状態に設定できました。

「できました」と言うか…要するに自分が正しく環境設定できていなかっただけの話で…。ポイントはこちらの「Prerequisites」でして、"Configure permissions for GPU access" の udev Rulesの作業を洩らしておりました。

AMDの説明書きにある通りにちゃんとやらないとダメですね。とは言っても、それが難しいケース（＝AMDのドキュメントが複雑怪奇）はたくさんあるのですけども。まぁ、今回の件は完全に私のマヌケなミスです。

「自宅でAIごっこして遊ぼ」という目的で始めた作業ですが、やっとこさ、ベースのAIエンジン部分の環境ができました。

続：久々にライポジを変更

前回調整してから何度か乗っていますが、「あともう少し」という感じがしました。

お尻の前ズレはだいぶマシになりましたが、会陰部の痛みがまだ少し残ること、膝前部の痛みが少し出ること、などがあってサドルのセッティングを少しだけ変更しました。

サドルを僅かに後ろに引き、且つ、前下がりを少しだけ強めにしました。

せっかくお尻の前ズレを緩和できたのに前下がりを強めたらまた前ズレしてしまうやん…という気が少ししますけど、上手く折り合いをつけたいところ…。

とりあえず「これでどーや！」という感じですが、なんとかこれで上手くいってもらいたい（＝もうそろそろＯＫを出したいところ）。

久々にライポジを変更

お尻の位置が前にズレてしまいがちなのが少し気になってて…

で、対策してみたのでその具合を確認するために酷暑サイクリングへｗ

対策の目的は（当然ながら）「リーチをできるだけ短くすること」で、変更したのはハンドル角度とブレーキレバーブラケットの位置。ブラケットの位置を手前にずらす、ブラケット角度が上向きすぎになるのでハンドルを前下がりにセット、という組み合わせ技。これで１０ｍｍ弱ほどリーチを短くすることができました。

乗ってみた感じですが、上ハンを持った感じは良好、下ハンを持つと少し寸詰まりな感覚（もう少し手を奥に置きたい感じ）がありましたが両立は難しいので上ハンを優先。

リーチを短くできたので、サドルの角度も見直して前下がりの度合いを少し緩めに変更しました。

とりあえず今日乗ってみた感じでは特に問題ありませんでしたので、しばらくこのままでいってみます。

久しぶりに滝畑ダムまでサイクリング

６月末まで工事で通行止めになってた府道２１８号の通行再開後の様子を見に…というのもあって、猛烈に暑かったですけど、なんとか行って帰ってこれましたｗ

花の文化園を過ぎて府道２１８号に入るところで、府道を辿ってこられた３人組みのサイクリストが自分の後方につく格好になりました。こちらはユルユルのポタリストなので、速攻で抜いて行かれるでしょ…と思うておりましたのですが、何故か少し頑張って漕いでしまってｗけっこう長い間先行する形で進んでいきました。が。

登りが辛くなってきてヘロヘロになってペースが激落ちしたところで、ズバっ！と追い抜いてくださいました。はれてプレッシャーから開放されましたｗｗ

いつもなら梨の木隧道を通ってダム湖に向かうんですが、そのコースに行く元気が無かったので、キャンプ場の先からも府道２１８号を辿って、石川を渡ってすぐのところで「写真を撮って折返して帰ろ」と思うたんですが、何故かそのまま登り続けて…で結局、冒頭の写真の場所まで行ってきました。

写真とか撮ってると、ズバっ！と追い抜いていかれた３人が来られて、「やぁ〜やぁ〜、先ほどはどうも」的な話から、あれこれとお話させていただきました。お一人はMERIDAのグラベルバイクでGRXコンポを使っておられました。もうお一人は赤白のカレラのフレームでブルベを志向されてる方。もうお一人はTREKに乗っておられる八尾市民の方。何にしましても、お時間とらせてしまって、申し訳ありませんでした。

府道２１８号は、途中１箇所だけ山側法面の補強工事が行われてました（今日は工事はお休みの様子）。 「路面が綺麗に舗装し直されてないかな〜」なんて淡い期待をしていましたが、見事に裏切られました。路面は以前のまま。残念っ。

来る途中の路面はけっこう濡れた箇所が多かった。たぶん、朝がたまで雨が降ってたんだろうと思います。天気予報では「午後は急な雨に注意」とか言ってて、冒頭の写真の通り妙な雲も出てきそうだったので、素直に折り返して往路のコースをそのまま逆に辿って帰宅しました。ありがたいことに今日は東からの風で、帰りの大和川ＣＲは追い風ルンルンでした。

やっとこさGPUをブン回せた。けど…

ローカルAIで遊ぼうと、いろいろ試してみております。まぁ、いわゆる「おもちゃ」的に遊んでいる状況です。

で、ちょっと苦労したのが「どうやったらGPUを使ってくれるのよ」ってところ。

具体的にはLemonade Serverなんですが、最初はStandaloneのサーバとしてインストールしていました。この時も、いくつかのモデルを使ってもCPUの負荷が上がるだけでGPUは静かな状態のまま。その後、Docker/Dockhandの環境に移行しましたが、状況は全く変わらず。最初は構成ファイル中に /dev/kfd, /dev/dri の Device を記述してなかったので「ああ、それだったか」と思ったのですが、それを記述しても状況は変わらず。使用したモデルのBackendにROCmを指定しても変わらず。

config set rocm_channel=nightly を指定して backends install llamacpp:rocm をやっても、なんら状況は変わりません。

Lemonade Serverのバージョンは 11.5.2（＝本記事投稿時点で最新）でしたが「こりゃダメか」と諦めました。

が、Standalone サーバの時には apt install したそのままで動かしてただけだったのを思い出し、lemonade config set rocm_channel=nightly して、lemonade backends install llamacpp:rocm して、もっかいトライしてみたら、冒頭の絵の通りGPUを使ってくれることが分かりました。

とりあえず、少しばかり望んだ状況に近づいたワケですが、それにしても、どうも応答がもっさりしてる…。

Docker環境には比較用に ollama も導入してあり、Lemonade Serverと同じModelを使って同じプロンプトで試してみたら、極めてスムースに応答してくれました。CPUはほとんど使用されずGPUがほぼ１００％の負荷で処理されていました。

ってことで、Lemonade Serverは「もう少し改善が望まれるね」という状況のように思いました。nVidiaのGPUなら結果が違うのかもしれませんが、CPUもAMD製、GPUもAMD製。の上にLemonade Serverの開発にもAMDが大きく関与しているはずで、今の状況ってのはちょっと寂しい感じがします。

そうではなくて、自分の環境／設定が悪い？

いろいろ調べて試してみたんですけどねぇ…。まだ何かあるのかもしれません。

【後日追記】

８／１５(土)の朝、Lemonade ServerのUpdateがあり v11.6.0 になりました。で、Gemma4:12Bを使って様子を見てみたところ、以前とは少し様子が違い、CPUはほとんど回らずGPUが100%で回り続けてくれるようになりました。やったね。

リリースノートを見てもgfx120xに関連するようなことは何も書いてなかったですが、「The llama.cpp ROCm backend now runs on AMD Instinct MI100, MI200, MI210, and MI250 GPUs on Linux.」なんてのがあって「ついでにgfx120x系も具合が良くなったんかな」と無根拠に妄想。

自分の環境条件を書いてなかったですが、GPU Driverは31.40.1を「--usecase=graphics,rocm,opencl --opencl=rocr --vulkan=radv --gfxversion=gfx1200」を指定してインストールしています。この時、Pytorchのバージョンが低くてインストールでエラーとなり、こちらよりPytorch 2.13.0／ROCm7.2を指定してインストール（アップデート？）した後、GPU Driverをインストールし直しました。何かよく分かった上でこういうことをした、というのではなくて、問題が出る都度あれこれ検索して対処方法を入手して…を繰り返してやっただけ。何か間違えてるかも…（特に Pytorch）

フロントタイヤを23Cにしてみた

例によって「とてつもなく暑い」日ですが、週に１度ぐらいは運動しないと…ということで、頑張って雁多尾畑の金山媛神社まで参拝サイクリングにいってきました。

目的は、神社にお礼参りをしたかった事と、フロントタイヤをグランボワ・コルデマドレーヌ（２３Ｃ）に替えてみた結果を確認したかった事、の２点でした。

前後異サイズながらも同じExtra Legerで作りもトレッド面の様子も同じで「乗った感触に大差が無いなら前だけ２３Ｃを常用しても良いかな〜」なんて思いましてね。ま、単なる思いつきなだけですけど。

で結果は、やっぱ手に伝わる感触が少し硬め。細身でエアボリュームが少ないので高圧にせざるをえず、なので路面振動が強めに伝わるんでしょうね。

とは言え２３Ｃにガチガチに不満を持ったわけではありません。２６Ｃを知らなければ「これでエエやんか」と思ってたはず。もうしばらくはこのままで乗ってみようと思います。

内幅１３ｍｍの同じリムに装着した時の２６Ｃ（左）と２３Ｃ（右）のクリアランス差はこの通り。まぁ、サイズ表記の差の通り、という感じです。

２６Ｃでは、タイヤに正圧の空気が入った状態ではブレーキシューに挟まってホイールを抜けませんが、２３Ｃではそうした問題（？）はありません。

パンク時は、空気が抜けてるのでホイールを抜く時は問題ありませんが、修理を終えた時は、先に空気を正圧まで入れてからホイールを装着しますので、こうした「引っかかり」があるとストレスになると思います。輪行時なら余計にストレスを感じるでしょうけど、自分はトラブル時以外の輪行はあまり考えてないので…。

ATHENAのブレーキキャリパにはクイックレリーズ機能が無いので、アウター調整ボルトを使って逃げれるようにしていますが、それでも２６Ｃの場合はちょっと厳しい感じです。

そういったストレスも２３Ｃには無いので、これで問題無ければ「２３Ｃタイヤの方がフールプルールやね」ということになります。ま、大した話ではないですけども。

Docker環境をDockhandで一括管理

先日導入したimmichで初めてDockerを利用し始めて、けっこう便利なモンやなぁ…と味をしめて、稼働中のサービスでDocker環境に切り替えれるものをDockerを利用する方法に変更しました。

で、そういうことをしてると「もっと便利に管理する方法は無いのか」と思うのが当然のなりゆきで、少し調べたら「Portainerなんてのがあるやーん」と分かり、早速それを使ってみることに…。

でも、なんとなーく気に入らなくて、もう少し掘り下げて調べてみたところDockhandに到達しました。

ということで、冒頭の絵の通り、あれも・これもDocker化してDockhand管理にしてしまいました。

まだ記事には書いておりませんが、RADEON RX9060XT も導入してローカルAIを（いちおう）目指せるハードになったので、Lemonade Serverなども導入しそれを利用するOpen WebUIとかSearXNG+VANEも導入したり。単体で導入していたAdGuard HomeもDocker版があると分かり、これもDocker/Dockhand環境に移設しました。

PortainerにせよDockhandにせよこうした管理ツール（GUI）が「必要」と思った理由は、サービスの追加や削除・停止／開始はもちろん構成変更をする機会が多いことを予想してのことです。「使うサービスが決まってて構成も決まってて起動したらしっぱなし」という安定した状態ならCLIベースでDockerを操作するので十分です。まだそういう状態ではないしこの先も「あれこれ試したい」というのもあって「手軽に構成変更できる環境」が欲しかったのでDockhandを利用することにしました。

【閑話休題】

できてみれば「そういうことか」と分かるのですが、やってる途中は分からないことだらけで、ぜんぜん上手くいかなかったり苦労しまくっておりました。（全ては歳のせいで理解力が劣化しているため…でしょう）

もうあと数ヶ月で正真正銘の「高齢者」に分類される歳になります（＝年金生活者になります）が、こうして自分の自由にできるツール（＝お遊び道具）を使って楽しんでいきたいと思っております。

山坂を（できるだけ）避けて法隆寺まで

道路各所にある気温表示はいずれも３？℃を示す中、元気よくヘロヘロ・ヘコヘコと走ってきました。

行き先は「いつもの」法隆寺ですが、この季節＆気温ですので、山坂をできるだけ減らしたコース取りにしました。おかげで、斑鳩町の龍田神社や藤ノ木古墳に立ち寄れました。

そういうのもあって、まだローギア３２Ｔを使うような場面には出会ってなくて亀の瀬辺りも２８Ｔまでで対応できております。２６Ｃタイヤも至って快調、空気圧７．０ｂａｒで乗ってますが問題無し。

細かめの砂程度の未舗装路であれば何ら心配なく乗れますね。少し大きめの石があるような路面は…試してみないと分からないですね。今日それを少し試そうかと思って出発したんですが、（短いけど）斜度がきつい箇所を通らんとあかんのでやめておきました。走路選択と抜重さえ気をつけておけば大丈夫なような気がするんですけどね…。

フォト画像の管理環境をリニューアル

これまで色々なやり方をしてきました。基本はローカルディスク上のPictureなりPhotoなりのフォルダを使い、その下に撮影日付のフォルダツリーを作ってそこに撮った写真画像ファイルを置く、で、しかるべきツールで表示する、という感じ。

以前はShotwellとかを使っていましたが、カメラ（＝スマホ）をパソコンに有線接続せなあかんしスマホ側を写真同期モードに設定せなあかんし…「あかん」てことは無いんですけど、とにかくまぁ、手間が鬱陶しくなってこの方法は縁遠くなりました。直近はGoogle Photoアプリを使ってGoogle Driveに同期する、という方法でやってきましたが、これにしても、現用中スマホ（Sharp AQUOS sense9）からアップロードするとドライブ領域の使用量カウントに計上されてしまうので、それを避けるためにいちいちPixel 4aにQuick Shareで転送してから 4a のGoogle Photoでアップロードする、なんていう小賢しいことをやっておりました。

が、これも「めんどっせーなー…」と…

そういう流れで、「じゃぁこの際、ローカルマシン上に自家製Google Driveもどきを用意して、そこでファイル管理するか」ということにしました。

使用したのは冒頭の絵の通り immichサーバでスマホアプリもimmich。世の中にゴマンとある情報を元に自パソコンにヘコヘコとインストール＆セットアップしました。

時間を要したのは写真データの移行で、Google Drive上の写真をどっさり取得して、Exifの無いファイルの対応とか移行しやすいフォルダへのファイルコピーとかいろいろ手間をかけて作業して、15000ファイルほどを移行しました。

ローカルマシンでもほどほどの安全性を持たせておきたいので、メタデータと実体ファイルを同じタイミングでバックアップする（質素な）スクリプトを作って対応しました。この環境を使うのは自分だけですし24h運転なんてしないので、バックアップは自分の好きなタイミングで手動で実行する方式にしました。

ってことで、まぁ、なんとか使える状態にできました。

スマホアプリの使用感は全く悪くないです。こと同期に関してはGoogle Photoより圧倒的に素早い。immichサーバと通信できない環境では写真データをダウンロードしたりはできないのですが、画面表示できればＯＫなので全く問題無し。

immichをインストール＆セットアップした時は v3.0.3 が最新でしたが、7/30にv3.1.0がリリースされました。「アップデートする前には、Metadataを含めバックアップしておけ」と説明されてますし、世の中の情報にも「immichのバージョンアップでは、DBが壊れても対応できるぐらいに備えておけ」的な話もありましたが、バージョンアップの説明手順通りにやったら、すんなりいけてひと安心。

Dockerを使うのも初めてでしたし、いろいろ知らないことばかりで大変でしたが勉強になりました。

前後新タイヤで試走

諸事情あって昔のように「日の出前から早朝サイクリングぅ〜」というワケにもゆかず、酷暑の季節でも家を出るのは朝の９時頃…

つまり「出発時点で既に猛烈に暑い」と…

そういう中でのサイクリングなので、無理と無茶は禁物で、少しでも異変を感じたら即座に良い場所を探して休憩する。状態が落ち着くまでじっくり待つ。という考えで走ってますが、とりあえずめちゃくちゃ暑い。法隆寺まで行って帰ってだいたい50kmほどですが、この季節の酷暑サイクリングではそれすら無理。大変です。今日も30km走って帰ってきました。

新タイヤですが、グランボワさんのおかげで無事に問題解消し、実走でも異音が出ることもなく安心して26Cタイヤを使える状態になりました。

タイヤサイドには「最低でも7.4barを」と書いてあるのですが、今日は前後とも7.0bar強で乗っていました。未舗装はもちろん酷く荒れた道は走らないし、下りを高速コーナリング〜〜なんてこともしませんので、これぐらいの圧でも大丈夫なよう。

タイヤ自体のしなやかさもあり乗り心地はかなり良いです。23Cでも似たような感想でしたので、26Cなら言わずもがな、でしょうか。

Extra Legerという軽量モノで1本5600円という値段。これをどう見るかですが、私的には全く不満はありません。耐久性がどうなのか…というのはこの先の判断になりますが、週末サイクリスト（ポタリスト？）には優しい製品のように思っています。

26Cタイヤ問題、無事解決

左の写真は前ブレーキアームとタイヤとのクリアランスを示したものですが、左側がVittoria Zaffiro Pro 25Cを履いた時のもの、右側がGrandBois CerfBlue 26Cを履いた時のもの。

7/20の日記で、26Cタイヤを「大きすぎた」と書いてますが、実際にこれぐらの差がありました、ということです。

当方が抱えた問題は、このクリアランスの縮小がタイヤの縦ブレの許容範囲の縮小に繋がってしまい、たまたま手にしたCerfBlueの１本が「（クリアランスのサイズに対して）ブレが大きかった」ということで、ブレーキアームにタイヤが擦れてしまうという問題になりました。

Zaffiro Proは新ETRTO規格のタイヤです。リムは内幅13mmという極細のGrandBois ABEILLE ですので、内幅19mmを前提にしたZaffiroではタイヤ幅が狭くなりハイトも（タイヤメーカの想定より）低くなってるはず。

リムハイトも含めた全高は先の日記に書いてありますが、Zaffiro ProとCerfBlueとではけっこうな差があり、さらにはCerfBlueの「縦ブレ」とブレーキアームとのクリアランスの小ささが重なって、「タイヤが擦れる〜〜〜」問題になりました。

今回の「CerfBlueの縦ブレ問題」について、個人的感想として「さすがのPanaracer製品としてはブレが大きすぎる気がする」と思い、サイクルグランボワに情報提供して「製品改善に繋げてもらおう」ということで連絡しましたら、折返してたいへんありがたいご提案をいただき、検品済み正常品に交換していただけることになりました。

タイヤの新旧ETRTOの規格については、タイヤ幅の話はたくさんありますますが、タイヤハイトについてはほぼ情報ゼロです。

今ドキな幅広リム＋幅広タイヤなら特に心配も無いでしょう。そうでない旧規格品を利用する者はよくリサーチする必要があるな、と改めて思い知ったしだいです。

縦ブレの大きかった（と感じた）CerfBlueタイヤですが、「ブレーキアームに擦れる」という問題があったのでこういう結果になりましたが、個人的にはこれが「タイヤの問題」かどうかは「よく分からない」と感じています。製品として許容されてる誤差範囲なら、この問題は私の使用条件が原因です。

その辺りを含めて飲み込んでくれはったサイクルグランボワには、あらためて、大いに感謝したいと思います。

Thunderbird is back！

今月初にKubuntu 26.04 に移行して、その時、OS含めて全て新規にインストールしセットアップし直しました。

従来からメールはThunderbirdを使ってきてましたが、この移行の時、手持ちのgmail.comアカウントが全く登録できず、「認証エラーです」攻撃に遭いました。ウェブブラウザからなら正常にログインしてメール読み書きもできましたので、パスワードが間違ってるワケではなく、OAuth2の認証処理に問題があったような感じでした。

とにかく、Thunderbirdでgmail.comアカウントが登録できない状態。まったく原因が分からず、他の使えるメーラーを探して、GNOME標準のEvolutionに逃げていました。

今日たまたまThunderbird 153 がリリースされたのを見て、もっかいトライしてみるか…ということでやってみたら、なんと、すんなりイケてしまいました。

「そういう不具合だった」ということで、解決していただいて助かりました。Evolutionはけっこう重量級アプリで、あんまし好きじゃなかったんでね。

ボトルを夏仕様に

ほぼ通年で、ボトルケージはNITTOの BOTTLE CAGE Rを使い、ボトルはCAMELBAK Podiumを使っております。

が、流石にくっそ暑い今の季節だけは保冷ボトルじゃないと…なんて言って自分が保冷ボトルを持ってるのをすっかり忘れてて…

それはともかく、THERMOS FFQ-600を使うことにしました（飲み口はストローではないものに換装済）。CAMELBAKの樹脂製保冷ボトル（Podium ICE）も持ってるんですが、金属製ボトルの保冷力にはかないません。

THERMOSのこのボトル、ヤワいケージだと走行振動でカチャカチャと音がするので、それを抑止する為、強固なケージ ELITE CIUSSI GEL に換装しました。おかげでボトルの抜き挿しが大変なんですけど、しかたがありません。

26Cは大きすぎた

左の写真、既にタイヤを交換した後のものなんですが、白丸を付けた箇所、グランボワの26Cタイヤだとこの部分のクリアランスが不足してタイヤがキャリパーに擦れてしまう状態でした。

手持ち残のZaffiro Pro 25Cに交換したのが冒頭の写真です。25Cでこれだけ隙間があるのに26Cにしたらダメとは…。まさかの落とし穴。26Cだと、白丸箇所のクリアランスが1mmほどでした。で、タイヤの上下ブレ具合によって、ブレーキキャリパーの腹に擦れて…。

ホイールに縦振れがあるワケではなくタイヤの問題。タイヤやホイールの装着具合とか色々試してみましたが異音解消には至れず、残念ながらフロント側にはCerfBlue 26Cは使えない、という結論になりました。

走行中に「なんか妙な…リズミカルな異音がするなぁ」なんて思ってましたが、そういうことでした。タイヤが真円だと救われたのかもしれませんが、さすがのPanaracer製でも完全な真円は難しいでしょう…。とは言え、今回の26Cは、ちょっとブレが大きいような…、被害妄想かｗ

当面しばらくは「前Zaffiro 25C、後CerfBlue 26C」という組み合わせのまま乗ることにします。Zaffiro Proの性能に不満も無いし、前輪より後輪の方が減りが早いのでCerfBlue 26Cの１本は後輪の交換用ってことにします。

その先はどうするか…

WH-RS500に装着しているCol de la Madeleine 23C を前輪用に使おうかな…。前後異サイズですが同じExtra Legerで色合いも合いますしね。

【後日追記】

ふと思って、Zaffiro Pro 25Cを装着した前輪とCerfBlue 26Cを装着した後輪のハイトを測ってみました。リムハイト＋タイヤハイトの合計サイズですが、前輪が３８ｍｍ、後輪が４0〜4１ｍｍ。なんとCerfBlueは外周直径で5ｍｍほどもデカかった。全くの予想外というか、ここまで差が出るとは想像もしておりませんでした。

タイヤ外径にこれだけ差があるんなら、各所のクリアランスにも注意しとかなあきませんでしたわ。というのを今さら理解したしだい。

スプロケットを夏仕様に（なにそれ…）

既にレガシーなカンパ11sですが、実使用のスプロケットとして12-27と12-32の２つを持ってます。

SCAPIN車に当初装着されていたのがATHENACHORUSの12-27でしたが、当時自分はシマノR7000の11-30を使っていて「27じゃ厳しすぎるかもなー」と思って、リアディレイラのキャパオーバーを承知でCHORUSCentaurの12-32を手当したものです。

しばらく12-32を使っていましたが、体調の具合や「頑張りすぎない漕ぎ方」などもあって12-27に戻していました。32を付けてても「なんや、27でもワリと登れるんやなぁ」と思うことが増えたのもありまして…。

でも、今また12-32を装着した、ということで。

27だと苦しくても32ならめちゃ楽、なんてことはあまり無いんですが、「もうあと１枚まだある」と思えるだけで気持ち的に楽になりますので…。これからの暑い季節、ヘロヘロになる機会も多いでしょうし、いざっ！って時の「もう１枚」があっても良いでしょう、と。

WarpinatorからPacketへ

スマホ〜スマホ間、スマホ〜パソコン間のファイル転送では長らくWarpinatorを使ってきました。Win10からLinux MINTに引っ越した時にWarpinatorなるツールがあるのを知り、Android向けに非公式アプリがありWindows向けにもWinpinatorなる非公式アプリがあることを知って、「これはファイル交換するのに便利やん」ということで使ってきました。

が、AndroidにはQuick Shareというネイティブの機能があり、Google謹製の他アプリから便利に呼び出せるようになっています。また最近はAppleデバイスのAirDropともファイル送受信できるようになっているので、パソコン側もQuick Shareに対応できれば「けっこう便利かもなぁ…」なんて…

で、調べてみると rquickshare なるものが見つかりましたが、何故か上手く機能しなくて…詳しく調べることもせず諦めて、もう１つ見つかった Packet を試すことにしました。ありがたいことに、これがすんなりイケて「これにしよ！」ということで採用決定。

偶然にもパソコンにはBluetoothを使えるようにするのが目的でIntel AX210なNVMe2230カードを入れて有効化してあり、WiFiは用事が無かったのでOFFにしていましたが、Quick Shareが使えるならば…ということで、WiFi接続も常時有効に。

Packet自体はFlatpakから手軽にインストールしました。ufw（ファイアーウォール）設定もインストール中に面倒見てくれるのですが、ファイアーウォール定義は自分流管理方法があるのでそれに合う形で設定し直しました。

★

後から分かった事ですが…

Kubuntu 26.04に変えてamdgpuドライバを導入した以降、Warpinatorが起動できなくなりました。「カーネルかモジュールの関係か…」と思って Warpinatorをビルドし直したら、とりあえず起動してくれるようになりました。が…Pythonが3.14になったことの弊害なのか（よく調べてもいませんが…）Warpinatorがクラッシュしてしまい…

結局、Warpinatorに代わってQuick Shareのみを使う環境になりました。