Docker SIGILL: illegal instruction 問題除錯記錄

Docker SIGILL: illegal instruction 問題除錯記錄

最近在一台平常執行得好好的伺服器上,遇到一個讓人頭痛的 Docker 問題。
原本 Portainer 和其他容器都可以正常運行,但在系統突然當機後,所有容器在啟動時都出現以下錯誤訊息:

docker: Error response from daemon: failed to create task for container: failed to start shim: start failed: SIGILL: illegal instruction

以下記錄排除問題的經過,給有類似狀況的朋友參考。

OS: Debian GNU/Linux 12 (bookworm) Server: Raspberry Pi 4 Docker: 28.3.0, build 38b7060

前情提要: - Docker 與容器本來可以正常運作 - 其中一個 Container 服務發生當機後,所有 Container 都停止服務 - 所有 Container 都無法啟動,一啟動沒幾秒就會出現docker: Error response from daemon: failed to create task for container: failed to start shim: start failed: SIGILL: illegal instruction

Google 錯誤訊息後,大多數文章都是把問題指向映像檔和 CPU 架構不相容,但在我的環境中應該不太可能。因為同樣的映像檔在當機前是可以執行的。

以下是排查與解決過程: 第一步:重啟治百病 在 Log 皆沒有進一步資訊的情況下,遵循重啟治百病,先重啟 Docker

sudo systemctl restart docker

再試著啟動容器

docker start portainer

結果依然出現一樣的錯誤訊息

第二步:檢查 containerd-shim 接下來懷疑containerd-shim 二進位是否損壞。先確認檔案存在:

which containerd-shim

確認檔案是存在的後,再確認檔案是否正常

file $(which containerd-shim)

file 檢查結果顯示為正常的 ELF 執行檔。

第三步:查看系統日誌 使用 journalctl 以及 dmesg 查看重啟後有沒有關鍵錯誤:

journalctl -xe
dmesg | tail -n 50

除了原本的錯誤訊息外,並沒有其他比較顯眼的錯誤訊息

第四步:系統重啟

sudo reboot

整個系統重新開機後,再重覆第一至第三步,確否是否有恢復正常。可惜很不幸,問題依舊,並沒有好轉。只好繼續。

第五步:刪除容器重建 依前面的結果看起來,懷疑可能是容器的檔案發生問題,試著刪除現存的容器再重建看看

docker rm portainer

重啟

docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:lts

結果發現還是同樣錯誤

第六步:清空 Docker 資料的目錄 接下來猜測有可能是 /var/lib/docker 儲存層損壞,進行備份再清理。

停止 Docker

sudo systemctl stop docker

將現行資料備份到 /root/ 目錄中

sudo tar czvf /root/docker-backup.tgz /var/lib/docker

清空資料

sudo rm -rf /var/lib/docker

再重新啟動 Docker

sudo systemctl start docker

此時 Docker 狀態應該是整個恢復乾淨了

第七步:重新拉映像檔來執行 重新拉取 Portainer 映像:

docker pull portainer/portainer-ce:lts

啟動容器

docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:lts

結果大失所望,居然還是有問題。還有最後一個方向,整個把 Docker 移除後再裝一次

第八步:移除 Docker 重新安裝 停止 Docker

sudo systemctl stop docker

移除 Docker 並重新安裝

sudo apt-get remove --purge docker-ce docker-ce-cli containerd.io
sudo apt-get install docker-ce

然後再重新啟動容器

終於看到正常執行的結果了,此次除錯繞了一大圈,要是一開始直接移除 Docker 重新安裝再重新開機,應該就不用這麼麻煩了,特此記錄,希望對遇到同樣情況的棒油有幫助,少走彎路。

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

應該可以解決簽章的問題

在 Chrome 中遇到自然人憑證跨平台元件未啟動或尚未安裝元件的問題


在使用Google Chrome瀏覽器操作自然人憑證認證頁面時,確定已安裝跨平台元件,但卻一直出現”未啟動或尚未安裝元件”訊息的情況,但使用無痕視窗開啟的話又可以使用,可以試試以下操作,步驟如下:

1. 複製 chrome://net-internals/#hsts 貼在網址列進入網站 

2. 在該網頁項目 Delete domain security policies 的欄位登打localhost 再按DEL 

3. 重新開啟Google Chrome瀏覽器後,請點選測試網頁 http://localhost:61161/selfTest.htm 進行測試 

4. 若檢測結果第1項至第9項全數通過,則表示您的自然人憑證可以正常讀取也能在網頁進行自然人憑證官網的各項操作。

參考資訊: 

跨平台元件使用障礙排除說明(錯誤訊息“未安裝未啟動”或“2201”)

pi-hole & ADGuard 解封 Line News 的影片

 pi-hole 和 ADGuard 是家庭用擋廣告的利器,不僅免費而且只要一台小小的樹莓就可以運作,目前僅用一台 Pi 一代即可運作順暢,設定完成後。全家連上 wifi 後手機不用再另外設定,即可有擋廣告的效果。至於喜好用哪一個就見人見智了,之前我是用 pi-hole ,在前陣子記憶卡莫名資料消失後就改試看看 ADGuard ,只能說各有優缺點。

只是家中長輩會習慣看 Line news 裡的影片,結果因為廣告被擋掉的關係,導致 Line News 的影片不能播放。在這裡有兩個 URI 必須要放在白名單中,Line news 的影片才能順利播放。若使用的是 Pi-hole 可在白名單中加入以下資訊

(\.|^)securepubads\.g\.doubleclick\.net$   (google ads data)
(\.|^)imasdk\.googleapis\.com$ (google ads query )

若使用的是 ADGuard 的話,可以白名單中加入以下資訊

@@||securepubads.g.doubleclick.net^$important
@@||imasdk.googleapis.com^$important

一會兒即可測試 Line News 裡的影片應該就可以播放了,但代價就是來自這兩個網址的廣告解封了。

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

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

Docker SIGILL: illegal instruction 問題除錯記錄

Docker SIGILL: illegal instruction 問題除錯記錄 最近在一台平常執行得好好的伺服器上,遇到一個讓人頭痛的 Docker 問題。 原本 Portainer 和其他容器都可以正常運行,但在系統突然當機後,所有容器在啟動時都出現以下錯誤訊息: d...