このメモの使い方
- 人が読むとき: 各項目は「症状 → 原因 → 対処 → 確認」の順に並んでいる。
- AIに渡すとき: このMarkdown全体を貼り、末尾の「AIへの依頼テンプレート」を使う。
- 項目の状態は3種類。解決済みは対処して症状が消えたもの。経過観察中は対処したが再発の有無がまだ確定していないもの。案は未適用・未検証の提案。
- 経過観察中・案の項目は、AIに断定させず、確認手順から提案させること。
- 「一般的な手順」と書いた対処は、実際に打ったコマンドの記録が残っていないもの。実機の記録と違えば追記して直す。
環境(2026-10-25 時点)
- 機器: HP ProLiant N54L(AMD Turion II Neo、AVXなし)
- OS: Fedora 44、カーネル 7.2.11-200.fc44.x86_64。F42は2026-05-13にEOLで、F42から直接F44へ2026-10-22に更新
- ディスク
- sda: システム(
/、/boot)
- sdb: WD30EZRX 約3TB(
/media/WD30EZRX)
- sdc: 約6TB(
/media/6TB)。どちらも使用率99%
- ネットワーク: 有線LAN + USB Wi-Fiドングル(RTL88x2BU、DKMSで導入した
morrownr/88x2bu-20210702)
- 主なサービス: httpd、php-fpm、mariadb、tomcat、guacd、websockify-novnc、Cloudflare Tunnel(cloudflared)
更新前後のチェックリスト
更新の前に確認すること。
- 重要データのバックアップ。劣化の兆候があるディスクは特に先に。
- 更新前のSMART値を控えておく(更新後と比較できる)。
/etc/fstab の外付け・増設ディスクに nofail を付ける(無いと起動時に緊急シェルへ落ちる。項目5参照)。- Wi-Fiドライバなど外部モジュールが外れても入れる手段(有線LAN、ローカルコンソール)を確保する。
更新後は、次をまとめて実行して状態を見る。
uname -r
sudo grubby --default-kernel
dkms status
lsmod | grep 88x2bu
nmcli device status
cat /sys/class/scsi_host/host*/link_power_management_policy
sudo idle3ctl -g /dev/sdb
sudo dmesg -T | grep -E "ata[0-9]|sd[a-c]" | grep -iE "error|reset|timeout|exception"
sudo smartctl -A /dev/sdb | grep -E "Pending|Uncorrectable|Reallocated|Load_Cycle"
sudo smartctl -A /dev/sdc | grep -E "Pending|Uncorrectable|Reallocated"
systemctl --failed
1. 更新後に古いカーネルで起動する✓ 解決済み
症状
新しいカーネルをインストールしたのに、再起動すると古いカーネルで起動する。
原因
/etc/default/grub が GRUB_DEFAULT=1 で、メニュー上の位置(2番目)で起動項目を固定していた。新カーネルが先頭に来ても、2番目の古い項目が選ばれ続ける。
対処
GRUB_DEFAULT=saved に変更する。これで「最後に選んだ/設定した項目」で起動する。下記は一般的な手順。
grep GRUB_DEFAULT /etc/default/grub
sudo sed -i 's/^GRUB_DEFAULT=.*/GRUB_DEFAULT=saved/' /etc/default/grub
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo grubby --set-default /boot/vmlinuz-<起動したいカーネルのバージョン>
UEFI機では grub.cfg の置き場所が環境で異なることがあるので、事前に確認する。N54L(BIOS起動)では /boot/grub2/grub.cfg。
確認
sudo grubby --default-kernel
sudo reboot
uname -r
再起動後も uname -r が新カーネルなら完了(2026-10-24、再起動後も 7.2.11 で起動することを確認済み)。
2. Wi-Fiドングルが使えない・繋がらない✓ 解決済み
症状
- カーネル更新後、ドライバが無くなりSSHで入れなくなる。
- ドライバは有効なはずなのに、有線LANをつないだ状態ではWi-Fiに繋がらなかった。有線を抜いたら繋がった。
原因
- DKMSモジュールは、新しいカーネル用にビルドされていないと使えない。カーネル更新のあとに作り直しが必要になる。
- 有線とWi-Fiを同時につないだ状態で繋がらなかった理由は、未特定。経路の優先順位(メトリック)やNetworkManagerの接続優先の影響が疑われるが、確認していない。
- F44に最初から入っているカーネル内蔵ドライバで足りた可能性もあるが、未検証。
- 起動ログに
88x2bu: module verification failed: signature and/or required key missing - tainting kernel が出る。署名のないモジュールを読み込んだ警告で、動作は可能。
対処
ドライバのディレクトリでインストールスクリプトを再実行する(最新カーネルで再コンパイルされる)。2025年の経緯は https://min117.hatenablog.com/entry/2025/08/11/054203 に記事がある。
cd <88x2buのディレクトリ>
sudo ./install-driver.sh
確認
dkms status
lsmod | grep 88x2bu
nmcli device status
ip route
nmcli -f NAME,DEVICE,STATE connection show --active
有線とWi-Fiの両方が有効なとき、ip route の default が2本出る場合は、メトリックの値で優先が決まる。
3. HDDのプチフリーズ◐ 経過観察中
症状
F44化のあと、SSHのコンソールやhttpd経由の動画再生が数十秒止まり、ディスクの読み出しが終わった瞬間に戻る。ケーブルを挿し直して再起動しても改善しなかった。
原因(ここまでに分かったこと)
- sdc(ata3)で約1分おきにSATAリンクエラーが出ていた。
SError: { CommWake 10B8B }、READ FPDMA QUEUED のタイムアウト(30秒)、hard resetting link、最後に NCQ disabled due to excessive errors。Sense Keyは Aborted Command で、媒体エラー(Medium Error)ではなくリンク側の問題を示す。
- SATAリンク電源管理(LPM)の既定が
min_power_with_partial だった。省電力状態からの復帰に失敗している疑いがある。
- sdb(WD30EZRX)のidle3タイマーは80(8秒)で、ヘッドを頻繁に退避する状態だった。Load_Cycle_Countは約638万。
- 利用者の見立ては「idle3の無効化で解決」。ログ上はsdcのリンクエラーが主で、LPMとidle3を同時に対処したため、どちらが効いたかは未確定。
別件として、SMARTには媒体劣化の兆候もある(フリーズの原因とは別に対処が必要)。
- sdb: Current_Pending_Sector 94、Offline_Uncorrectable 70。読めない領域があり、劣化が進んでいる。
- sdc: Reallocated_Sector_Ct 1603(正規化値159、しきい値140)。
対処
切り分けの順番は、カーネルログ → SMART → 遅いディスクの特定。
sudo dmesg -T | grep -iE "ata[0-9]|sd[a-c]|error|timeout|reset|link" | tail -50
sudo smartctl -H -A /dev/sdb | grep -E "overall|Reallocated|Pending|Uncorrectable|UDMA_CRC|Load_Cycle|Power_On"
sudo iostat -x 1 | grep -E "Device|sda|sdb|sdc"
LPMを max_performance に固定する。sysfsへの書き込みは再起動で戻るので、udevルールで永続化した。
sudo tee /etc/udev/rules.d/60-sata-lpm.rules <<'EOF'
ACTION=="add", SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="max_performance"
EOF
sudo udevadm control --reload
idle3(WD Green系の8秒ヘッド退避)を無効化する。反映には、再起動ではなく電源の完全な入れ直し(電源ケーブルを抜いて30秒)が必要。
sudo dnf install -y idle3-tools
sudo idle3ctl -g /dev/sdb
sudo idle3ctl -d /dev/sdb
6TB(sdc)は idle3ctl が sg16(VSC_SENDKEY) failed: Invalid exchange で失敗した。このドライブは非対応なので、Linuxからは変更できない。
確認
udevルールが効くかは、一度値を戻して udevadm settle で処理完了を待ってから見る(待たずに見ると未適用に見える)。
for h in /sys/class/scsi_host/host*/link_power_management_policy; do echo min_power_with_partial | sudo tee $h >/dev/null; done
sudo udevadm trigger --subsystem-match=scsi_host --action=add
sudo udevadm settle
cat /sys/class/scsi_host/host*/link_power_management_policy
電源の入れ直し後は、4行とも max_performance、idle3が disabled、ataのエラーなしを確認する。エラー監視は次のコマンドで行う。
sudo journalctl -kf | grep -iE "ata[0-9]|exception|hard resetting|I/O error"
残課題
- 半日から1日、エラーが再発しないかを見て、原因がLPMかidle3かを確定させる。
- エラーが残る場合は、sdcのSATAケーブル交換、別ポートへの差し替え、電源コネクタの変更を試す。
- sdbのPending/Uncorrectableは自然に消えない。バックアップを先に進める。バックアップが済むまで、書き込みを伴う検査(
fsck、badblocks -w、pendingを潰す操作)は避ける。
4. VNCをXfce + TigerVNC + noVNCに作り直す✓ 解決済み
症状
F44のローカルGNOMEがディスプレイ X0/X1 を使うため、従来のVNC構成と噛み合わない。Wayland/GNOMEセッションのままでは、確実に動くVNCにならなかった。
対処
VNC専用のXfceセッションを別ディスプレイ(:2)で動かす構成にした。
vncserver@:2.service が 5902 で待ち受ける。デスクトップはXfce、設定は ~/.config/tigervnc/config。websockify-novnc は 6080 から localhost:5902 へ中継するよう変更。- 黒画面になる対策として、
~/.local/bin/vnc-fix-xfce.sh を自動起動に入れ、xfwm4 と xfdesktop を起動する。
- noVNC経由でつなぐコマンド
myVNC3do を別途作成した(中身はこのメモに含めていない)。
確認
systemctl status 'vncserver@:2.service' --no-pager
systemctl status websockify-novnc --no-pager
ss -ltnp | grep -E "5902|6080"
再起動後も、VNC/noVNCが自動で起動することを確認済み(2026-10-24)。
5. PHP更新・ミドルウェア・fstab✓ 解決済み
経緯
F42は2026-05-13にEOLで、PHPの脆弱性修正が入らなくなっていた。F42から直接F44へ上げて(2026-10-22)、最新のPHPに更新した。古い機器でも、最新Fedoraで解決できた。
更新で壊れたもの
- Tomcatが10.1になり、Guacamole(1.5.5.war)はJakarta変換が必要になった。
- fstabに書いていた外付けHDD(
/media/2TB)が見つからず、起動が緊急シェルに落ちた。nofail を付けて解決した。
# /etc/fstab の例(UUIDとファイルシステムは環境に合わせる)
UUID=<UUID> /media/2TB <FSTYPE> defaults,nofail 0 0
php-fpmが一度、起動タイムアウトで落ちた [案]
起動の45秒後に強制終了された(Result: timeout)。起動直後のディスクI/Oの詰まりが疑われるが、確定していない。手動で systemctl start したら正常に起動した。再発に備えて、再試行とタイムアウト延長を入れる案がある。適用したかは要確認。
sudo mkdir -p /etc/systemd/system/php-fpm.service.d
sudo tee /etc/systemd/system/php-fpm.service.d/10-retry.conf <<'EOF'
[Service]
TimeoutStartSec=180
Restart=on-failure
RestartSec=10
EOF
sudo systemctl daemon-reload
6. 認証ダイアログ(pkexec)が出たときの確認手順▷ 参考
Dropboxの起動直後に、pkexec /bin/sh /tmp/tmpXXXXXXXX を実行してよいか聞く認証ダイアログが出た。パスワードを入れる前に、中身と呼び出し元を確認する。
cat /tmp/tmpXXXXXXXX
ps -eo pid,ppid,user,lstart,cmd | grep -E "pkexec|dropbox" | grep -v grep
pstree -asp $(pgrep -o pkexec)
今回は、親プロセスがユーザー自身のDropboxデーモンで、中身は同期フォルダの chown -h -R と chmod -R u+rwX のみだったので許可してよい内容だった。誤って拒否しても、dropbox stop; dropbox start で再要求されるほか、同じコマンドを手動で sudo 実行しても同じ結果になる。
許可しない目安は、親がデーモンではない、中身が読めない・難読化されている、curl/wget で取得して実行する、広範囲の rm -rf、ユーザーやsudoers・sshの設定変更を含む場合。
AIへの依頼テンプレート
次回の更新作業のとき、このMarkdown全体の後ろに付けて渡す。
上のメモは、前回の Fedora 42→44 更新で起きた問題と対処の記録です。
今回は Fedora <旧バージョン>→<新バージョン> の更新(または カーネル更新)を行います。
- メモの「更新前後のチェックリスト」に沿って、先に確認すべきことを教えてください。
- 「経過観察中」「案」の項目は断定せず、確認コマンドから提案してください。
- コマンドは、コピーしやすいようにコードブロックで示してください。
- 状況: <ここに今回の現象やログを貼る>
