またしても失敗したので、対応策をメモ。
Kernelが変わった場合、
sudo akmods –kernels $(uname -r) –rebuild
を実行してkmodを有効化すること。
Jamano's Blog 2nd gen.
またしても失敗したので、対応策をメモ。
Kernelが変わった場合、
sudo akmods –kernels $(uname -r) –rebuild
を実行してkmodを有効化すること。
Fedora40にUpgradeしたのですが、各モジュールのrebuildで問題多発。QT6のcmake定義がないとかなんとか。kf6(KDE 6)のメインモジュールやplasma関係のrpmがかなり引っかかります。
いろいろ調べて処置してみるのですがまったく改善されません。
しばらくもやもやしていたのですが、VMに新規インストールしたらどうなるのかと気付きました。
VM player ProがVer.17から個人利用であれば使用できるようになったので早速セットアップ。そしてFedora40をISOイメージからインストールしてあれこれ準備。
ちなみにVMへだと、UEFIでなければインストール不能となっているFedora40が若干の問題だけでインストールができます。
さっそくrebuildしたところ問題なく進行していきます。ならばと思い、/usr/lib64/qt6/cmakeの中身を全部取り出して、VMでない方にコピーします。本来は一つずつどこがどう違うか調べるべきでしたが、一気に上書きしたので何がNGだったのかは不明ですが、rebuildは本番環境でも問題なく進むようになりました。あとはネット関係が引っかかるのを解決できれば問題解決なんだけど、どこから調べていきますかね。現状ではVM上のFedoraの方がスムーズに動きますので。
だからと言って全面的にVM環境下へ移行することも検討しましたが、どうしたってパフォーマンスは落ちますから、正しい選択とも思えません。
さてもう一息頑張りましょうか。
いろいろあって専念できなかった関係も有ってようやく-O3化終了です。
4453モジュール中4273モジュールが-O3化できました。率としては約96%。まぁそんなものですかね。
さて次は何して遊ぶかな。その前にPCをなんとかするのが先決?
Windows側での作業が一段落したのでLinux側での作業開始。時間はかかったようですが、無事に39にUpgradeができました。
相変わらずなにがどうなったことやら(苦笑)。Consoleのプロンプトの形が少し変わったのは気が付きましたが、他はさっぱり…
思い返せばFedoraCore2からの付き合いですからね。調べたらFC2の登場が2004年5月ですから18年半ほどが経過したことになります。で、使う側の技量がそれだけ上がったのかというと… ですねぇ(苦笑)
Desktopも最初はGnomeでしたが、GNOME3になったときにどうにも違和感だらけだったのでKDEにスイッチして以来KDEとの付き合いです。KDEも5になりたての時はトラブルが多かったのですが、以後だいぶ安定するようになりましたね。そろそろ6って噂も聞こえてきますがどうなりますやら。
さあ、恒例の-O3化。ツールは揃えたのであとはソースを用意するだけ。手始めにめちゃくちゃ時間のかかるgccから行きますか。
ラジオ放送の整理で時間がとられている間に39がリリースされていました。
Fedoraは半年ごとに更新なのでお約束ではありますが、見た感じ大きく変わったところが無いので更新しがいが…
もたもたしていると40が出てしまうので早めに更新しないとね。
クリーンインストールはできないので祈るようにして実行するdnf upgrade….
さて今回はどうなることやら。
-O3化が一段落して、日常に復旧しました。で、いつものようにupdateモジュールどものrebuild。ところがまたしても途中でPCが気絶する事態に陥ってしまいました。何をしてもキーボードからは反応がありません。メニューからrebootを選びますが先に進まない… デスクトップのウィジェットはちゃんと反応しているのがなんとも悔しい状態。
しかたがないので強制電源断。このまま再起動すると前回同様怪しいことになりそうだったので、一旦36のBootable Mediaで起動です。しかしKDE spinなので例によって停止します。
毎回ビデオカードの脱着は面倒なので、ここで新しいDesktop環境のBootable Mediaを作ることにします。とりあえず38のCinamonを作成してBoot。見事に起動せず… UEFI未対応PCだとBootable Meidaからも起動できないとは… トホホ と言う訳でアーカイブを漁って36のCinamon DesktopのBootable Mediaを作成して起動します。
lsblkで対象ドライブを確認してxfs_repairを実行。当該デバイスのlogが変だから一旦mountしろやと出ましたので適当にディレクトリを作ってmountしてからumount。
その後再度xfs_repairを実行。いくつか「注意」は出ましたが、さほど大事にならずに修復終了。
あとはシステムを再起動してどこからも苦情が出ないことを確認します。
いやはやびっくりしたな。
SRPMを取り出すツールを作ったので、ついでとばかりに全体の-o3化にとりかかり、なんとか終了しました。
-o3化できたのが1834ファイルで、失敗が123ファイル。失敗の中にはどうにもならない依存関係のある物も含まれていますので、純粋に謎のrebuildエラーで出来上がらなかったのは7割くらいじゃないでしょうか。
それにしてもPythonからみでファイルやディレクトリが見つからないというエラーがたくさんあって、どうもPythonは具合悪いですね。いろいろな依存関係からから多数のバージョンが同居している状態は気持ち悪いです。
ところで-o3化したことで、全体の感じに変化があったのかなんですが、これが少しずついじっていったこともあってよくわからないというのが実態。rebuild時間の短縮とか、ちょっとしたレスポンスの向上などがあるはずなんですが、一気に入れ替えてみないと実感できないなぁというのが正直な感想です。
でも自力でrebuildしたシステムを使用しているわけで、たぶんこれが本来のLinuxの使いたかだよなと自己満足しています。
と言うわけで早速半自動取り出しスクリプトを作成
# # エラーリストなどから自動で.srpmを取り出すためのスクリプト # getsrc.sh #! /bin/sh cat $1 | gawk '{ print $1 }'|grep "[0-9A-Za-z]"|grep -v '^setting' > ./temp.txt cmd="" spc=" " for fn in $(cat ./temp.txt); do if [ $fn == "RPM" ]; then break fi cmd=$cmd$spc$fn$spc done rm temp.txt -f echo $cmd dnf download --source --destdir ./SRPMS $cmd
楽ですね。さらに楽だなぁと思ったのは重複している場合やすでにダウンロードしている場合には自動でスキップしてくれる点です。なので、何も考えずにリストを作成してこのスクリプトに食わせてやればOK。
dnfの直前のecho $cmdは確認用でもあるので、無くても問題はないですね。
例えばlist1.txtなるファイルに
tcpdump-4.99.4-1.fc38.x86_64 tigervnc-server-minimal-1.13.1-3.fc38.x86_64 time-1.9-20.fc38.x86_64 tmux-3.3a-3.fc38.x86_64
と言った感じで羅列してやり、あとは
$ ./getsrc.sh list1.txt
これだけで、このディレクトリ内の./SRPMS内に.srpmがダウンロードされます。リストにはバージョン情報は無くてもよいので、単に
tcpdump tigervnc-server-minimal time tmux
でもOKです。
いや、もっと早く気づいていれば楽できたのにな…
-O3化の作業で.srpmを引っ張ってくるのにいちいち手動でftpを利用するのは面倒です。さらに.srpm自体がupdate側にあるのかそうでないかまで判断しなくてはなりません。
なんとかならんかと考えていたところ、なんとdnfに.srpmをダウンロードする機能が存在することが判明。
しかもupdate側かどうかまで自動で判別してコマンド発行時点での最新を引っ張ってくれます。ファイル名は厳密にチェックされますが、バージョンまでは指定する必要がないのでとても便利。
dnf download --source file名1 file名2...
インストール済みやdnf check-updateで示されるrpmモジュール名からバージョン情報を取りのぞくスクリプトはgawkかpython+正規表現を使えば簡単に書けますから、.srpmの取り出しも半自動化できます。
早く気付けば良かったな。これでftpは必要無くなった?
Fedora38の三度目のインストール騒ぎ。その際にgroupinstallなど手動でインストールでモジュール類が明確に分かった各種ツール類の-O3化がようやく終わりました。
生成済みrpmの確認用のツールも作ったので、ついでだと言う訳で現在システム内に入っているrpmどもの内どの程度が-O3化されているのか確認してみることに。
その結果インストール済みが6,185モジュールでその内処理済みは3,212モジュールとだいたい半分。
最初から入っていた分でまだupdateが来ていないものがこれだけ有るということになります。もちろん依存関係やどうしても解決できないrebuid時のエラーによって-O3化できない物もあるので未処理分の全部が取り掛かっていないと言う訳ではありませんが、まだ結構残っている感じ。
rebuildエラーになったsrpmから生成されるrpmモジュールを取り出すツールを用意して、この際だからできる分は全部片づけてみますかね。