[rdo-list] RDO Mitaka: Kernel panic after instance update - not syncing: VFS: Unable to mount root fs on unknown-block(0, 0)

[Arash Kaffamanesh]

Hello together,

After yum update on CentOS 7.2 instance running on Mitaka, I'm getting the
following Kernel panic message:
I'm using NFS as storage backend and had a similar problem with
CentOS-7-x86_64-GenericCloud-*1608*.qcow2 image and hat to
use CentOS-7-x86_64-GenericCloud-*1511*.qcow2 image (which worked fine till
now).

Has someone faced the same problem with instance updates?

By the way, the kernel panic doesn't happen after yum update on a CentOS
7.2 installation on bare metal.

Thx!
-Arash

[    0.889347] No filesystem could mount root, tried:
[    0.890271] *Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(0,0)*
[    0.891813] CPU: 5 PID: 1 Comm: swapper/0 Not tainted
3.10.0-514.2.2.el7.x86_64 #1
[    0.893287] Hardware name: Fedora Project OpenStack Nova, BIOS
seabios-1.7.5-11.el7 04/01/2014
[    0.894829]  ffffffff818b4340 0000000080f55afb ffff8801820dbd60
ffffffff816861cc
[    0.896526]  ffff8801820dbde0 ffffffff8167f5d3 ffffffff00000010
ffff8801820dbdf0
[    0.898204]  ffff8801820dbd90 0000000080f55afb 0000000080f55afb
ffff8801820dbe00
[    0.899881] Call Trace:
[    0.900525]  [<ffffffff816861cc>] dump_stack+0x19/0x1b
[    0.901420]  [<ffffffff8167f5d3>] panic+0xe3/0x1f2
[    0.902279]  [<ffffffff81b0a602>] mount_block_root+0x2a1/0x2b0
[    0.903234]  [<ffffffff81b0a664>] mount_root+0x53/0x56
[    0.904127]  [<ffffffff81b0a7a3>] prepare_namespace+0x13c/0x174
[    0.905089]  [<ffffffff81b0a270>] kernel_init_freeable+0x1f5/0x21c
[    0.906077]  [<ffffffff81b099db>] ? initcall_blacklist+0xb0/0xb0
[    0.907058]  [<ffffffff81674630>] ? rest_init+0x80/0x80
[    0.907944]  [<ffffffff8167463e>] kernel_init+0xe/0xf0
[    0.908844]  [<ffffffff81696718>] ret_from_fork+0x58/0x90
[    0.909769]  [<ffffffff81674630>] ? rest_init+0x80/0x80
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20161217/93555021/attachment.html>