麥克星球 Linux Fedora 心得筆記: fedora

顯示具有 fedora 標籤的文章。顯示所有文章

dnf upgrade fails with Error: GPG check FAILED

OS: Fedora 36

今天在做 dnf 更新的時候，突然有很多 package 都出現簽章問題無法更新。類似如下的錯誤訊息

....   is  not signed.
......   is  not signed.
.........   is  not signed.
Error: GPG check FAILE

可以試試先將 package 都清掉, 再 refresh 一次看看.

dnf clean all
dnf upgrade --refresh

應該可以解決簽章的問題

dnf 更新時 openh264 repo 發生錯誤

平常更新的訊息都沒特別注意，今天仔細去看 dnf 更新的訊息才發現有以下的錯誤訊息。

Fedora 34 openh264 (From Cisco) - x86_64                                                                                                 85  B/s | 271  B     00:03     
Errors during downloading metadata for repository 'fedora-cisco-openh264': 
  - Status code: 404 for https://codecs.fedoraproject.org/openh264/34/x86_64/os/repodata/repodata/repomd.xml (IP: 38.145.60.21)                                         
Error: 無法下載「fedora-cisco-openh264」軟體庫的中介資料：Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried   
忽略軟體庫：fedora-cisco-openh264

Fedora 34 openh264 (From Cisco) 主要是提供 OpenH264 codec 的 repostory (可參考 Fedora Project wiki - OpenH264)，不知何時開始出現如上的錯誤。今天才注意到，通常這類的錯誤訊是由連不到提供服務的網站或是服務網站的目錄結構異動造成無法取得中介資料而造成。

手動連到訊息中的網址 https://codecs.fedoraproject.org/openh264/34/x86_64/os/repodata/repodata/repomd.xml 發現真的沒有檔案，所以試連看看網站還在不在。由 https://codecs.fedoraproject.org/openh264/ 可以看到網站還是有正常運作的，但在檢視現行網站上的目錄結構時發現似乎多了一層 os 。於是先手動更新 /etc/yum.repos.d/fedora-cisco-openh264.repo ，將其中的 baseurl 的路徑多加了一層 os 由原本的

[fedora-cisco-openh264]
name=Fedora $releasever openh264 (From Cisco) - $basearch
baseurl=https://codecs.fedoraproject.org/openh264/$releasever/$basearch/
.....

改為

[fedora-cisco-openh264]
name=Fedora $releasever openh264 (From Cisco) - $basearch
baseurl=https://codecs.fedoraproject.org/openh264/$releasever/$basearch/os/
....

baseurl=https://codecs.fedoraproject.org/openh264/$releasever/$basearch/os/

修改完成後存檔，再做一次 dnf update ，錯誤訊息就不見了。只是不知道什麼時候會不會架構又發生異動。

dkms status 出現錯誤訊息 …/source/dkms.conf does not exist

dkms全名為(Dynamic Kernel Module Support)，其介紹可參考wiki 動態核心模支援

在執行 dkms status 確認系統內有安裝了哪些模組時若出現 .../source/dkms.conf does not exist. 的錯誤訊息。例如

$ dkms status
    nvidia/470.103.01, 5.16.5-100.fc34.x86_64, x86_64: installedError! Could not locate dkms.conf file.
    File: /var/lib/dkms/nvidia/470.74/source/dkms.conf does not exist.

    nvidia/470.103.01, 5.16.7-100.fc34.x86_64, x86_64: installed

這種情況常見 nvidia 安裝多個官方版本的驅動程式後，舊版本的驅動程式檔案不見了。

主要該 module 缺少了 dkms.conf 導致發生錯誤，也可以利用以下指令檢查 /var/lib/dkms/ 目錄下的缺少 source 目錄的 module 有哪些？[1]

for i in /var/lib/dkms/*/[^k]*/source; do [ -e "$i" ] || echo "$i";done

解決方法 - 確認 /var/lib/dkms/nvidia/470.74/ 目錄下沒有 source 的目錄後，將其刪除 - 刪除後在 /var/lib/dkms/nvidia/ 目錄下有其他 kernel 開頭的連結目錄出現指向 /var/lib/dkms/nvidia/470.74/ 而失效的情況，也將其一併刪除即可。 - 最後再執行一次 dkms status 確認是否恢復正常

參考資料 [1] https://bbs.archlinux.org/viewtopic.php?pid=1189293#p1189293

更新套件時新舊版本的檔案發生衝突

在系統更新的時候，有時發現很奇怪的檔案衝突，例如同一個套件新舊版本的檔案發生衝突。原本該是被更新的檔案，卻被系統告知要安裝新版本中的檔案被舊版本套件中的檔案互相衝突。

以這次遇到的 glib-networking 為例：

錯誤：處理事項測試錯誤：                                                       
  從 glib-networking-2.68.3-1.fc34.i686 安裝的檔案 /usr/share/doc/glib-networking/NEWS 與來自軟體包 glib-networking-2.68.2-1.fc34.x86_64 的檔案產生衝突
  從 glib-networking-2.68.3-1.fc34.i686 安裝的檔案 /usr/share/locale/hr/LC_MESSAGES/glib-networking.mo 與來自軟體包 glib-networking-2.68.2-1.fc34.x86_64 的檔
案產生衝突

在更新的過程中，系統告知版本 2.68.3-1 的 /usr/share/doc/glib-networking/NEWS 和 /usr/share/locale/hr/LC_MESSAGES/glib-networking.mo 兩個檔案與版本 2.68.2-1 的檔案發生衝突。照理說這些檔案應該是直接要被更新的才對，而不是出現這樣的錯誤訊息。

