Fedora36

新しい版が発表されました。なので手順に従ってUpgrade。古式ゆかしくコンソールからコマンドを打ち込んでの作業です。

なんだかんだで今回は1つのモジュールが更新できないとの話しでしたが、Optionの–skip-brokenをつけてやったら全部OKとなりました。

KDE spinであるせいもあって何が変わったのかよくわからないですね。唯一はっきりしているのはSRPMをダウンロードするのためのgftpの設定でJAISTがipv6でアクセスしに行って討ち死にしたくらいかな。

あれこれ設定して、とりあえずipv6を無効化してなんとかクリア。あとはgftpのブックマークの変更と更新分のSRPMの取り出し。今回は出遅れた分インストール時にだいぶ更新が含まれたようで初回取得のリストはいつもの2/3くらい。それでも600程度はありますから先は長そう。

遅ればせながらのSMB2

社内サーバーの共有ストレージ用にSambaを利用しています。しばらくはSMB1での運用でしたが、MicrosoftがSMB1を取り除くとの方針が発表されました。

SMB1->SMB2の時にはセキュリティ証明書が必要になると思い込んでいたので、判ってはいたのですが全く行動に移さずにいましたが、どうもそうではない模様。

単純に/etc/samba/smb.confに”min protocol = SMB2″の一文を追加するだけのことでした。実際にやってみましたが全く問題は起きません。
こんなことならもっと早くやっておくんだったな…

リモートデスクトップ接続

Windowsには標準でリモートデスクトップ接続の機能があります。職場でのサーバー管理に便利に使っていたのですが、3月の末頃から妙なエラーが発生して接続できない状態となりました。

ちょっとした作業なら定番のTeraTermを使ってコンソールで済ませることができるのですが、「GUIに頼るなんてトーシロだな」なんて声が聞こえてきますが、ファイルを大量に加工するとか中のゴミを大掃除するなんて作業の場合はGUIで楽にやりたいものです。

接続拒絶のダイアログに表示されるメッセージには「セキュリティレベル」がどうのこうのと出ます。Linuxサイドには特に変更を加えたつもりはないので、戸惑うばかり。WindowsのProでもHomeでも同じ問題が出て接続できせん。また、このリモート接続でのセキュリティレベル云々の問題はネットを漁っても情報がありません。

散々探してようやく突き当たったのが、なんと接続時の色数の問題。Linux側はxrdpなのですが、/etc/xrdp.iniの設定で色数設定を32から24にすると良いとの情報が見つかりました。で、ここを変更してやったところ無事に接続できるようになりました。

#hidelogwindow=true
max_bpp=32 <- ここを24へ
new_cursors=true

こんな設定いじったことは無いはずなのですが、どうにも妙。各種ログを確認したところ3月末にyumでxrdpが自動更新されてました。そのときにiniファイルも更新されてしまったのでしょうね。迷惑だな…

それにしても32bppだと問題になるセキュリティって何なのでしょうね。なんか闇だな。

システムエラー

エンジンを始動した途端になにやら不穏なメッセージが表示されました。

エレクトロニックパーキングブレーキとかありますが、要は電動のパーキングブレーキシステム。ギアセレクター横のボタンで掛けたり開放したりできます。
とりあえずこういう時には一旦システム再起動が鉄則なので、一旦OFFにして少し待機。再始動したところメッセージは消えたのでした。

実はこのメッセージが出るのは初めてではないのですが、毎回再始動で消えてしまうので放置していたのでした。が、さすがに3回も見ると穏やかでは居られませんのでディーラーに連絡。近々修理となる予定です。

まぁそれにしてもあれこれ電脳仕掛けになってきているので、いろいろとつまらないことが原因のエラーが多発するようになってきましたね。
昔の車なら、サイドブレーキのトラブルといったらワイヤーが伸びて効きが甘くなるとか、どこかに引っかかって戻らないといった単純な物が多く、その場でなんとかできることが多かったのですが、コントロールユニットがどこにあるかもよく解らないブラックボックス化している現代の車では下手に手出しができないので、こういった時には困ります。

Windows側でRTCをUTCにする

LinuxとWindowsとを往復すると、RTCの取り扱いの問題で時間がずれます。
うっとうしいので、Linux側をいじったところ変な警告が出たという話は前回しました。なので今回はWindows側の対策の話。

