其實是未能解決這個問題，而是索性把它整個停用了事。話說有一部安裝 RHEL 8 的工作站主機，平常的遠端檢查動作，基本上就是看能否正常 Wake-on-LAN 開機、SSH 登入，執行系統更新。然後視需要遠端重啟後，再確認依賴的驅動程式有跑起來，大概就是這些動作而已。然而近期有一次隨意地將 dmesg 指令的輸出結果叫出來看了一下，赫然發現有個 segfault。然後接著查看 /var/log/messages，才發現在看似一直可正常使用的情形下，其實系統背後有非常密集的錯誤記錄。
只要使用者在本機登入 GNOME 桌面環境後，用於提供桌面索引功能的 GNOME Tracker 就會開始出現服務啟動錯誤，首先訊息大概會是如下：
這是發生在一部老筆電 Aspire E1-571G（Core i3-3110M）上，選擇安裝的發行版是 RHEL 9，並且一如往常地換 SSD 及增加記憶體。這部筆電從一開始接手時，就並非是完全正常的狀態，有幾個出於年邁及逐漸耗損的毛病，但大致堪用。而硬體之於 Linux 作業系統的支援情形也並非是最佳狀態，其獨顯（GeForce GT 620M）所適用的舊版 NVIDIA 390xx Linux 驅動程式雖然裝得起來，但實際上無法正常運作，而自己也並未打算拿更舊的發行版來試；至於開源的 nouveau 驅動程式若拿來跑遊戲，實測起來則發現比 Intel 內顯更不正常，不如不用，所以索性是把獨顯直接從 BIOS 裡停用。
不過近期真正影響使用的問題，是筆電鍵盤開始出現顯著的異常。首先是鍵盤不時會在進入作業系統後沒有反應，但重開機可能就會好轉。後來認真看了一下，注意到若鍵盤無反應時，Linux 內核在一開始啟動時會有以下訊息（也可以用 dmesg 指令撈出來）：
這是近期將多部 RHEL 9.7 主機更新至 9.8 後所發現的另一個狀況，但由於出現此問題的主機，平常所存放的場域並沒有辦法那麼便利地處理電腦問題；再加上它前陣子主要是作為備用桌機，其用途已優先由安裝相同 OS 的筆電取代之，使用頻率較低，所以延宕較久才找時間處理掉。
這是一部宏碁 Acer 的老桌機（Aspire X1930，Pentium G620），BIOS 版本為 P01-B1（07/08/2011）。記憶體、磁碟（換 SSD）及顯卡（加裝 GeForce GT 1030）全部自行升級過，不是按原樣使用的狀態。發生的問題，是 Linux 內核版本從 RHEL 9.7 的 5.14.0-611 更新到 9.8 的 5.14.0-687 後，發現主機背後的 USB 連接埠，所連接的 USB 裝置（鍵盤、滑鼠等）在進入作業系統後都會失去作用。並且在一開始內核開機時，也會額外出現諸如以下的錯誤訊息：
前一陣子陸續將手邊的 RHEL 9.7 系統更新至 9.8 時所發生的一個插曲，發現內核版本更新後所產生的 initramfs 檔案變得相當肥大，大約從 30-40MB 擴張至 200MB 以上，會直接把 /boot 分割區塞爆……導致 initramfs 無法正常產出，而出現錯誤。再核對了一下，則發現這個情形只發生在 AWS EC2 上面的主機，其餘手邊的實體或虛擬機，相同的更新程序都沒有 initramfs 增大的情形。以及另一方面，不同於雲端主機的磁碟分割狀態，是預先分配好的情形，例如 /boot 可能會被切成僅有 500MB 大；平常自行手動安裝的 Linux 系統，自己都是選擇不切 /boot 分割區，自然也就不會有 /boot 被塞爆的狀況。
……這完完全全不是出於任何嚴肅性的需求，而是 100% 為了玩遊戲的緣故。由於基本上無法期待每款連線遊戲的區域網路搜尋功能，在各種不同條件下都能夠正常地運作。所以最直接的手段，就是在其中一部電腦開設遊戲伺服器後，其它電腦便在遊戲中手動輸入目標主機的 IP 位址，來進行連線（這些電腦全都是 Linux 系統）。因此在這個情境下，若能夠更快速地檢視電腦當前分配到的區網 IP 位址，就會顯得方便許多。
日前將二號機的作業系統從 Fedora 42 重新安裝至 Fedora 43 的一個插曲，是安裝完成並從備份復原各項配置時，發現新酷音輸入法的使用者詞庫位置及儲存格式均有變化。在使用者家目錄下，從「.chewing/chewing.sqlite3」變更為「.local/share/chewing/chewing.dat」，所以原本保留的資料備份不能直接覆蓋上去。
雖然這是 DR 習慣使用的注音輸入法，但說實在話，自己平常也沒有什麼在關注它背後的版本發展及變化。Fedora 43 當前安裝的套件版本分別為 ibus-chewing 2.1.7 及 libchewing 0.10.3，找尋了一下，發現有內建一支 chewing-cli 工具程式。不過與此同時，它好像也沒有很清楚的範例，來說明可以如何進行詞庫格式的轉換。於是就這樣試驗了一輪，最終發現流程算單純，就是可以從 *.sqlite3 輸出至 tsi.src、再將 tsi.src 轉換成 *.dat。所以具體的詞庫復原流程便如下所示：
最近因故覺得有必要釐清主機板 BIOS 內，Above 4G Decoding 及 Re-Size BAR Support 這兩項設定，對於 Linux 遊戲執行狀況的影響。特別是 NVIDIA 獨顯視訊記憶體（VRAM）的消耗、以及與之相關的錯誤情形。雖然最終是未能得出清楚的結論，可能要看日後是否有更合適的環境條件再做研究。但由於 BIOS 操作過程中有發覺到一些其它的事情，所以在此筆記下來。
即如標題所示，DR 最近開始體會到這會是個問題……因著各種不一的因素，有些時候可能會遇到主機設備上存在著非常陳舊的 SSH 服務。它所支援及啟用的加密演算法，在較新的 Linux 系統上，若嘗試以 OpenSSH 的 ssh 客戶端指令連線過去，會出現例如以下錯誤：「no matching host key type found. Their offer: ssh-rsa,ssh-dss」。而這些陳舊設備裡，有些是 Linux、也有些是某種封閉系統。其中後者即代表它的軟體環境是無法被更動的，連線障礙無論如何都只能從客戶端解決。
由於這項需求的發生頻率相當低，很難維持記憶力。所以曾寫了一份內部工作筆記，讓自己在一旦有需要的時候，可以看著筆記來操作。不過最近則意識到若改放置在自己的個人網站上，檢視起來是會更加方便。所以也請留意，以下其實是非常個人化的文字筆記（寫給自己看的）。它可能不是最佳實踐方法，也非圖文並茂、或者擁有鉅細靡遺的知識內容。倘若有進一步想要瞭解之處，則會建議找尋網路上的其它教程或說明。
製作流程如下：
本站部份的文章內容可能多少都曾提及過：Mozilla Firefox 是 DR 個人在 PC 上最主要使用的網頁瀏覽器，而且是自 2004 年的 1.0 版就開始在用了。Google Chrome 雖然也會用到，但就不是當成主要的瀏覽器來用。然而這並不因此表示，DR 對於 Firefox 歷代版本以來的所有變革都是照單全收。相反地，有一些改版變化，自己都還是傾向再手動回復成舊版的面貌。也幸好這些復原途徑始終存在，所以依然可以按照自己以往的習慣來操作瀏覽器。
於是本文接下來便是一份簡短的清單，算是呈現出 Firefox 有哪些變化項目，其實恐怕並不是很迎合自己的使用習慣，同時也一併說明相應的復原方式：