タグ: Linux

またやっちまった…

またしてもgrub2でトラブル。起動不能になってしまいました。
こんな時のための忘備録というわけで、作業をしたのですが、どうも新規インストール扱いとなってしまったようで、「オマエのPCはUEFIでないから起動設定不可!」とメッセージが出てオシマイ…

さて方法は3つ。

  • 1. とりあえず36まで戻って(36のBootable Mediaを作って)、36の環境を作成してupgradeをかける
  • 2. Fedoraをあきらめて他のDistributionに移行する
  • 3. 新しいPCを購入する

選択肢2の他のディストリですが、現在元気なのはUbuntuなんですが、ベースがDebianなのが大いに問題。どうもUbuntuの世界では自前でパッケージを最適化rebuildすることは無いようで、ほとんど情報が出てきません。
やはり使い慣れたRedHat系がいいなと思うと、CentOSとなるのですが、こちらもかなり混乱していてCentOS7より8の方が先にEOLが来るというカオス。

UEFIの他にx86のv2以降でないと使えなくなるディストリが増えそうな気配もあるので、そうなると10年目が見えてきたこのPCを廃棄して新しいPCもしくは8世代目あたりのCPUを積んだ中古PCを購入ということなります。価格見てみましたが第8世代あたりはまだ高いですね。i7-8700搭載機だとi5-12400辺りの新品と価格が変わりません。
現状のPCはグラフィックボードが非常に高価になっているので内蔵グラフィック以外だと結構な金額となってしまいますので、悩みも深い。

と言う訳で、とりあえず1の一旦36に戻してからUpgradeを実施。37になってまだ日が浅いのでさほどの大ごとにもならずに37に戻れました。rpmのrebuild環境はこれからなんですが、ぼちぼちやっていきましょう。まぁこちらは道楽なんで焦る必要も無いし。

Fedora37

お約束のように37がやってきました。36は様々なドタバタのおかげでほとんど触った気がしないうちに終わってしまいました。

例によってcuiで古式ゆかしく更新をかけて終了。今回はlv2-develが気に入らないとのことでしたが、削除してやって問題解決。dnfの–allowerasingオプションが機能しなかったのがちょっと癪に障ったりします。
トータルで6400ほどのrpm更新となったようなので、総処理時間は不明です。(寝ている間にPCに頑張ってもらいました(汗))。

再起動後いつものようにftpの設定などを変更して、以後のupdateに備えます。が、すでにかなりの数のupdateが登録されていてびっくり。流石にFedoraだなぁと。ただし、手動更新の時点ですでにupdateが適用されているので今現在はdnf updateのリストにはなにも載ってきません。

とりあえず、いつものようにgcc、kf5のあれこれ、cmake,make,tar,xorg-sever,firefox,thunderbird,libreofficeあたりから-O3化を進めていきましょう。

ドジな話Part2その後の続き

諸々のリビルドとアップデートを着々と進めて、残りの大物としてはLibreofficeを残すのみとなりました。

KF5の地獄はいつものことなんですが、うっかりghcとrustのリビルドに入ったところ、出てくる出てくる関連ファイルの山。使いもしないのにghcとrustの殆どのrpmモジュールをインストールしたんではないかな。それでいてghc本体はエラーで作成できずと何やってんだか解らなくなりました。

さてある程度作成も済んだので一旦再起動しようとしたところ、またしてもgrub2のエラーでFedoraが起動不能に。そのままだとWindows側も道連れなのでBIOS(UEFI?)の設定を変更してとりあえずWindowsは起動できる状態に戻しました。

このgrub2の問題、いい加減にしてほしいなぁ。面倒なので再インストールはしたくありません。なので本腰を入れて対処方法を探らなくては、いやはや面倒なことだ。

まぁこれがFedoraの世界でもあるのですがね。

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

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

ちょっとした小技

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

Fedora35苦戦中

Kicadの方が一段落したので、本当の目的であるFedoraの環境構築。それが今回はとても手強い。いままでの環境との違いと言えば、いままではBIOS経由だったのが、今回からはUEFI経由のBootとなったくらいのはずなんですが、謎の現象が起きていて全く落ち着きません。

