Scott,
I just tested a recent Maverick AMI and it does indeed correctly set the hostname to the newly assigned internal domain name after a stop/start sequence. So no need to open any other bugs on that score.
+ uname -n
ip-10-117-39-235
+ hostname -s
ip-10-117-39-235
+ hostname -d
ec2.internal
+ hostname -f
ip-10-117-39-235.ec2.internal
+ hostname
ip-10-117-39-235
+ echo ip-10-117-39-235
ip-10-117-39-235
+ cat /etc/hostname
ip-10-117-39-235
+ /sbin/sysctl -n kernel.hostname
ip-10-117-39-235
Now the question is how early in the boot process does cloud-init run?
With the changes in this bug, how can we make another boot process wait until cloud-init has completed setting up the hostname?
Scott, 39-235. ec2.internal
I just tested a recent Maverick AMI and it does indeed correctly set the hostname to the newly assigned internal domain name after a stop/start sequence. So no need to open any other bugs on that score.
+ uname -n
ip-10-117-39-235
+ hostname -s
ip-10-117-39-235
+ hostname -d
ec2.internal
+ hostname -f
ip-10-117-
+ hostname
ip-10-117-39-235
+ echo ip-10-117-39-235
ip-10-117-39-235
+ cat /etc/hostname
ip-10-117-39-235
+ /sbin/sysctl -n kernel.hostname
ip-10-117-39-235
Now the question is how early in the boot process does cloud-init run?
With the changes in this bug, how can we make another boot process wait until cloud-init has completed setting up the hostname?