CentOS7でbootできなくなったときの対処¶
2020/8/6¶
自宅の環境ではKVM上でいくつかの仮想サーバが動いている。
仮想サーバのOSはCentOS7.8で、yum-cronを動かして放置していた。
先日、久しぶりにOS再起動をしたところ、OSが起動できなくなってしまった。
起動時のログを見ていると、以下のログが出ていた。
[ 1.013801] List of all partitions:
[ 1.015108] No filesystem could mount root, tried:
[ 1.016734] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 1.019481] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-1127.18.2.el7.x86_64 #1
[ 1.022194] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[ 1.023881] Call Trace:
[ 1.025034] [<ffffffffb577ffa5>] dump_stack+0x19/0x1b
[ 1.026803] [<ffffffffb5779541>] panic+0xe8/0x21f
[ 1.028402] [<ffffffffb5d8b794>] mount_block_root+0x291/0x2a0
[ 1.030085] [<ffffffffb5d8b7f6>] mount_root+0x53/0x56
[ 1.031749] [<ffffffffb5d8b935>] prepare_namespace+0x13c/0x174
[ 1.034253] [<ffffffffb5d8b412>] kernel_init_freeable+0x222/0x249
[ 1.036027] [<ffffffffb5d8ab28>] ? initcall_blacklist+0xb0/0xb0
[ 1.037817] [<ffffffffb576e6b0>] ? rest_init+0x80/0x80
[ 1.039407] [<ffffffffb576e6be>] kernel_init+0xe/0x100
[ 1.040978] [<ffffffffb5792d37>] ret_from_fork_nospec_begin+0x21/0x21
[ 1.042843] [<ffffffffb576e6b0>] ? rest_init+0x80/0x80
[ 1.044603] Kernel Offset: 0x34000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
rootのファイルシステムがマウントできず、カーネルパニックを起こしているらしい。
調べてみた結果、yumとかで新しいカーネルバージョンにアップデートされると、
上記のエラーメッセージが出て、できなくなることがあるらしい。
対処としては、OS起動時にカーネルバージョン選択画面が出てくるので、古いカーネルバージョンを指定して起動してあげれば起動できるようにはなるらしい。
さて、それはわかったが、KVMだとそれをどうやればいいんだろうということだ。
GUI環境がまったくなく、起動時にカーネルバージョンを指定することができない。
KVMのコマンドでカーネルバージョンの指定をする方法等調べてみたが、その方法は見つけることができなかった。
直接bootの設定ファイルを書き換えて対処できないかと思考錯誤してみて、対処できたので、その方法をまとめる。
KVMではOSをレスキューモードで起動するオプションが用意されている。
# virt-rescue -d [仮想マシン名]
色々と起動時のメッセージが出た後、レスキューモードで起動されたことが表示される。
Welcome to virt-rescue, the libguestfs rescue shell.
Note: The contents of / (root) are the rescue appliance.
You have to mount the guest’s partitions under /sysroot
before you can examine them.
><rescue>
まずは、仮想マシンのファイルシステムをマウントして操作できるようにする。
fdisk -l でdiskの情報を出力する。
><rescue> fdisk -l
Disk /dev/sda: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000dea8a
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux
/dev/sda2 1026048 41943039 20458496 8e Linux LVM
Disk /dev/sdb: 4294 MB, 4294967296 bytes, 8388608 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/centos-root: 18.8 GB, 18798870528 bytes, 36716544 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/centos-swap: 2147 MB, 2147483648 bytes, 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
/dev/sda1がbootパーティション、
/dev/sda2がLVMで、
* /dev/mapper/centos-root
* /dev/mapper/centos-swap
の論理パーティションがあることがわかる。
bootパーティションを書き換えるのでマウントし、中身を覗いてみる。
(/mnt/bootディレクトリを作成し、そこに/dev/sda1をマウントさせた)
><rescue> mkdir /mnt/boot
><rescue> mount /dev/sda1 /mnt/boot/
><rescue> cd /mnt/boot/
><rescue> ls -l
total 169052
-rw-------. 1 root root 3600165 Mar 17 23:53 System.map-3.10.0-1062.18.1.el7.x86_64
-rw-------. 1 root root 3611728 Jun 3 14:32 System.map-3.10.0-1127.10.1.el7.x86_64
-rw-------. 1 root root 3612279 Jun 23 15:50 System.map-3.10.0-1127.13.1.el7.x86_64
-rw-------. 1 root root 3612386 Jul 26 15:31 System.map-3.10.0-1127.18.2.el7.x86_64
-rw-------. 1 root root 3611697 May 12 17:01 System.map-3.10.0-1127.8.2.el7.x86_64
-rw-r--r--. 1 root root 153187 Mar 17 23:53 config-3.10.0-1062.18.1.el7.x86_64
-rw-r--r--. 1 root root 153567 Jun 3 14:32 config-3.10.0-1127.10.1.el7.x86_64
-rw-r--r--. 1 root root 153567 Jun 23 15:50 config-3.10.0-1127.13.1.el7.x86_64
-rw-r--r--. 1 root root 153567 Jul 26 15:31 config-3.10.0-1127.18.2.el7.x86_64
-rw-r--r--. 1 root root 153566 May 12 17:01 config-3.10.0-1127.8.2.el7.x86_64
drwxr-xr-x. 3 root root 16 Oct 17 2017 efi
drwxr-xr-x. 2 root root 26 Aug 27 2017 grub
drwx------. 5 root root 4096 Jul 31 12:02 grub2
-rw-r--r--. 1 root root 29085758 May 12 2015 initramfs-0-rescue-d45dd82781eb6f6143cf189e1d9a7755.img
-rw-------. 1 root root 21051372 Jun 25 22:09 initramfs-3.10.0-1062.18.1.el7.x86_64.img
-rw-------. 1 root root 21063705 Jun 25 22:09 initramfs-3.10.0-1127.10.1.el7.x86_64.img
-rw-------. 1 root root 21065960 Jun 25 22:08 initramfs-3.10.0-1127.13.1.el7.x86_64.img
-rw-------. 1 root root 21061094 Jun 11 00:28 initramfs-3.10.0-1127.8.2.el7.x86_64.img
-rw-r--r--. 1 root root 611392 Oct 17 2017 initrd-plymouth.img
-rw-r--r--. 1 root root 318991 Mar 17 23:53 symvers-3.10.0-1062.18.1.el7.x86_64.gz
-rw-r--r--. 1 root root 320504 Jun 3 14:32 symvers-3.10.0-1127.10.1.el7.x86_64.gz
-rw-r--r--. 1 root root 320513 Jun 23 15:50 symvers-3.10.0-1127.13.1.el7.x86_64.gz
-rw-r--r--. 1 root root 320536 Jul 26 15:31 symvers-3.10.0-1127.18.2.el7.x86_64.gz
-rw-r--r--. 1 root root 320504 May 12 17:01 symvers-3.10.0-1127.8.2.el7.x86_64.gz
-rwxr-xr-x. 1 root root 4902656 May 12 2015 vmlinuz-0-rescue-d45dd82781eb6f6143cf189e1d9a7755
-rwxr-xr-x. 1 root root 6738112 Mar 17 23:53 vmlinuz-3.10.0-1062.18.1.el7.x86_64
-rwxr-xr-x. 1 root root 6762688 Jun 3 14:32 vmlinuz-3.10.0-1127.10.1.el7.x86_64
-rwxr-xr-x. 1 root root 6762688 Jun 23 15:50 vmlinuz-3.10.0-1127.13.1.el7.x86_64
-rwxr-xr-x. 1 root root 6761064 Jul 26 15:31 vmlinuz-3.10.0-1127.18.2.el7.x86_64
-rwxr-xr-x. 1 root root 6762688 May 12 17:01 vmlinuz-3.10.0-1127.8.2.el7.x86_64
><rescue> cd grub2
><rescue> ls
><rescue> ls -l
total 64
-rw-r--r--. 1 root root 84 May 12 2015 device.map
drwxr-xr-x. 2 root root 24 May 12 2015 fonts
-rw-r--r--. 1 root root 7597 Jul 30 23:02 grub.cfg
-rw-r--r--. 1 root root 6741 Aug 9 2015 grub.cfg.1503876154.rpmsave
-rw-r--r--. 1 root root 7619 Aug 27 2017 grub.cfg.1508282747.rpmsave
-rw-r--r--. 1 root root 7629 Sep 28 2018 grub.cfg.1543960359.rpmsave
-rw-r--r--. 1 root root 7635 Jul 31 2019 grub.cfg.1568853580.rpmsave
-rw-r--r--. 1 root root 1024 Jul 30 23:02 grubenv
drwxr-xr-x. 2 root root 8192 May 12 2015 i386-pc
drwxr-xr-x. 2 root root 4096 May 12 2015 locale
7/26 15:31に最新のカーネルが入ったらしい。
(問題が発生したのは7/31)
3.10.0-1127.18.2.el7.x86_64とは違うカーネルバージョンでブートしたい。
結論から、grub2/grubenvを書き換えることで、起動時のデフォルトカーネルバージョンを変更することができた。
grub2/grubenvを覗いてみる。
# cat grubenv
# GRUB Environment Block
saved_entry=CentOS Linux (3.10.0-1127.18.2.el7.x86_64) 7 (Core)
#######################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################
3.10.0-1127.18.2.el7.x86_64 がカーネルバージョンなので、これを書き換えてやれば良さそうだ。
ただ書き換えようとしたとき、viコマンドを使ったところ、viコマンドが存在しないメッセージが表示された。
そこで、viが入っているrootパーティションもマウントすることで、viを使えるようにした。
><rescue> mkdir /mnt/root
><rescue> mount /dev/mapper/centos-root /mnt/root/
→こうすることで、/mnt/root/bin/のパスでマウントされるので、/mnt/root/bin/viとフルパスを記載してviを動かす。
（パスを通してもいいが、１回使うだけなので）
viを使って、grub2/grubenvを書き換える。
><rescue> /mnt/root/bin/vi grubenv
以下のように書き換えた
saved_entry=CentOS Linux (3.10.0-1127.18.2.el7.x86_64) 7 (Core)
↓
saved_entry=CentOS Linux (3.10.0-1127.13.1.el7.x86_64) 7 (Core)
一つ前のバージョン3.10.0-1127.13.1.el7.x86_64 に変更した。
レスキューモードを抜け
><rescue> exit
exit
起動してみる。
virsh start [仮想マシン名]
起動できた！
起動したOSのカーネルバージョンを確認してみる。
# uname -r
3.10.0-1127.13.1.el7.x86_64
ちゃんと指定したカーネルバージョンで起動していることを確認できた。
起動できるようになれば、あとは多数のサイトに案内されている通りの方法で対処できる。
しかし、yum-cron設定して放置しておくのもなかなか危ないと思った体験だった。
（個人の趣味レベルのサーバなので、あまり問題にはならないが）