| 2012-08-10 12:07:09 |
Louis Bouchard |
bug |
|
|
added bug |
| 2012-08-10 12:58:12 |
Louis Bouchard |
attachment added |
|
nova-api.log.test https://bugs.launchpad.net/nova/+bug/1035279/+attachment/3255768/+files/nova-api.log.test |
|
| 2012-08-10 12:58:34 |
Louis Bouchard |
attachment added |
|
nova-compute.log.test https://bugs.launchpad.net/nova/+bug/1035279/+attachment/3255769/+files/nova-compute.log.test |
|
| 2012-08-10 12:59:30 |
Louis Bouchard |
attachment added |
|
nova-dhcpbridge.log.test https://bugs.launchpad.net/nova/+bug/1035279/+attachment/3255770/+files/nova-dhcpbridge.log.test |
|
| 2012-08-10 12:59:45 |
Louis Bouchard |
attachment added |
|
nova-network.log.test https://bugs.launchpad.net/nova/+bug/1035279/+attachment/3255786/+files/nova-network.log.test |
|
| 2012-08-16 14:24:29 |
Louis Bouchard |
summary |
network to instance lost after reboot followed by euca-reboot-instances |
interactive access to instance lost after reboot followed by euca-reboot-instances |
|
| 2012-08-16 14:25:32 |
Louis Bouchard |
description |
This issue has been reproduced on Diablo and Essex so far.
When doing "sudo reboot" in an instance shortly followed by "euca-reboot-instances {instanceID}", once the instaces comes back up, it is no longer accessible via network (floating IP).
If only "sudo reboot" from within the instance or "euca-reboot-instances" is used, network connectivity comes back as expected.
This can be reproduced by using the following steps :
# On the compute node
sudo -s
source creds/novarc
# start instance
instanceid=`euca-run-instances -k novaadmin -t m1.tiny ami-00000006 | grep INSTANCE | awk '{print $2}'`
# wait for instance to start
sleep 60
# reboot the instance with reboot command
ssh -i creds/novaadmin_.key ubuntu@`euca-describe-instances $instanceid | grep INSTANCE | awk '{print $4}'` 'sudo reboot'
# wait 20 seconds
sleep 20
# reboot instance with euca-reboot-instance command
euca-reboot-instances $instanceid
Now euca-describe-instances will show the instance as running, but it is is unreachable via ssh. The kvm process is still present and running. |
This issue has been reproduced on Diablo and Essex so far.
When doing "sudo reboot" in an instance shortly followed by "euca-reboot-instances {instanceID}", once the instaces comes back up, it is no longer accessible interactively. The kernel is still executing commands but it stucked in the early boot phases
If only "sudo reboot" from within the instance or "euca-reboot-instances" is used, network connectivity comes back as expected.
This can be reproduced by using the following steps :
# On the compute node
sudo -s
source creds/novarc
# start instance
instanceid=`euca-run-instances -k novaadmin -t m1.tiny ami-00000006 | grep INSTANCE | awk '{print $2}'`
# wait for instance to start
sleep 60
# reboot the instance with reboot command
ssh -i creds/novaadmin_.key ubuntu@`euca-describe-instances $instanceid | grep INSTANCE | awk '{print $4}'` 'sudo reboot'
# wait 20 seconds
sleep 20
# reboot instance with euca-reboot-instance command
euca-reboot-instances $instanceid
Now euca-describe-instances will show the instance as running, but it is is unreachable via ssh. The kvm process for the instance is still visible and running. |
|
| 2012-08-20 14:21:06 |
Louis Bouchard |
nova: status |
New |
In Progress |
|
| 2012-08-20 14:21:21 |
Louis Bouchard |
nova: assignee |
|
Louis Bouchard (louis-bouchard) |
|
| 2012-08-20 14:28:52 |
Scott Moser |
bug task added |
|
ubuntu |
|
| 2012-08-20 14:29:19 |
Scott Moser |
tags |
|
cloud-images cloud-images-build |
|
| 2012-08-20 14:30:30 |
Scott Moser |
description |
This issue has been reproduced on Diablo and Essex so far.
When doing "sudo reboot" in an instance shortly followed by "euca-reboot-instances {instanceID}", once the instaces comes back up, it is no longer accessible interactively. The kernel is still executing commands but it stucked in the early boot phases
If only "sudo reboot" from within the instance or "euca-reboot-instances" is used, network connectivity comes back as expected.
This can be reproduced by using the following steps :
# On the compute node
sudo -s
source creds/novarc
# start instance
instanceid=`euca-run-instances -k novaadmin -t m1.tiny ami-00000006 | grep INSTANCE | awk '{print $2}'`
# wait for instance to start
sleep 60
# reboot the instance with reboot command
ssh -i creds/novaadmin_.key ubuntu@`euca-describe-instances $instanceid | grep INSTANCE | awk '{print $4}'` 'sudo reboot'
# wait 20 seconds
sleep 20
# reboot instance with euca-reboot-instance command
euca-reboot-instances $instanceid
Now euca-describe-instances will show the instance as running, but it is is unreachable via ssh. The kvm process for the instance is still visible and running. |
This issue has been reproduced on Diablo and Essex so far.
When doing "sudo reboot" in an instance shortly followed by "euca-reboot-instances {instanceID}", once the instaces comes back up, it is no longer accessible interactively. The kernel is still executing commands but it stucked in the early boot phases
If only "sudo reboot" from within the instance or "euca-reboot-instances" is used, network connectivity comes back as expected.
This can be reproduced by using the following steps :
# On the compute node
sudo -s
source creds/novarc
# start instance
instanceid=`euca-run-instances -k novaadmin -t m1.tiny ami-00000006 | grep INSTANCE | awk '{print $2}'`
# wait for instance to start
sleep 60
# reboot the instance with reboot command
ssh -i creds/novaadmin_.key ubuntu@`euca-describe-instances $instanceid | grep INSTANCE | awk '{print $4}'` 'sudo reboot'
# wait 20 seconds
sleep 20
# reboot instance with euca-reboot-instance command
euca-reboot-instances $instanceid
Now euca-describe-instances will show the instance as running, but it is is unreachable via ssh. The kvm process for the instance is still visible and running.
Related bugs:
* bug 872244: grub2 recordfail logic prevents headless system from rebooting after power outage |
|
| 2012-08-20 14:30:44 |
Scott Moser |
nova: status |
In Progress |
Invalid |
|
| 2012-08-20 14:38:50 |
Scott Moser |
description |
This issue has been reproduced on Diablo and Essex so far.
When doing "sudo reboot" in an instance shortly followed by "euca-reboot-instances {instanceID}", once the instaces comes back up, it is no longer accessible interactively. The kernel is still executing commands but it stucked in the early boot phases
If only "sudo reboot" from within the instance or "euca-reboot-instances" is used, network connectivity comes back as expected.
This can be reproduced by using the following steps :
# On the compute node
sudo -s
source creds/novarc
# start instance
instanceid=`euca-run-instances -k novaadmin -t m1.tiny ami-00000006 | grep INSTANCE | awk '{print $2}'`
# wait for instance to start
sleep 60
# reboot the instance with reboot command
ssh -i creds/novaadmin_.key ubuntu@`euca-describe-instances $instanceid | grep INSTANCE | awk '{print $4}'` 'sudo reboot'
# wait 20 seconds
sleep 20
# reboot instance with euca-reboot-instance command
euca-reboot-instances $instanceid
Now euca-describe-instances will show the instance as running, but it is is unreachable via ssh. The kvm process for the instance is still visible and running.
Related bugs:
* bug 872244: grub2 recordfail logic prevents headless system from rebooting after power outage |
This issue has been reproduced on Diablo and Essex so far.
When doing "sudo reboot" in an instance shortly followed by "euca-reboot-instances {instanceID}", once the instaces comes back up, it is no longer accessible interactively. The kernel is still executing commands but it stucked in the early boot phases
If only "sudo reboot" from within the instance or "euca-reboot-instances" is used, network connectivity comes back as expected.
This can be reproduced by using the following steps :
# On the compute node
sudo -s
source creds/novarc
# start instance
instanceid=`euca-run-instances -k novaadmin -t m1.tiny ami-00000006 | grep INSTANCE | awk '{print $2}'`
# wait for instance to start
sleep 60
# reboot the instance with reboot command
ssh -i creds/novaadmin_.key ubuntu@`euca-describe-instances $instanceid | grep INSTANCE | awk '{print $4}'` 'sudo reboot'
# wait 20 seconds
sleep 20
# reboot instance with euca-reboot-instance command
euca-reboot-instances $instanceid
Now euca-describe-instances will show the instance as running, but it is is unreachable via ssh. The kvm process for the instance is still visible and running.
Related bugs:
* bug 872244: grub2 recordfail logic prevents headless system from rebooting after power outage
* bug 669481: Timeout should not be -1 if $recordfail |
|
| 2012-08-20 14:40:27 |
Scott Moser |
ubuntu: status |
New |
Triaged |
|
| 2012-08-20 14:40:58 |
Scott Moser |
ubuntu: status |
Triaged |
Fix Released |
|
| 2012-08-20 14:43:36 |
Scott Moser |
ubuntu: status |
Fix Released |
In Progress |
|
| 2012-08-20 14:45:37 |
Scott Moser |
summary |
interactive access to instance lost after reboot followed by euca-reboot-instances |
instance hangs at grub prompt after reboot followed by euca-reboot-instances |
|
| 2012-08-20 15:02:30 |
Scott Moser |
nominated for series |
|
Ubuntu Precise |
|
| 2012-08-20 15:02:30 |
Scott Moser |
bug task added |
|
Ubuntu Precise |
|
| 2012-08-20 15:02:54 |
Scott Moser |
ubuntu: status |
In Progress |
Fix Released |
|
| 2012-08-20 15:02:58 |
Scott Moser |
ubuntu: importance |
Undecided |
High |
|
| 2012-08-20 15:03:03 |
Scott Moser |
Ubuntu Precise: status |
New |
In Progress |
|
| 2012-08-20 15:03:06 |
Scott Moser |
Ubuntu Precise: importance |
Undecided |
High |
|
| 2012-08-20 15:03:19 |
Scott Moser |
ubuntu: assignee |
|
Ben Howard (utlemming) |
|
| 2012-08-20 15:03:24 |
Scott Moser |
Ubuntu Precise: assignee |
|
Scott Moser (smoser) |
|
| 2012-08-20 15:22:23 |
Launchpad Janitor |
branch linked |
|
lp:~smoser/vmbuilder/automated-ec2-builds.lp1035279 |
|
| 2012-08-20 18:44:51 |
Scott Moser |
Ubuntu Precise: status |
In Progress |
Fix Committed |
|
| 2012-08-21 11:43:05 |
Louis Bouchard |
nova: assignee |
Louis Bouchard (louis-bouchard) |
|
|
| 2012-08-21 12:36:22 |
Louis Bouchard |
branch linked |
|
lp:~louis-bouchard/ubuntu/precise/grub2/grub2-recordfail-timeout |
|
| 2012-08-21 14:10:12 |
Scott Moser |
branch linked |
|
lp:~louis-bouchard/ubuntu/precise/grub2/grub2-recordfail-timeout |
|
| 2012-11-06 18:24:18 |
Scott Moser |
nominated for series |
|
Ubuntu Oneiric |
|
| 2012-11-06 18:24:18 |
Scott Moser |
bug task added |
|
Ubuntu Oneiric |
|
| 2012-11-06 18:25:08 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-on-ec2/vmbuilder/automated-ec2-builds |
|
| 2012-11-06 18:25:58 |
Scott Moser |
Ubuntu Oneiric: status |
New |
Fix Committed |
|
| 2012-11-06 18:32:27 |
Scott Moser |
Ubuntu Precise: status |
Fix Committed |
Fix Released |
|
| 2013-06-06 13:04:37 |
Scott Moser |
Ubuntu Oneiric: status |
Fix Committed |
Fix Released |
|
| 2016-07-08 22:48:23 |
Mathew Hodson |
affects |
nova |
ubuntu-on-ec2 |
|
| 2016-07-08 22:48:23 |
Mathew Hodson |
ubuntu-on-ec2: status |
Invalid |
Fix Released |
|
| 2016-07-08 22:48:36 |
Mathew Hodson |
Ubuntu Oneiric: importance |
Undecided |
High |
|
| 2016-07-08 22:48:43 |
Mathew Hodson |
affects |
ubuntu |
grub2 (Ubuntu) |
|
