no resume device found と言われ Linux 環境が起動しない

この記事を作った動機

　最近、XPS 13 2in1 (intel 8th) を使っていて、バッテリーが完全に放電しきった状態で放置していることがあった。それで、通常であれば、CMOS 電池が設定内容を保持していて、UEFI の変数などのデータを保持しているはずだが、今回は違った。PC を充電器に繋ぎ、起動すると CMOS リセット時に見られる挙動である何度か再起動をするということになった。ようやく動いたかと思ったら、普段の設定とは異なって、Dual Boot 構成にしていた Windows がのそのそと起動し始めた。あまりのストレスに PC を投げ出したくなったが、結局色々調べて振り回されたことがあったので、記録したい。

経緯

PC が完全に2日程度放置していて、放電しきっていることに気づく。
Windows が起動しようとしてイライラする
Linux 環境を立ち上げようとして、UEFI の設定画面でエントリを作成し起動を試みるも、“no resume device found"と言われ起動しない
GURB の設定を編集しresume=と書かれているところを消すも、症状が改善せず。
起動するために USB を用意するもDD コマンドによる起動可能な USB 作成において説明される問題により、一度失敗する
ローカルLLM である Gemma4 に投げるも、通常のターミナル環境を起動できないから困っているにもかかわらず、ターミナルを使えだの的はずれなことばっか出力してきて爆発しそうになる。例えばresume=noneにしたら上手くいくと出力してくるが、機能しなかった。
DD コマンドによる起動可能な USB 作成により、最終的に正しく起動する USB メモリを作成し、ようやくライブ環境の端末が起動する
ドライブモードが RAID になっていることに気づき、AHCIに設定する
しかし奇妙なことに最初ライブ環境を起動したとき、肝心の Linux 環境が入っている NVME SSD が見えず、もう一度 CMOS がリセットされた状態にして、再トライすることになる
もう一回 AHCI に設定する
ようやくライブ環境から SSD が見えるようになり、initramfs から resume の hooks を吹き飛ばすことと、GRUB の resume 設定をなしにして起動設定を再生成させる
ようやく PC が正常に Linux 環境に起動するようになる。
今回の問題を起こした主犯であると思われる、CMOS 電池について調べる。

ポイント

“no resume device found” で Linux 環境が起動しない

　完全には確かめられていないが、どうも AHCI でもともと動かしていた物を、CMOS リセットが起こった時点で、RAIDになっていたために、それで起動しようとした結果起動できなかったということっぽい？しかし、USB のライブ環境に入れるようになってから、AHCI にドライブのモードを設定することは試したため、本当にそれが問題かは謎である。Linux 環境なら元からドライバは入っていそうなものだし、考えられることとしては、RAID モードであるときと、AHCI モードであるときで、パティーションの UUID が異なってしまうのかな？とは考えた。

　しかしながら、RAID モードでも結局 GRUB までは起動できていた訳だし、よく分かっていない。そもそも、resume 関連だったら、勝手に無視して起動しろよとも思うが、今回はそうならなかった。

DD コマンドによる起動可能な USB 作成

　dd コマンドにおいて、UEFI 環境で ISO ファイルから起動可能な Arch Linux のライブ USB を作成する際、注意点があることが分かった。単に、ddコマンドで焼き込んだだけでは、物理的には USB にはまだ焼き込まれていないらしく、UEFIの起動オプションに出てこず、起動できなかった。conv=fsyncを指定する(Gemma4の提案)ことで、最終的には起動可能な USB 環境を作成することができた。

　ダメだったときの例と機能する例の結果を比べると明らかであるが、ダメだったときは明らかに通常の USB と比べて速く終わりすぎていることが見て取れる。今回は USB 2.0 のメモリスティックを使っており、正常に動作する例からわかるように、実際にはもっと時間がかかるものである。

ダメだったときの例

sudo dd if=archlinux-2025.04.01-x86_64.iso of=/dev/sdb status=progress bs=4M

# 1178599424 bytes (1.2 GB, 1.1 GiB) copied, 13 s, 90.4 MB/s
# 294+1 records in
# 294+1 records out
# 1236303872 bytes (1.2 GB, 1.2 GiB) copied, 13.6627 s, 90.5 MB/s

機能する例

sudo dd if=archlinux-2025.04.01-x86_64.iso of=/dev/sdb status=progress bs=4M conv=fsync

# 1153433600 bytes (1.2 GB, 1.1 GiB) copied, 12 s, 96.0 MB/s 1236303872 bytes (1.2 GB, 1.2 GiB) copied, 12.8778 s, 96.0 MB/s
# 
# 294+1 records in
# 294+1 records out
# 1236303872 bytes (1.2 GB, 1.2 GiB) copied, 182.676 s, 6.8 MB/s

特殊な CMOS 電池

　どうせだいぶ古い PC だし、完全に CMOS 電池である使い捨てのボタン電池が切れたんだろうと思い、取り出して見てみたところ、通常の電池と異なることが分かった。通常のデスクトップPCなどで使われる電池は、CR2032 などである。しかし、今回のPCでは、ML1220 という再充電可能な二次電池が取り付けられていた。安易に充電不能な CR1220 交換することは、充電回路内蔵などの観点からできないことが分かった。

　ただ、普通 CMOS 電池が、2日放置したくらいで切れることは考えにくく、再充電可能であるならばなぜこんなにすぐ切れるのかという疑問があった。そこで現時点では、とにかくどうせ電池が8年くらい経過して劣化しきって駄目になったんだろうと思い、1000円以内でオークションなどで別の ML1220 が買えることから、交換しようと考えている。まだ電池が届いていないので試せてはいないが、今後事後経過として記録は追記しようと思う。

　これで駄目だったら単にノートPC 側の RTC 回路が壊れて電気を食いまくっているか、単にハズレの電池を掴まされたかという感じに思う。

追記 (2026/8/4)

　今日は電池が届いたので早速作業してみた。作業ではケーブルを古いバッテリーから取り外して使いまわしている。結果としては機能しているっぽく、30分くらいバッテリーを以下のように外した状態で放置しても、UEFI(BIOS)の設定が失われていないことを確認できた。長期的にはどうなるか現時点では不明である。