Jamano's Blog 2nd gen.
色々と作業していたら結局の所GRUBの更新時には全部のドライブを活かせて置かないと駄目だということが判りました。また余計なものがあっても駄目。これが判るまで随分と時間を無駄にしてしまいました。
結局の所Fedoraの新規インストールを選択して全体の構成も整理したのでした。
で、ここで問題発生。
ぼちぼちやって行って、どうにかkf5とqt5は終わり。先にplasmaを処理してあとはボ更新の来たものから処置というところですかね。もたもたしていると、Fedoraなんで、次々に更新が降ってきて追いつかないという状態になります。
頑張らなきゃ(苦笑)。
先日のこと、PC内のファイルを整理していたらBIOSファイルが出てきました。CPU-Zで現在のBIOSバージョンを確認すると、後から見つかった方が4ステップ程進化している模様。タイムスタンプが2014年、即ち8年も前に取得して放っておいたファイルなので、今更更新する必要もないのですが、なんとなくフラフラと更新してしまいました。まぁ、更新用のExeファイルを実行すると確認されることも無く一気に進んでしまうので止めようもなかったというのもありますが…
1分もかからずに更新が済んで再起動。インストラクションに従ってBIOS画面を出して一旦Default値をLoadしてからあれこれいじって再起動。
Windowsは問題なく起動したのですが、Linuxが問題。BIOSのBoot Menu画面にすら出なくなってしまいました。当然のことながら起動はできません。
データーは残っているのでGrub2とUEFI-Bootの修復だけでなんとかなるんだろうか。
いやはや余計なことをしてしまったものだ。
MSより怪しげなアクティビティが検出されましたとのお知らせ。最近はこの手のメール自体が胡散臭い場合が多いのですが、MSにアクセスしてみると確かになんか怪しいアクセスが記録されています。
なので慌ててPasswordの変更開始。まぁ一回やられているのであれぱ、いまさら変更しても遅いんですけど… まぁ気休めというか何と言うか。
適当にパスワードを決めて登録しなおし。今回はDicewareという英単語を適当に並べてくるソフトを利用。非常に長いパスワードを生成して、登録しなおし。
当然あれこれが全滅しますので関係PC全部で関係パスワードを変更しなくてはなりません。自宅で自分のアカウントの変更をしたので、職場のPCの変更しなくてはと職場へ。
ところがパスワードのメモをOnedriveに仕舞ったのは良いのですが、スマートフォンでのOnedriveのパスワード変更を忘れていたので、当然のことですがオンラインファイルはアクセス不能に…
しかたなく一度家に戻ってから作業再開。時間の無駄でしたね。
やはりパスワードは紙に書いとけってのが最強ですかね。セキュリティ的にどうかと思いますが。
新しい版が発表されました。なので手順に従ってUpgrade。古式ゆかしくコンソールからコマンドを打ち込んでの作業です。
なんだかんだで今回は1つのモジュールが更新できないとの話しでしたが、Optionの–skip-brokenをつけてやったら全部OKとなりました。
KDE spinであるせいもあって何が変わったのかよくわからないですね。唯一はっきりしているのはSRPMをダウンロードするのためのgftpの設定でJAISTがipv6でアクセスしに行って討ち死にしたくらいかな。
あれこれ設定して、とりあえずipv6を無効化してなんとかクリア。あとはgftpのブックマークの変更と更新分のSRPMの取り出し。今回は出遅れた分インストール時にだいぶ更新が含まれたようで初回取得のリストはいつもの2/3くらい。それでも600程度はありますから先は長そう。
社内サーバーの共有ストレージ用に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回も見ると穏やかでは居られませんのでディーラーに連絡。近々修理となる予定です。
まぁそれにしてもあれこれ電脳仕掛けになってきているので、いろいろとつまらないことが原因のエラーが多発するようになってきましたね。
昔の車なら、サイドブレーキのトラブルといったらワイヤーが伸びて効きが甘くなるとか、どこかに引っかかって戻らないといった単純な物が多く、その場でなんとかできることが多かったのですが、コントロールユニットがどこにあるかもよく解らないブラックボックス化している現代の車では下手に手出しができないので、こういった時には困ります。
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の方を合わせることにしましょう。
本番環境は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にスイッチ。今のところ落ち着いている感じ。多少はパフォーマンスが落ちるんでしょうけど、安定がなにより第一!