Ubuntu 20.04.4 LTSでのKernel panic「kernel BUG at include/linux/fs.h:3104!」の暫定回避方法

Diary
Ubuntu 20.04.4 LTSでのKernel panic「kernel BUG at include/linux/fs.h:3104!」の暫定回避方法
Page content

OCIインスタンスでKernelエラー

「Always Free」ということでありがたく愛用している次のOCI (Oracle Cloud Infrastructure) インスタンスのKernelを、本日 (2022-06-08) 現在最新の 5.13.0-1033-oracle へ更新した後、システムが安定せず、Linux起動後にKernel panicが発生するようになってしまった。

項目内容
インスタンスOCI (Oracle Cloud Infrastructure) VM.Standard.E2.1.Micro
OSUbuntu 20.04.4 LTS (Focal Fossa)
問題が発生したKernellinux-image-5.13.0-1033-oracle 5.13.0-1033.39~20.04.1 amd64
問題が発生しないKernellinux-image-5.13.0-1030-oracle 5.13.0-1030.35~20.04.1 amd64 (一つ前の版)

具体的な病状

  • Linuxの起動直後は、コンソール画面 (OCI管理画面にある仮想コンソール) からの直接ログインやSSHでのネットワークログインは可能
  • しかしコンソール画面を見ていると、Linuxの起動完了後から数秒のうちに、次のログを吐いて操作不能になる。ネットワーク経由でも応答しなくなる
