Instances failes to boot from volume

[Attila Fazekas]

Logstash query for full console outputs which does not contains 'info: initramfs loading root from /dev/vda' , but contains the previous boot message.

These issues look like ssh connectivity issue, but the instance is not booted and it happens regardless to the network type.

message: "Freeing unused kernel memory" AND message: "Initializing cgroup subsys cpuset" AND NOT message: "initramfs loading root from" AND tags:"console"

49 incident/week.

Example console log:
http://logs.openstack.org/75/113175/1/gate/check-tempest-dsvm-neutron-full/827c854/console.html.gz#_2014-08-14_11_23_30_120

It failed when it's tried to ssh 3th server.
WARNING: The conole.log contains two instances serial console output, try no to mix them when reading.

The fail point in the test code was here:
https://github.com/openstack/tempest/blob/b7144eb08175d010e1300e14f4f75d04d9c63c98/tempest/scenario/test_volume_boot_pattern.py#L175

[Attila Fazekas (afazekas)]

E-mail about this issue: http://lists.openstack.org/pipermail/openstack-dev/2014-August/043347.html

[Nikola Đipanov (ndipanov)]

I've reported the following bug that might be related: https://bugs.launchpad.net/nova/+bug/1359617

[John Griffith (john-griffith)]

I'm not sure why this is logged as a Cinder bug? Other than the fact that it's boot from volume perhaps, but the instance appears to boot correctly and is in ACTIVE state. The issue here seems to be networking as the ssh connection fails... no?

http://logs.openstack.org/75/113175/1/gate/check-tempest-dsvm-neutron-full/827c854/console.html.gz#_2014-08-14_11_23_29_423

Not sure if this is on the Neutron side or the Nova side, but I suspect it's a networking issue, regardless doesn't seem like a Cinder issue as far as I can tell.

[Sean Dague (sdague)]

That output is the kind of output that would always be dumped from the console, it's not really a useful bug

[Attila Fazekas (afazekas)]

sdague: The query contains a NOT message: "initramfs loading root from" , which means something is not dumped from serial console to the jenkins console log what should be there if the volume properly attached.

Basically it means the instance is booted, but did not find the block device. There are other sings in the console log about the block device was not detected.

jgriffith: The issue is NOT an ssh issue, the vda is not visible on the guest. the instance even did not reached the state when it tries to set up addresses for the interfaces.

Please be aware we are directly injecting the kernel and the initramfs to the vm memory, so those part can work with a working block device. We see the issue when the system really tries to touch the block device.

[Ning Sun (ning-sun)]

Anyone working on this bug?

[Lee Yarwood (lyarwood)]

@Attila I only see a single novaclient hit with your original query in the last 30 days, I assume this is no longer an issue and can be closed correct?

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY