© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
@Carlos
The upgrade was from maverick (10.10), but this is a server that I have been using for development and has been on natty devel branch since early days in the cycle. I have had to do a bit of jiggery-pokery with eucalyptus and other packages at points, as tends to be the way during development (instance IFACE problem in the upstart scripts IIRC).
"Why this would have needed dac_override I do not know" - me neither, and that seemed to be a temporary problem. I cannot make that happen now...I'm happy to forget that one ;)
Currently, the only problem I have is that dhcpd won't identify and listen on eucabr10. After that, everything works (or at least as well as it did on maverick...I have the issue with 32-bit images and also that restarting eucalyptus seems to lose the public IP, but that was the case before anyway).
Not sure what other info I can provide, other than what I expect to see instead; switching back to dhcp3, things immediately work as expected:
==> /var/log/
No subnet declaration for eth0.2187 (169.254.169.254).
** Ignoring requests on eth0.2187. If this is not what
you want, please write a subnet declaration
in your dhcpd.conf file for the network segment
to which interface eth0.2187 is attached. **
Listening on LPF/eucabr10/
Sending on LPF/eucabr10/
Sending on Socket/
...I then have both public and private connectivity to the started instance!
A slight aside, I don't know why Eucalyptus passes the VNET_PRIVINTERFACE as last parameter in it's command line to dhcpd[3] as this causes (as it should, since there is no subnet in the config for that interface) the notice seen above in httpd-cc_
I would feel better about this bug if somebody has tested it successfully using VLANs in MANAGED mode? There must be something that happens differently because I'm as certain as I can be that Dan's patch is compiled into the dhcpd bin that is still failing.