タグ: Windows

Clean Install

Fedoraのことではなく、職場PCのこと。

Windows11 23H2への更新に失敗して以来ずっと24H2への更新に失敗続き。ErrorLogを見るも結構な量の依存があって一筋縄ではいかない雰囲気。さらに状況が悪化して遂にはリカバリーによる修復もできず、さらに悪いことにwindows updateもPC Health checkも走らなくなりました。

機能的には使用できていますが非常に気分が悪い。さらに25H2が出て23H2もEOL…
仕方がないのでクリーンインストール敢行です。

まずあちこち検索してwindows11のインストールイメージを調達。7Gもあってびっくりです。DVDでも1枚に収まらない!、何入っているんだろうな…　それにしてもMircosoftの中って探しにくいよな…
そして、関係データーを別ドライブに避難して作成したbootメディアで起動。

1回めは各ドライブを接続したままでやったので、中途半端に失敗です。なので、無関係なドライブを外して再度実行。思い切って全パーティションを削除してまったくの更の状態にしてやって、ようやくインストールが成功しました。

このマザー(Asrock H570)の癖なのか、設定が悪いのかドライブの検索順がSATA->NvmeなのでSATAに何かドライブを繋いでいると、そちらに書き込み行こうとするので厄介でしたね。

あとはボチボチ各種アプリとデーターを戻していきます。例によってOutlookの振り分けルールが復旧できないのが謎です。pstファイルを戻してやって、中のメールデーターは全部読めるのにな… かと言ってルールのexport/importって一括全部ではなく、1個ずつなので、面倒で効率の悪いこと夥しい… ThunderbirdでもBecky!でも関係フォルダーを戻すだけで、完全に元に戻るのに。もうOutlook止めてやるかなぁ。

Thunderbirdは複数メールアカウントの取扱に少し難が有るし、Becky!だとカレンダーが使えない。しかもどちらもoutlookからhtmlメールを送られたときにメール本体が1つにまとまった形にされてしまうデーター(winmail.dat)を復元できないので、弱りもの。

またVisioはMicrosoft365のSoloエディションではなく、Businessエディションなので、アカウントの切り替えなどでドタバタ。Visioもデスクトップアプリのインストールに辿り着くのに毎度苦労させられます。

MSとしては「もうWebアプリだけでいいじゃん」って事なんでしょうけど、インターネットが常に使用できるわけではないのでOff-lineでも使用できないと困ります。
客先によっては通信機器持ち込み禁止ってところもありますし。

全アプリケーションを戻すのにあと丸1日はかかりそうだな、やれやれ。

新PC導入

今まで使用していたPCは仕事用に導入したものですが、2013年製。つまり12年落ちです。よくぞ持ったものだとは思います。ただし、ビデオカードは3枚交換してますけどね。
未だに少々遅いことを除けば大した不満もないのですが、やはり12年落ちともなるといろいろと不安が高まってくるのと、最近はCPUをひっくるめてある程度新しくないとOSの更新すらままなりません。特にレガシーBIOS式なのが致命的です。
なので思い切って1台お買い上げ…

とは言っても新品ではなく中古。i5-10400ですから5年落ち。マザーボードはB460という廉価版ですが、一応NVMeの1T SSD搭載だし、グラフィックボードとしてRTX2060Superがついてきます。中古とは言え、メインストリームのグラフィックボードを導入するのは初めてです。メモリは16GBで、トータルで50k円でしたから、まあまあの買い物です。あとなぜかWindowsは11のpro版です。

さっそく3DMarkを走らせてみましたが、さすがにメインストリームのカードは違います。いままで見たこともないようなシーンが出てきたり、各シーンが滑らかに動作します。現在職場にあるi7-11700+32GB+GTX1650の組み合わせの倍のスコアを出してきますから、滑らかに動くのも納得です。ちなみに旧PCはi4770+GT1030なので現PCの1/5程度の性能しかありません。
もっともゲームをするために導入したPCではないので、この性能はもてあまします。
消費電力もCPUが65Wなのに対してグラフィックボードは175Wの消費なのでなんか本末転倒… もっとも最近のRTX4000シリーズや5000シリーズでは消費電力600Wなんてただのヒーターだろうってなモノもあるので、それらに比べたらまぁバランスはとれているのかな。

旧PCからストレージを移植して内部の変更は一段落。内臓メモリーカードリーダーどうするかな。またSSDが5年落ちなのでTBWが心配です。

またそれなりに早いPCに代わると画面をもっと広くしたいという欲求が湧いてきます。
現用機は1920×1600の24インチですけど、こちらも2012年製ともう13年選手です。
ストレージの手当の前にディスプレイかな。現在DisplayPort->DVIアダプタを通して使ってますけど何かドライバー側で検出に手間取るのか起動がスムーズではないのが気になります。直接HDMIなりDisplayPortなりで接続してやれば改善される気がします。


KiCAD winbuild

PCのOSがWindows11になりました。なのでと言う訳でもないのですがbuildシステムがpowershellのshell scriptベースとなったので、改めて挑戦。

説明ページ(https://gitlab.com/kicad/packaging/kicad-win-builder)によればgitを入れとけばOKとのことだったので、一式をgitリポジトリから持ってきて実行開始。

いきなり「powershellではスクリプト実行できません」攻撃を喰らい撃沈。セキュリティ上の仕様によりスクリプトは実行できない状態にしてあるとかなんとか。いきなり丸腰ってもどうかと思ったので制限付き実行可状態として再度挑戦。

あれやこれやをダウンロードしているようで順調です。が、「cmakeが無い」と苦情。こんなことも有ろうかと思ってcmakeを最新版を入れてPathも通しておいたのですがダメ。よくエラーメッセージを見るとパス決め打ちでそこにcmakeが無いと。しかもバージョンまで決め打ちされているのでcmakeのアーカイブから当該バージョンを引っ張ってきて、再挑戦。

が、結果的には最後のあたりでエラーになって結局は自前buildには失敗です。

本家ではどうやってパッケージを作成してんでしょうね。毎度のことながら謎だ。

ドジな話

MSより怪しげなアクティビティが検出されましたとのお知らせ。最近はこの手のメール自体が胡散臭い場合が多いのですが、MSにアクセスしてみると確かになんか怪しいアクセスが記録されています。

なので慌ててPasswordの変更開始。まぁ一回やられているのであれぱ、いまさら変更しても遅いんですけど… まぁ気休めというか何と言うか。
適当にパスワードを決めて登録しなおし。今回はDicewareという英単語を適当に並べてくるソフトを利用。非常に長いパスワードを生成して、登録しなおし。

当然あれこれが全滅しますので関係PC全部で関係パスワードを変更しなくてはなりません。自宅で自分のアカウントの変更をしたので、職場のPCの変更しなくてはと職場へ。

ところがパスワードのメモをOnedriveに仕舞ったのは良いのですが、スマートフォンでのOnedriveのパスワード変更を忘れていたので、当然のことですがオンラインファイルはアクセス不能に…
しかたなく一度家に戻ってから作業再開。時間の無駄でしたね。

やはりパスワードは紙に書いとけってのが最強ですかね。セキュリティ的にどうかと思いますが。

遅ればせながらの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だと問題になるセキュリティって何なのでしょうね。なんか闇だな。

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の方を合わせることにしましょう。

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の処理でエラーになったけど、再度実行したら止まることなく実行中。なんだったかな?