On 08.07.2012 01:57, Mike McClurg wrote:
On Sat, Jul 7, 2012 at 10:40 PM, Thomas Goirand<tho...@goirand.fr> wrote:
On 07/08/2012 04:22 AM, Mike McClurg wrote:
So 680102 is due to there not being an /etc/firstboot.d/ directory (as
the ticket explains). I think we can fix this issue simply by
mkdir'ing the directory /etc/firstboot.d/data at some point in xapi's
installation. This would allow the pool-eject to proceed, but I think
that there might be problems when the host reboots: since none of the
firstboot scripts will be called, the host might not reinitialise
properly.
Well, writing in /etc dynamically is *forbidden* by the Debian policy.
The /etc folder is for configuration, not something else! If you were
using /var/lib/xcp-xapi, ok, but not /etc.
Could you think about a better way to fix?
Sure, we can change what xapi thinks is the firstboot directory. See
ocaml/xapi/xapi_globs.ml:593 :
let first_boot_dir = "/etc/firstboot.d/"
We could change that to "/var/lib/xcp/firstboot.d". I'd like to know
whether creating the /etc/firstboot.d directory will solve the problem
though, before we make that change.
Very naive question: Why xcp wants to preserve original database? Isn't
leaving pool same as 'fresh install' (means db creation).
I think situation is somehow differ from XCP ISO where some magic
settings was putted by installer inside 'initial database'. For xcp-xapi
it is kinda easy, because host is still operational even without xapi.
If we preserve networkd settings for management interface, this will
allow to perform that operations via ssh without risks to go offline.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
