(also, my system comes up in much the same state as if I hadn't done the
reinstall in my late_command script)
--
karmic netboot UEC install fails at registering nodes
https://bugs.launchpad.net/bugs/480125
You received this bug notification because you are a member of Ubuntu
Server Team, which
On a whim, I decided to query debconf with debconf-show eucalyptus-cc
before and after the purge/reinstall:
Nov 18 17:04:03 in-target: eucalyptus/mode: MANAGED-NOVLAN
Nov 18 17:04:03 in-target: * eucalyptus/publicips:
Nov 18 17:04:03 in-target: eucalyptus/dns: 172.24.1.1
Nov 18 17:04:03
Once I narrowed it down to debconf, Colin Watson immediately clued me to
the fact that I most likely had the wrong owner for my eucalyptus-cc
settings. In fact, I had just cutwasted the d-i from the eucalyptus-
udeb settings and not even thought twice about it. Changing the owner
to
It works, so you can resolve/reject this bug as user error.
--
karmic netboot UEC install fails at registering nodes
https://bugs.launchpad.net/bugs/480125
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Cool, thanks for the followup, Nick!
** Changed in: eucalyptus
Status: New = Invalid
** Changed in: eucalyptus (Ubuntu)
Status: Confirmed = Invalid
--
karmic netboot UEC install fails at registering nodes
https://bugs.launchpad.net/bugs/480125
You received this bug notification
I've attached a snippet of /var/log/installer/syslog from a system just after
PXE installation attempted to make a CC of it via the eucalyptus-udeb. You'll
notice that it's Setting up version 1.6~bzr931-0ubuntu7 of eucalyptus-cc. It
then runs ssh-keygen via an su to the eucalyptus user, and
Ignoring for the moment that the subnet is all wrong for the IP range I
have chosen, here is the diff of /etc/eucalyptus before and after I
purged/reinstalled eucalyptus-cc
** Attachment added: post-purge.diff
http://launchpadlibrarian.net/35802128/post-purge.diff
--
karmic netboot UEC
I pulled everything out that I thought could be interfering (mostly by
not specifying a preseed/late_command *anywhere*) but still no luck.
I'll poke around in the maintainer scripts to see if i can spot any
obvious reason why this stuff would fail based on the install
environment like this.
--
Updated title to reflect latest findings. I also changed autodiscovery
- registration of nodes since --discover-nodes seems to discover
nodes alright, it's the node register operation that --discover-nodes
triggers that ends up buggy. I suspect you could reproduce it by
manually running
