安直に “do-release-upgrade” したところWordpress を提供している Ubuntu が起動しなくなりました。
起動直後に“Initramfs unpacking failed”のメッセージが表示されOSが起動しません。
Grubも主性出来ず、当日朝のバックアップでも、最古の2週間前のバックアップでもリカバリできず、最終的に再構築した話です。
目次
システム構成
WordPress は Alibaba Cloud ECSの仮想マシンを利用したいわゆるLAMP構成です。 データベースはマネージドなRDSに外だししているのとフロントはAlibaba Cloud ESA でCDNやエッジセキュリティを提供しています。
今回の話は “ECS 仮想マシン(Ubuntu 22)”で起きた障害のリカバリの話となります。
どんな問題が発生したのか
“do-release-upgrade”を実行し、OSを再起動後、正常に起動しない問題が発生しました。
Alibaba Cloud が提供するコンソール機能（VNC）の画面スクショは以下。
[ 0.039522] RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!
[ 0.259679] Initramfs unpacking failed: invalid magic at start of compressed archive
[ 0.643686] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 0.644423] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-137-generic #154-Ubuntu
[ 0.645025] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014
[ 0.645632] Call Trace:
[ 0.645843] dump_stack+0x6d/0x8b
[ 0.646118] panic+0x101/0x2e3
[ 0.646364] mount_block_root+0x23f/0x2e8
[ 0.646688] mount_root+0x38/0x3a
[ 0.646958] prepare_namespace+0x13f/0x194
[ 0.647292] kernel_init_freeable+0x265/0x289
[ 0.647644] ? rest_init+0xb0/0xb0
[ 0.647921] kernel_init+0xe/0x110
[ 0.648198] ret_from_fork+0x35/0x40
[ 0.648532] Kernel Offset: 0x7000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffffffffff)
[ 0.649371] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---2行目の”Initramfs unpacking failed: invalid magic at start of compressed archive” が1次的なOSが起動原因となります。 どうしてこの状態に陥ったかの根本原因の調査結果は次のセクションで紹介します。
Initramfs unpacking failed が起きた原因
サービス復旧後に当日朝のスナップショットのディスクからログを読み込んでいく中で何が起きたのか見えてきました。
10月15日のパッケージ更新時に update-initramfs による initrd.img の生成・圧縮処理が不完全（不整合）な状態のまま完了し、その後の初回再起動（本日、10月18日）で読み込みに失敗しています。
update-initramfsが発生する原因はディスクの容量不足の場合もありますが今回は違います（十分な空き容量あり）。
カーネル更新についてログから時系列を整理すると
- 10月2日 新しいカーネル linux-image-5.15.0-198-generic のインストールと古いカーネルの削除を実行
- 10月15日 initramfs-tools のトリガー処理（trigproc）が走り、約 42 秒間（16:46:12 〜 16:46:54）かけて initrd の再生成が実行される
生成AIの仮説としては10月15日の再生成時に壊れてしまったとのこと。 initramfs-tools 処理中、または直後のパッケージ処理において、mkinitramfs が生成した圧縮アーカイブ（gzip/lz4 等）のヘッダーやフッターが正しく書き終わる前に処理が抜けた（あるいはメモリ上のフラッシュ不足・競合が発生した）可能性があると。
その結果、10月18日にリブートした際、ブートローダー（GRUB）から読み込まれた initrd.img の先頭マジックナンバー（ファイル識別子）をカーネルが認識できず、”Initramfs unpacking failed “が発生したと。
ただ、わたしの見立ては異なります。 10月15日に壊れていないと考えていて、その根拠としては一番古いバックアップとなる10月4日のスナップショットでも同じエラー”Initramfs unpacking failed”で起動できなかったためです。となると10月2日の新しいカーネルのインストールと古いカーネルの削除がこの状況をもたらした要因ではないかと考えています。 ただし、10月2日に何が起きたのかはログからは確認できず、不明というのが今回の結論とはなります。
上記の調査は以下の感じで障害発生前の一番新しいスナップショットからAlibaba Cloud の Cloud Disk を作成し、それを仮想マシンにアタッチしてUbuntuでmountとして調査しました。 （この作業自体はOSが復旧してから行っています）
障害発生前のスナップショットから生成したディスクのマウント
# mount /dev/sdb1 /mnt/old
ログの調査
# cat /mnt/old/var/log/dpkg.log | grep -E "initramfs|linux-image"
2026-10-02 21:21:23 install linux-image-5.15.0-198-generic:amd64 <none> 5.15.0-198.208
2026-10-02 21:21:23 status half-installed linux-image-5.15.0-198-generic:amd64 5.15.0-198.208
2026-10-02 21:21:23 status unpacked linux-image-5.15.0-198-generic:amd64 5.15.0-198.208
2026-10-02 21:21:28 upgrade linux-image-generic:amd64 5.15.0.194.171 5.15.0.198.171
2026-10-02 21:21:28 status half-configured linux-image-generic:amd64 5.15.0.194.171
2026-10-02 21:21:28 status unpacked linux-image-generic:amd64 5.15.0.194.171
2026-10-02 21:21:28 status half-installed linux-image-generic:amd64 5.15.0.194.171
2026-10-02 21:21:28 status unpacked linux-image-generic:amd64 5.15.0.198.171
2026-10-02 21:21:41 configure linux-image-5.15.0-198-generic:amd64 5.15.0-198.208 <none>
2026-10-02 21:21:41 status unpacked linux-image-5.15.0-198-generic:amd64 5.15.0-198.208
2026-10-02 21:21:41 status half-configured linux-image-5.15.0-198-generic:amd64 5.15.0-198.208
2026-10-02 21:21:42 status installed linux-image-5.15.0-198-generic:amd64 5.15.0-198.208
2026-10-02 21:21:42 status triggers-pending linux-image-5.15.0-198-generic:amd64 5.15.0-198.208
2026-10-02 21:21:45 configure linux-image-generic:amd64 5.15.0.198.171 <none>
2026-10-02 21:21:45 status unpacked linux-image-generic:amd64 5.15.0.198.171
2026-10-02 21:21:45 status half-configured linux-image-generic:amd64 5.15.0.198.171
2026-10-02 21:21:45 status installed linux-image-generic:amd64 5.15.0.198.171
2026-10-02 21:21:46 trigproc linux-image-5.15.0-198-generic:amd64 5.15.0-198.208 <none>
2026-10-02 21:21:46 status half-configured linux-image-5.15.0-198-generic:amd64 5.15.0-198.208
2026-10-02 21:22:02 status installed linux-image-5.15.0-198-generic:amd64 5.15.0-198.208
2026-10-02 21:27:18 status installed linux-image-5.15.0-190-generic:amd64 5.15.0-190.200
2026-10-02 21:27:22 status installed linux-image-5.15.0-191-generic:amd64 5.15.0-191.201
2026-10-02 21:27:22 remove linux-image-5.15.0-190-generic:amd64 5.15.0-190.200 <none>
2026-10-02 21:27:22 status half-configured linux-image-5.15.0-190-generic:amd64 5.15.0-190.200
2026-10-02 21:27:22 status half-installed linux-image-5.15.0-190-generic:amd64 5.15.0-190.200
2026-10-02 21:27:23 status config-files linux-image-5.15.0-190-generic:amd64 5.15.0-190.200
2026-10-02 21:27:23 remove linux-image-5.15.0-191-generic:amd64 5.15.0-191.201 <none>
2026-10-02 21:27:23 status half-configured linux-image-5.15.0-191-generic:amd64 5.15.0-191.201
2026-10-02 21:27:24 status half-installed linux-image-5.15.0-191-generic:amd64 5.15.0-191.201
2026-10-02 21:27:25 status config-files linux-image-5.15.0-191-generic:amd64 5.15.0-191.201
2026-10-15 16:46:01 status triggers-pending initramfs-tools:all 0.140ubuntu13.5
2026-10-15 16:46:12 trigproc initramfs-tools:all 0.140ubuntu13.5 <none>
2026-10-15 16:46:12 status half-configured initramfs-tools:all 0.140ubuntu13.5
2026-10-15 16:46:54 status installed initramfs-tools:all 0.140ubuntu13.5
復旧作業
復旧完了までには想定外に試行錯誤しました。 当初は当日朝（問題発生の数時間前）のスナップショットや2週間分の1日1回のスナップショットがあることからスナップショットからリストアすれば5分10分で復旧できると思っていました。 結果そんなことはなくOSのまっさらにしてのApache、PHPの再設定などを行うことになりました。
まず、最初に試みたのは OS 起動時の Grub メニューを出しての起動カーネルの選択です。 残っている過去のカーネルを選んで起動させるやり方です。 これが出来れば簡単だったのですができませんでした。
GrubのTimeOut時間が”1″秒の設定でかつパブリッククラウドの仮想マシンということで直接コンソールを操作できるのではなくAlibaba Cloud が提供する VNC ベースの画面転送を使うなかで、どうしても Grub の設定画面を表示させることができませんでした。
次に行ったのは当日朝のスナップショットからのリストアです。 “do-release-upgrade”を実行する数時間前のスナップショットなのでこれでリカバリできるだろうと思ったのですがNGでした。 2週間分1日1回のバックアップがあったのですが直前のものと一番古い2週間前のものでNGでした。
次に行ったのは問題が起きているディスクを別の仮想マシンにアタッチしての修正です。 結論から言うとできませんでした。 スナップショットからディスクを作成してマウントしてchrootして修正は出来たのですが、それをシステムディスクとして簡単かつすぐに適用する手段を見つけられず断念。 時間をかけて調べたり、サポートに問い合わせすればなんとかなったかもしれないし、本当に出来ないのかもしれませんがあきらめてしまいました。
上の3つの復旧手段の失敗で1時間が過ぎていました。 あまり止めたくないしバックアップからリカバリが失敗した時点で再構築するしかないと考えていたので早々に再構築での復旧に切り替えて作業を進めます。
再構築の流れは以下。 問題は設定シートやリカバリ手順は無いことだけです。
- OSをリプレース
- 直近のスナップショットから作成したディスクを仮想マシンにアタッチしマウント
- wordpress データのコピー
- Apache、PHP環境の再設定
- 動作確認
OSをリプレースというのは Alibaba Cloud ECS の標準機能で仮想マシンはそのままに OS だけいれかえる機能です。 この時、OSが正常動作する状態であればデータを残してのリプレースもできるのですが今回は起動しない状態なので、入れ替える＝初期化となります。 ただ、IPアドレスなどはそのまま引き継げますのでまったく新規に仮想マシンを払い出すよりは実施する作業の手番は少ない点はよいところです。
以下は実際の画面ですが”Replacement System Disk”が今回採用したまっさらになるやり方です。 右の”Migrate Operating System”はデータは保持する方法です。
Precautionsセクションに注意書きがありますが、データが消えることはもちろんスナップショットなどに関する仕様の説明がありますので実施する際には必ず確認しましょう（その時の最新の情報を）
次の画面に行くとAlibaba Cloudが提供する様々なOSからバージョンを選ぶことができます。 今回は”Ubuntu 26.04 64bit”にしました。 もともと使っていたのが “Ubuntu 22.04 64bit”でしたが再構築するので最新にしました。
上記の操作を行うと数分もしないうちに生まれ変わった Ubuntu 26.04 として起動します。 もちろん、ApacheやPHPなどの環境は整っていないですし、データもないのでこの時点ではサービスは復旧できません。
次は当日朝のスナップショットから Cloud Disk を作成し、その Cloud Disk を先ほど生まれ変わった Ubuntu 26.04 の仮想マシンにアタッチします。
以下は実際の画面ですが、スナップショットのリストから”Create Disk”を実行します。
アタッチ後はUbuntu上で lsblkコマンドでデバイス名を確認しマウントします。
$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
～省略～
vdb1 253:17 0 40G 0 part /mnt/old
$ sudo mkdir /mnt/old
$ sudo moount /dev/vdb1 /mnt/old
あとは Apacheの公開用のディレクトリに wordpress のデータを先ほどマウントしたところからコピーします。
そのあとはApacheの設定を見比べながら戻して、Module系を整えて、PHPを整えてとなります。 ここら辺は単純なWordpress構築の話なので今回は割愛。 MySQLはRDSというマネージドサービスに外だししているので復旧は不要です。
これでとりあえず、Wordpressが動作し、この Alibaba Cloudの備忘ログ（https://www.bigriver.jp/)も復旧しました。
先ほどまでの作業でとりあえずは WordPress は動き始め、一見した限りは特に問題はなさそうでしたが色々見ていくと軽微なものが多いですが作業漏れ、考慮漏れがありました。
- php.ini の移行漏れ（アップロードサイズとか使用メモリなどチューニング系）
- /etc/hosts
- crontab
- Apache の細かい設定 (X-Forwarderd-forのためのremoteipモジュールなど）
- PHPのモジュール入れ忘れ（ WordPress のダッシュボードから確認できた ImageMagickとかIntlとか）
こういうのは今後のためにやったことを再利用可能な手順化しておけばよいのですがいつもあとであとでとやらないのですよね・・。 まあ、こうやって多少なりとも記録に残しておくだけでも違いますが。 実際に過去のPHPトラブルや再構築の自分の記事を参考にしていたりもするので備忘ログとして役だったりもしています。
教訓・再発防止策
今回の教訓、再発防止も整理、まとめておきます。
- カーネル更新後は必ず検証する (
lsinitramfs /boot/initrd.img-$(uname -r) > /dev/null) - GRUBのタイムアウト値を長めにしておく（デフォの1秒から10秒へ）
- 再構築手順を整理しておく(毎回、Apacheの設定漏れやPHPのモジュール漏れが起きて、過去の自分の記事をバラバラと見ないように）
- ソーリーページを準備しておく （今回問題が起きてからESAでソーリーページを準備しようとしたが断念）
こんなことが起きるなら仮想マシンでのLAMPなんてやめてしまおうかと思いつつも、あえてOSやミドルウェアを運用していくことのメリットはまだまだあるので当面は続ける予定。 ただ、ソーリーページは Alibaba Cloud ESA のFunctionsを使う予定。これは Cloudflare の Workers 相当で簡単にWebサイトがつくれそうだったこともあり。
以上