まぁ難しいことは無くて、レジストリエディターで1項目追加するだけです。追加するのは次の項目

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

このレジストリエントリを追加してDWORDで1をセットします。あとは再起動するだけ。再起動すれば当然9時間ずれますので、時刻合わせを行っておきます。

それにしてもまだまだWindowsにもいろいろな機能が隠されていますね。みなさんどうやって見つけているんだろうか。Windows SDKあたりにヒントが隠されているのかな?

ちょっとした小技

LinuxからWindowsに戻すと時刻が-9時間となって鬱陶しいです。

[xxxxx@localhost ~]$ timedatectl
               Local time: 日 2022-03-13 12:15:19 JST
           Universal time: 日 2022-03-13 03:15:19 UTC
                 RTC time: 日 2022-03-13 03:15:20
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no 

それは上記のようにPCの内部時計(RTC)がUTCに同期してしまうからです。LinuxサイドではRTCのデーターから指定されたTimeZoneデータを元に現在時刻を出すので問題無いのですが、WindowsはRTCがローカルタイムであることが前提になっています。
これだとWindowsに戻ったときにいちいち時計合わせしなくてはならず、面倒なので、LinuxサイドのRTCをローカルタイムに合わせてみます。

[xxxxx@localhost ~]$ sudo timedatectl set-local-rtc 1
[xxxxx@localhost ~]$ timedatectl
               Local time: 日 2022-03-13 12:21:18 JST
           Universal time: 日 2022-03-13 03:21:18 UTC
                 RTC time: 日 2022-03-13 12:21:18
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.

しかし、「いろいろと不都合が出るかもよ」と”脅されます”。ならばともう一度調べたところWindows側のRTCをUTCに合わせる方法もあるとのこと。普段はLinuxなので、Windowsの方を合わせることにしましょう。

Videoカード交換その2

本番環境はFedoraなので、そちらを起動。するとKDEのスクリーンになったところで固まってしまいGUIの反応がなくなります。ただし別に起動しておいたKonsoleは動いているので、システム全体が死んだわけでありません。

クリーンインストールが必要かと勘違いしてbootable mediaを作成。でもやっぱり同じく固まる。ならばとMint Desktopのbootable mediaを作成して試したところこらはOK。

しばらくMintで凌ぐかと考えたのですが、よく考えてみたらドライバーが不適合なだけと言うことに気がついてnVidiaのドライバーをインストール。rpmfusion-non-freeにドライバーがあるので、rpmfusion-non-freeをenableにしてインストール。ようやく全体が正常に動くようになったのでした。

[xxxxx@localhost ~] sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
[xxxxx@localhost ~] sudo dnf install akmod-nvidia

AMDならともかく、NvidiaのGeForceシリーズならデフォルトでカバーされているものとばかり思っていたのでこれは意外でした。もっともMintではそのままでOKでしたから、これはKDE特有の問題かもしれません。KDEの人はNvidiaが嫌いなのかな(笑)。

Videoカードの交換でドライバーが必要になったのは、2013年にAMDのカードに変えた時なので、9年ほど遭遇しなかった事態です。なのですっかり忘れてちょっと焦ったのでした。

3月21日追記

どうにも各ウィンドウの中身の表示がちらついたりして落ち着きません。Nvidiaの場合、cudaドライバーも入れないと駄目だとのことなのでインストール。
cudaってGPUで演算するための機構というイメージが強いので、別にいいかと思ったのでした。記事によっても「入れてもいいよ」から「入れないと問題が起きるかもね」まであっていろいろ。

[xxxxx@localhost mak]$ sudo dnf install xorg-x11-drv-nvidia-cuda
=====================================================================================================================
 パッケージ                       Arch           バージョン                  リポジトリー                      サイズ
=====================================================================================================================
インストール:
 xorg-x11-drv-nvidia-cuda         x86_64         3:510.47.03-1.fc35          rpmfusion-nonfree-updates         1.8 M
依存関係のインストール:
 nvidia-persistenced              x86_64         3:510.47.03-1.fc35          rpmfusion-nonfree-updates          34 k
 opencl-filesystem                noarch         1.0-14.fc35                 fedora                            7.4 k

トランザクションの概要
=====================================================================================================================
インストール  3 パッケージ

cudaを入れたところなんとなく落ち着いた感じ。まだ再起動していないので本当かどうかはわかりませんけど。

