ubuntu上のCentOSを再起動したときにカーネルパニックが発生する場合の対処
先日Ubuntu 12.04.1 LTS上で、KVMの環境を作りました。
CentOS6.3の仮想マシンを再起動すると、毎回、カーネルパニックが発生する事象に遭遇。
# shutdown -r now Broadcast message from root@localhost.localdomain (/dev/ttyS0) at 12:36 ... The system is going down for reboot NOW! [root@otrs ~]# sshd を停止中: [ OK ] postfix を停止中: [ OK ] crond を停止中: [ OK ] auditd を停止中: type=1305 audit(1348284995.393:33): audit_pid=0 old=995 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1 [ OK ] type=1305 audit(1348284996.194:34): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditctl_t:s0 res=1 システムロガーを停止中: [ OK ] インターフェース eth0 を終了中: [ OK ] ループバックインターフェースを終了中 [ OK ] iptables: ファイアウォールルールを消去中: [ OK ] iptables: チェインをポリシー ACCEPT へ設定中filter [ OK ] iptables: モジュールを取り外し中:[ OK ] Stopping monitoring for VG VolGroup: 2 logical volume(s) in volume group "VolGroup" unmonitored [ OK ] Sending all processes the TERM signal... [ OK ] Sending all processes the KILL signal... [ OK ] Saving random seed: [ OK ] Syncing hardware clock to system time [ OK ] Turning off swap: [ OK ] Unmounting file systems: [ OK ] init: Re-executing /sbin/init Please stand by while rebooting the system... md: stopping all md devices. Restarting system. machine restart general protection fault: fff2 [#1] SMP last sysfs file: /sys/devices/virtual/block/dm-0/dm/name CPU 0 Modules linked in: ipt_REJECT virtio_balloon 8139too 8139cp mii i2c_piix4 i2c_core sg ext4 mbcache jbd2 sd_mod crc_t10dif virtio_pci virtio_ring virtio pata_acpi ata_generic ata_piix dm_mirror dm_region_hash dm_log dm_mod [last unloaded: nf_conntrack] Pid: 1193, comm: reboot Not tainted 2.6.32-279.5.2.el6.x86_64 #1 Bochs Bochs RIP: 0010:[<ffffffff8102aa71>] [<ffffffff8102aa71>] native_stop_other_cpus+0xb1/0xd0 RSP: 0018:ffff88007aa9ddb8 EFLAGS: 00000246 RAX: ffffffff81a93820 RBX: 0000000000000246 RCX: 3333333333333333 RDX: 0000000000000000 RSI: 00000000000000ff RDI: 0000000000000246 RBP: ffff88007aa9ddd8 R08: 0000000000000001 R09: 0000000000000001 R10: 20656e696863616d R11: 0a74726174736572 R12: 0000000000000001 R13: ffffffff81c017c0 R14: 00007fff6f820ef0 R15: 0000000000000000 FS: 00007feb9f1b8700(0000) GS:ffff880002200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007fff6f81a7a0 CR3: 000000007ac8a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 Process reboot (pid: 1193, threadinfo ffff88007aa9c000, task ffff88007b934ae0) Stack: 0000000000000000 0000000000000000 0000000028121969 0000000001234567 <d> ffff88007aa9dde8 ffffffff8102a214 ffff88007aa9ddf8 ffffffff81029e37 <d> ffff88007aa9de08 ffffffff81029d5f ffff88007aa9de28 ffffffff8108a50e Call Trace: [<ffffffff8102a214>] native_machine_shutdown+0x64/0x80 [<ffffffff81029e37>] native_machine_restart+0x27/0x40 [<ffffffff81029d5f>] machine_restart+0xf/0x20 [<ffffffff8108a50e>] kernel_restart+0x3e/0x60 [<ffffffff8108a6e3>] sys_reboot+0x193/0x220 [<ffffffff8119200f>] ? __d_free+0x3f/0x60 [<ffffffff81192088>] ? d_free+0x58/0x60 [<ffffffff8119a5b0>] ? mntput_no_expire+0x30/0x110 [<ffffffff8117cc61>] ? __fput+0x1a1/0x210 [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b Code: c5 bc 00 4c 89 ef e8 df 5e 25 00 83 f8 01 77 d2 9c 58 66 66 90 66 90 48 89 c3 fa 66 66 90 66 66 90 e8 34 0d 00 00 48 89 df 57 9d <66> 66 90 66 90 48 83 c4 08 5b 41 5c 41 5d c9 c3 66 66 66 66 66 RIP [<ffffffff8102aa71>] native_stop_other_cpus+0xb1/0xd0 RSP <ffff88007aa9ddb8> ---[ end trace 132fc276bfe48761 ]--- Kernel panic - not syncing: Fatal exception Pid: 1193, comm: reboot Tainted: G D --------------- 2.6.32-279.5.2.el6.x86_64 #1 Call Trace: [<ffffffff814fd39a>] ? panic+0xa0/0x168 [<ffffffff81501534>] ? oops_end+0xe4/0x100 [<ffffffff8100f26b>] ? die+0x5b/0x90 [<ffffffff815010a2>] ? do_general_protection+0x152/0x160 [<ffffffff81500875>] ? general_protection+0x25/0x30 [<ffffffff8102aa71>] ? native_stop_other_cpus+0xb1/0xd0 [<ffffffff8102a214>] ? native_machine_shutdown+0x64/0x80 [<ffffffff81029e37>] ? native_machine_restart+0x27/0x40 [<ffffffff81029d5f>] ? machine_restart+0xf/0x20 [<ffffffff8108a50e>] ? kernel_restart+0x3e/0x60 [<ffffffff8108a6e3>] ? sys_reboot+0x193/0x220 [<ffffffff8119200f>] ? __d_free+0x3f/0x60 [<ffffffff81192088>] ? d_free+0x58/0x60 [<ffffffff8119a5b0>] ? mntput_no_expire+0x30/0x110 [<ffffffff8117cc61>] ? __fput+0x1a1/0x210 [<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b
少し調べて、CentOS6.3の仮想マシン側の設定を変えたところ、
一旦問題の回避ができたので、そのときのメモを書いておきます。
まずは、「/etc/sysconfig/network」に以下を追記します。
# vi /etc/sysconfig/network NETWORKING_IPV6=no
つづいて、「/etc/modprobe.d/disable-ipv6.conf」を作成し、以下の一行を追加します。
# vi /etc/modprobe.d/disable-ipv6.conf install ipv6 /bin/true
この設定を追加した上で、再起動を行ったら問題を回避することが出来ました。
# なんで起きているのかは時間を作ってもう少し調べてみよう。。
今日はこんなところで。