[   47.372548] kernel BUG at include/linux/fs.h:3104!
[   47.376841] invalid opcode: 0000 [#1] SMP NOPTI
[   47.377884] CPU: 0 PID: 1860 Comm: miniflux Not tainted 5.13.0-1033-oracle #39~20.04.1-Ubuntu
[   47.380564] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
[   47.382589] RIP: 0010:__fput+0x247/0x250
[   47.383469] Code: 00 48 85 ff 0f 84 8b fe ff ff f6 c7 40 0f 85 82 fe ff ff e8 ab 38 00 00 e9 78 fe ff ff 4c 89 f7 e8 2e 88 02 00 e9 b5 fe ff ff <0f> 0b 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 31 db 48
[   47.393212] RSP: 0018:ffffa3bf82353bd0 EFLAGS: 00010246
[   47.394525] RAX: 0000000000000000 RBX: 00000000000a801d RCX: ffff95323d1b4800
[   47.396417] RDX: ffff9532390f7780 RSI: 0000000000000001 RDI: 0000000000000000
[   47.473552] RBP: ffffa3bf82353bf8 R08: 0000000000000001 R09: ffff95323822cac0
[   47.475477] R10: ffffa3bf82353bd0 R11: ffff95323914d110 R12: ffff95323914d100
[   47.477260] R13: ffff95323822cac0 R14: ffff9532390f77a0 R15: ffff95320472cf00
[   47.479419] FS:  00007fec6cb99b20(0000) GS:ffff95323f800000(0000) knlGS:0000000000000000
[   47.485791] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   47.487972] CR2: 000000c000d8ffb0 CR3: 000000000327c000 CR4: 00000000003506f0
[   47.495594] Call Trace:
[   47.496175]  <TASK>
[   47.496695]  ____fput+0xe/0x10
[   47.497410]  task_work_run+0x70/0xb0
[   47.498604]  do_exit+0x37b/0xaf0
[   47.499425]  do_group_exit+0x43/0xb0
[   47.500326]  get_signal+0x157/0x8c0
[   47.501180]  arch_do_signal_or_restart+0xf2/0x290
[   47.573573]  exit_to_user_mode_prepare+0x12f/0x1c0
[   47.574868]  syscall_exit_to_user_mode+0x27/0x50
[   47.575906]  do_syscall_64+0x6e/0xb0
[   47.576732]  ? exit_to_user_mode_prepare+0x3d/0x1c0
[   47.577803]  ? syscall_exit_to_user_mode+0x27/0x50
[   47.579237]  ? do_syscall_64+0x6e/0xb0
[   47.580179]  ? exit_to_user_mode_prepare+0x9b/0x1c0
[   47.581358]  ? irqentry_exit_to_user_mode+0x9/0x20
[   47.583420]  ? irqentry_exit+0x19/0x30
[   47.585168]  ? common_interrupt+0x55/0xa0
[   47.586882]  ? asm_common_interrupt+0x8/0x40
[   47.588067]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   47.589582] RIP: 0033:0x46f023
[   47.590462] Code: Unable to access opcode bytes at RIP 0x46eff9.
[   47.591938] RSP: 002b:00007fec6cb998a0 EFLAGS: 00000286 ORIG_RAX: 00000000000000ca
[   47.593888] RAX: fffffffffffffe00 RBX: 000000c00003e800 RCX: 000000000046f023
[   47.595824] RDX: 0000000000000000 RSI: 0000000000000080 RDI: 000000c00003e948
[   47.597700] RBP: 00007fec6cb998e8 R08: 0000000000000000 R09: 0000000000000000
[   47.673857] R10: 0000000000000000 R11: 0000000000000286 R12: 00000000000000f7
[   47.675586] R13: 0000000000000000 R14: 0000000000d00024 R15: 0000000000000000
[   47.677321]  </TASK>
[   47.678535] Modules linked in: xt_mark ip6table_nat ip6table_filter ip6_tables veth xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bpfilter br_netfilter bridge stp llc aufs overlay nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua joydev efi_pstore input_leds serio_raw sch_fq_codel ipmi_devintf ipmi_msghandler msr sunrpc ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi iscsi_ibft iscsi_boot_sysfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic bochs_drm drm_vram_helper drm_kms_helper syscopyarea sysfillrect usbhid crct10dif_pclmul sysimgblt crc32_pclmul fb_sys_fops ghash_clmulni_intel cec aesni_intel rc_core drm_ttm_helper crypto_simd hid cryptd ttm virtio_net net_failover failover
[   47.678599]  psmouse drm virtio_scsi floppy
[   47.785254] ---[ end trace 0e747571a933ea24 ]---
(snip)
[   51.097840] RIP: 0010:__fput+0x247/0x250
[   51.173822] Code: 00 48 85 ff 0f 84 8b fe ff ff f6 c7 40 0f 85 82 fe ff ff e8 ab 38 00 00 e9 78 fe ff ff 4c 89 f7 e8 2e 88 02 00 e9 b5 fe ff ff <0f> 0b 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 31 db 48
[   51.181323] RSP: 0018:ffffa3bf82353bd0 EFLAGS: 00010246
[   51.184481] RAX: 0000000000000000 RBX: 00000000000a801d RCX: ffff95323d1b4800
[   51.187779] RDX: ffff9532390f7780 RSI: 0000000000000001 RDI: 0000000000000000
[   51.191379] RBP: ffffa3bf82353bf8 R08: 0000000000000001 R09: ffff95323822cac0
[   51.194511] R10: ffffa3bf82353bd0 R11: ffff95323914d110 R12: ffff95323914d100
[   51.197397] R13: ffff95323822cac0 R14: ffff9532390f77a0 R15: ffff95320472cf00
[   51.272947] FS:  0000000000000000(0000) GS:ffff95323f900000(0000) knlGS:0000000000000000
[   51.276348] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   51.278612] CR2: 0000557b01ae52e0 CR3: 0000000004852000 CR4: 00000000003506e0
[   51.281192] Kernel panic - not syncing: Fatal exception in interrupt
[   51.285262] Kernel Offset: 0x16400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[   51.299923] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

今回の環境での制限事項

Kernel更新に関わる問題が発生したときの一般的な対処法としては、GRUBを操作して更新前のKernelを選択して起動しなおせば良いわけだが、今回の環境では勝手が違っていて次の通り。

  • コンソール画面にGRUBが現れない (効くのかわからないが起動中にコンソール画面に対してShiftキーを押していてもだめ)
  • コンソール画面にLinux起動途中の進捗画面とログインプロンプトは出る → 数秒で操作不能

【事後談】GRUBの設定/etc/default/grubを確認してみると、そもそもシリアルコンソールを使う設定になっていなかった。

$ cat grub.original | grep -v '^#' | grep -v '^\s*$'
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Kernelエラーの暫定回避方法