さらに追記

cuda入れても変わりは無し。なのでwaylandをあきらめてxorgにスイッチ。今のところ落ち着いている感じ。多少はパフォーマンスが落ちるんでしょうけど、安定がなにより第一!

Videoカード交換

自宅PCのVideoカード不調が悪化してしまい、WindowsでもLinuxでも突然に一面単色になって無反応となることが増えてきました。本当に突然落ちるので困ります。

現PCは現在8年目のi4770使用の物。一応内蔵グラフィック(HD4600)が使用できるので急場はしのげますが、どうしてもパフォーマンスはがた落ちです。また接続が15pinのVGAケーブルでの「アナログ」接続なので目にも厳しい…
PC入れ替えるかと考えて中古を探してみましたが、現状と変わらない第4世代CPUの品でも3~4万。せめて第7世代くらいにはしたいものだと思うのですが、物が有りません。

もちろん新品で同じような構成を取ると軽く10万に達してしまうのでこちらも現実的な方法ではありません。

と言うわけでバクチではありますが、Videoカードの交換を実施。それにしても選択肢が極端になってしまいましたね。今回選んだGT1030はかなりのロースペックなのですが、だからといってこの次はGT1050TiやGTX1650となって価格も3万近く。補助電源は必要だし、冷却も大変。1030と1050Tiの間のスペックの品が無いので、困ります。

結局は約10k円出してGT1030の安いやつを調達しました。
安いだけあって小さくてちゃちな品物です。
全体が真っ白のレジストに覆われているのは斬新かもしれません。
出力はHDMIとDVIだけ。Display Portは対応しません。

で、3D Mark11を走らせてみましたが、HD4600の3倍のパフォーマンスなので、一応交換しただけのことはあったという結果。ただし、前カードのRX550の70%程度なのでRX550の優秀さが光ります。価格もこちらは7.5k円でしたしね。とは言ってもまともに動かなければただのゴミですからこれはやむを得ないな。
後は壊れずに使えることを願うだけです。

KiCAD V6その4

どうにか時間が取れたので、本体のbuild開始。30分くらいで終わった気がします。

今回、VSでProjectを開くのにドキュメントと違う方法試したところドはまり。cmakesettings.jsonにswig.exeとpython.exeのありかを書いておけば、特に何も追加指定せずに実行できるはずと、あれこれやりましたがエラーが取れなくて一旦中止。cmakesettings.jsonの書式を勉強しないとだめですね…

今度はドキュメント通りにprojectを開き、ドキュメントにある通りにswig.exeとpython.exeの在処を書き込んでビルド開始。ビルドオプションは生成するオブジェクト毎に分かれています。x86-debug,x86-release,x64-debug,x64-release,MSYS2-x64-debugとあるのですが、x86とMSYS2は使用しないのでx86の2つにだけ追加。

出来上がったのはよいのだけど、何このバージョン表記。またnightlyからソースを引っ張ってきてしまったようだ… 進歩無いな。もう一度6.01のソースをとってくるところからやり直さなきゃ。

KiCAD V6その3

いろいろ情報を漁っていたところ、文字コードをUTF8にするオプションが有ることを発見。コントールパネルの「時計と地域」→「地域」→(管理タブ)と辿っていくとUnicode対応というチェックがあります。ベータと書いてあるのが気になりますが、デフォルトで用意されているのだからと、チェックを入れて再起動。再度vcpkgの作成に挑戦します。

文字コード変更

その結果は大成功で、止まることなく進行していきます。嬉しいことにネイティブ環境なので、当たり前ですがVM環境下より早い。途中でlibiconvだったかがエラーになっていたのだけど、全体として停止せずに進んでいるので必要無いってことなんだろうか? これは後でどう影響するか気になります。まぁ実行する前にもう一度構築してみますかね。

さてVM環境下ではかなりの時間を要したvcpkgの構築、どの程度で終わるのか楽しみだ。

16:55追記

外出から戻ってきたら終わってました。所要時間は2.8hとのことですから2時間50分ほど。VMの時は7時間以上だったので大幅短縮です。buildもこの調子だと嬉しいな。

2月13日追記

vcpkgが更新されていたので、gitで取り直して更新。途中sqlite3の処理でエラーになったけど、再度実行したら止まることなく実行中。なんだったかな?