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

[Brandon James]

Arash,

    I ran into the same issue on all my instances. It appears that during
the last kernel updates on the instances it did not complete or was not
happy(Not sure exactly what triggered it). I resolved this issue by booting
each instance into rescue mode. I did that by running the command  "nova
rescue system name".

http://docs.openstack.org/user-guide/cli-reboot-an-instance.html

   Once the system was in rescue mode I was able to ssh into the instance
and run yum update to correct the incomplete kernel install. On some of my
instances I had to run yum reinstall kernel which seems to resolve it on
all of my instances. I hope this provides you some help as this issue was
strange and I was not sure what exactly caused it.


Cheers,
Brandon

On Sat, Dec 17, 2016 at 7:35 AM, Arash Kaffamanesh <ak at cloudssky.com> wrote:

> 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
>
>
> _______________________________________________
> rdo-list mailing list
> rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com
>



-- 


Brandon James
CEO & Founding Member
Email:    brandon.james at sunayu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20161222/187c540a/attachment.html>