這時候可以先利用 rpm 指令檢查一下系統中是不是安裝了多個版本 glib-networking

$ rpm -qa | grep -i glib-networking
glib-networking-2.68.2-1.fc34.x86_64
glib-networking-2.68.2-1.fc34.i686
glib-networking-2.68.3-1.fc34.x86_64

可以看到不知道為什麼 2.68.3-1 已經安裝進來了，但 2.68.2-1 卻同時有 i686 和 x86_64 的兩組套件，可以直接把舊版本的 2.68.2-1 兩組套件移除後，再重新更新一次試看看。

$ sudo dnf remove glib-networking-2.68.2-1.fc34.i686
$ sudo dnf remove glib-networking-2.68.2-1.fc34.x86_64

如果並沒有安裝多個版本的問題，可以試試將其移除後再進行系統更新，最後再安裝回來，應該就可以解決這個問題。

Fedora 33 升級到 34 遇到問題

Fedora 33 升級到 34 的詳細步驟可參考以下文章 https://www.putorius.net/upgrade-to-fedora-34.html

升級流程所用到的指令如下

# 切換到 root
sudo -s

# 先將現行系統更新到最新
dnf --refresh upgrade

# 安裝 dnf 系統升級套件
dnf install dnf-plugin-system-upgrade --best

# 下載升級到 fedora 34 所需要的套件檔案
dnf system-upgrade download --refresh --releasever=34

# 重開機準備開始升級
dnf system-upgrade reboot

在準備升級的過程中遇到以下的錯誤訊息

錯誤：
 問題: rdma-core-35.0-1.fc33.i686 has inferior architecture
  - rdma-core-35.0-1.fc33.x86_64 不屬於 distupgrade 軟體庫
  - 安裝的軟體包有問題 rdma-core-35.0-1.fc33.i686
(請試試加上「--skip-broken」以跳過無法安裝的軟體包)

先依照訊息健議使用 --skip-broken 來處理

$ dnf system-upgrade download --refresh --releasever=34 --skip-broken
錯誤：
 問題: rdma-core-35.0-1.fc33.i686 has inferior architecture
  - rdma-core-35.0-1.fc33.x86_64 不屬於 distupgrade 軟體庫
  - 安裝的軟體包有問題 rdma-core-35.0-1.fc33.i686

依之前的慣例來看，可以透過先將有問題的套件移除，等升級完成後再另外裝回來，可以解決大部份的問題。所以試著用 dnf 將其移除：

$ dnf remove rdma-core --skip-broken
錯誤：
 問題: rdma-core-35.0-1.fc33.i686 has inferior architecture
  - rdma-core-35.0-1.fc33.x86_64 不屬於 distupgrade 軟體庫
  - 安裝的軟體包有問題 rdma-core-35.0-1.fc33.i686

似乎並不能解決問題，無法使用 dnf 將其移除，google 了類似的錯誤訊息後，在 https://bugzilla.redhat.com/show_bug.cgi?id=1956631 發現類似的問題，論壇提到解決方法是先將 rdma-core 透過 rpm 的方式移除後再進行升級

＃ 搜尋後發現系統裡居然有兩個 rdma-core 的套件，於是先使用 rpm 將兩個都進行移除
$ rpm -e --nodeps rdma-core-35.0-1.fc33.x86_64
$ rpm -e --nodeps rdma-core-35.0-1.fc33.i686
# 重新開始下載系統升級套件
$ dnf system-upgrade download --refresh --releasever=34

接下來就一路順利升級到 fedora 34 了。

掛載 Synology 分享的 NFS 後無法使用 Gnome nautilus 無法寫入檔案

最近遇到一個奇怪的問題，我在 Fedora 的環境下 Mount Synology 分享出來的 NFS 空間時，發現 Gnome nautilus 檔案總管無法寫入或變更檔案就像沒有寫入權限一般。但若是使用 Shell 指令操作時，卻又一切正常。百思不得其解，在 google 了許多論壇後，似乎有類似問題的人不多。但有在 gnome nautils 的論壇中看到一篇兩年前的舊文提到了類似的問題，透過 gio info 掛載目錄 的指令查詢了我掛載起來的目錄，發現其中的 access::can-write:屬性居然是 FALSE，但明明權限已經都正確設定了 read/write 了。這篇討論的後段有網友提到可以透過把權限 set to Windows ACL 的方式來解決，但我在爬文中看到 Synology 的官方 Knowledge Center 中的如何將檔案或資料夾的權限從 UNIX 權限還原為 Windows ACL 權限？提到這麼一段話。

在 DSM 中，檔案 / 資料夾的預設權限為 Windows ACL 權限。若在檔案或資料夾上執行 chmod 指令 (例如：chmod 644 FILE)，權限會變更為 UNIX 權限，此操作可能會導致日後無法預期的行為。本文將說明如何還原權限變更。

其中提出的解決方法是

您可以依照下列步驟以將 UNIX 權限還原為 Windows ACL 權限：
1. 開啟 File Station，找到您執行 chmod 指令的檔案 / 資料夾其上層資料夾。
2. 以右鍵按一下該上層資料夾，選擇內容。
3. 前往權限頁籤，勾選套用到這個資料夾、子資料夾及檔案並按一下確定。
4. Windows ACL 權限將會重新套用至檔案或資料夾。

照著官方提供的解決方法來操作後，掛載起來的 NFS 便可以用 Gnome nautilus 正常操作寫入檔案了。至於是什麼時候權限錯了，實在記不起來了，因為真的好久沒用 NFS 掛載空間了。

把解決方法記錄下來，希望能幫到遇上相同問題的朋友。