Linuxの起動後の数秒間は生きているので、この短い時間内で問題解決をしなければならない。GRUBの設定を変更して一つ前のKernelで起動させることを目標に、次のような操作を行った。操作途中でKernel panicが発生してしまったら、OCI管理画面から対象のインスタンスを強制StopしてまたStartさせて……を繰り返し、不調サーバがつかのま息を吹き返しているうちに続きを実施。

どうやら今回の環境では、コンソールでの直接ログインよりもSSHでのネットワークログインのほうが起動の早い段階で行える、つまりネットワークからアクセスするほうが早く触れて時間的に余裕があると気づいたので、できるだけネットワーク経由で作業を行うようにした。

  1. 不調サーバ (Kernel panicを吐くインスタンス) のgrubを取得しておき、さらにgrub.cfgをgrepして一つ前のKernelを調べる
ssh <不調サーバ>
scp /etc/default/grub <他のサーバ>:/tmp/grub.original
grep -E '(menuentry|submenu) ' /boot/grub/grub.cfg > /tmp/menu.txt && scp /tmp/menu.txt <他サーバ>:/tmp/menu.txt
  1. 他サーバの上で、一つ前のKernelで起動するための緊急用のgrubを用意する
## 他サーバにて
$ cd /tmp
$ cp grub.original grub.emergency
$ vim grub.emergency
## https://blog.masu-mi.me/post/2020/12/05/switch-kernel-with-grub2/ と
## menu.txtを参考にしながら一つ前のkernelを使う中身に編集する

$ diff grub.original grub.emergency 
6c6
< GRUB_DEFAULT=0
---
> GRUB_DEFAULT='Advanced options for Ubuntu>Ubuntu, with Linux 5.13.0-1030-oracle'
  1. 緊急用のgrubを不調サーバに適用して再起動を試みる
scp grub.emergency <不調サーバ>:/tmp/
ssh <不調サーバ>
sudo mv /tmp/grub.emergency /etc/default/grub && sudo update-grub && sudo reboot

最後のsudo update-grub && sudo rebootまでやり通すことができれば、不調サーバは一つ前のKernelで正常に起動してくるはず。

【事後談】問題のインスタンスがマウントしているボリュームを他のインスタンスでマウントし、そちらでGRUBの設定を変更するという方法も可能かも。このほうがデータ破壊の恐れを最小化できるだろうが、OCIでのやり方を知らない。

Twitter情報: docker絡み?

とりあえず上記の復旧作業を暫定的に行ってほっとした後、Twitterにて Andrew (@andriusk) さんから有用な情報をいただいた。そのリンク先によると、私が問題に遭遇したOCIのインスタンスの他に、AWS (Amazon Web Services), Microsoft Azure, GCE (Google Compute Engine) でも同様の問題が発生しているらしい。

そして問題のKernel panicが発生するのは、dockerが動いている環境らしいのだ。ひぇぇー、私の環境が特殊だったというわけではなく、影響が広範囲っぽくて大変だ。

関連の情報源は次の通り。特に2のリンク先ではスレッドが進行中に思える。発生条件的に該当する環境では、問題が解決するまではKernelの更新は見守ったほうが無難であろう。

  1. kernel panic on Ubuntu 20.04.4 LTS with kernel 5.13.0-1028-aws when using docker | AWS re:Post
  2. Bug #1977919 “Docker container creation causes kernel oops on linux-aws 5.13.0.1028.31~20.04.22”: Bugs : linux-aws package : Ubuntu
    • 影響を受けるKernelがcomment #21に書かれている

      Work on this issue continues. We have identified the following impacted kernels and versions:

      focal linux-aws-5.13 5.13.0-1028.3120.04.1
      focal linux-azure-5.13 5.13.0-1028.33      20.04.1
      focal linux-gcp-5.13 5.13.0-1030.3620.04.1
      focal linux-oracle-5.13 5.13.0-1033.39      20.04.1

  3. Kernel Panic with Docker on some Cloud-optimized Ubuntu Kernels - General - GitLab Forum

追記 [2022-06-09 22:26]

Kernelエラーの問題がdocker絡みだと判明した上での暫定対処方法として、インスタンスの起動直後にdockerサービスを停止 (stop) または無効化 (disable) することも考えられる。

追記 [2022-06-10 17:05]

GCEとOCIのインスタンスで、問題を回避するために実際にどのような操作をしたかの奮闘記。大変参考になる。

参考リンク