インストール自体はUSBメモリースティックにインストーラーパッケージを入れてやってそこから起動するだけのことで、難しいことはありません。ものの20分もあれば終わるくらいのお手軽なもの。

ところが、Fedora恒例のインストール後のUpdateをかけるとあっという間に起動不能となります。「Boot Sector not found…」てなメッセージが出るのでどうにもなりません。

一番最初は画面が一面「水色」となる現象が出たので、ビデオカードの不調で吹っ飛んでドライブがこけたのかと思ったのですが、どうも違う様子。だいたい同じハード構成のWindowsはクリーンインストール後は実に安定しているので、ハード系の問題では無いはず。
ドライブの構成の問題かと思い、完全手動構成、完全自動構成、LVM使用の自動構成といろいろと試しましたが、どの構成でもUpdate終了後の再起動ができなくなる事にはには変わりなく、しかもネット上にもほとんど情報がなくて大弱り。

謎なので、VM上にインストールしてupdateしてみましたが、全く問題が発生しません。

起動系をいじくるのはgrub2しか無いのでgrub2の更新をせずに他を更新した場合にどうなるのか試してみましょう。

SSD導入

通販屋からのメールで960GBのSSDが特価になっていたので、早速注文。消費税が上がる前だったので、総額7800円で購入できました。1GBあたり10円切っていますので随分安くなったものです。

960GB SSD
激安SSD

職場のPCへ入れようと考えたのですが、960Gだとちょっと不足なので自宅PCへ。LinuxをSSDへ載せようという訳です。
もともと1.5TBの領域を使用していたのでclone化ツールだと面倒そうなのでパス。まぁFedoraなんで新規に入れるのも手間ではありませんので、HDDとSSDとでケーブルを付け替えてSSDへ新規にインストール。一通り設定が終わった所で、HDDから必要な部分(homeディレクトリの中身とか、rpmのrebuildに使ってるディレクトリの中身など)を書き戻して、再起動。

例によってなにかが気に障ったようでGUIモードで起動しなくなりましたが、コマンドモードを起動してあれこれ処置して再起動。今度は無事にGUIも立ち上がりました。
ちょっとメーラーの設定で悶着が有ったのですが、新しいやつを入れたり古いやつに戻したりしているうちに最新版で起動できるようになって一段落といったところ。
あとはrpmのrebuildをやってみて不足ツールやファイルを追加していけば元に戻る感じです。

それにしても全体に早くなりました。なによりHDDのシーク音(例のシャラシャラ言う音)が無くなってとても静か。
これでHDDがBusyになって全体が反応無しになってしまう状態が少しは減ってくれると良いな。

Fedora29 その後

ほぼトラブルフリーでインストールの終わった29。問題はその後でした。
横着してNTFSのディスクにバックアップしてやったところ、所有権だとかパーミッションがグダグダになってしまい、復元に一苦労。手を抜かずにext4にでもしておけばよかったなと反省。
今回は物理的に別ドライブにバックアップしましたが、よく考えてみたらメインのドライブにバックアップ用パーテーションを用意してあったのでした。もう少し早く気付かないと駄目ですね。

環境がすっかり初期化されてしまったので、rebuildに必要なモジュールが多すぎて毎度おなじみの騒ぎです。ようやくgccのrebuildが済んだところだけど、別のrpmファイルをrebuildするために必要となるモジュールが毎回10〜20出てくるので収束するにはだいぶ掛かりそう。
もっともこれが楽しみでいじっているとも言えるのですがね。

Fedora29

今回は順調に11月に29が出ました。さっそくUpgradeに挑戦しましたが、例によって失敗。なんか変な依存が有るとか言ってきますが、別に野良rpmは入れてないんだがな。
仕方がないので、再インストールしなくちゃ。
再インストールだと、現在のデーターが保存されないって言うか、一旦旧パーティションを削除しないと進めないので現在のデーターのバックアップから開始。あぁ面倒だし時間かかるし…
お散歩の間に終わってくれるかな。