And of course when I reply from my phone I forget the list. ---------- Forwarded message ---------- From: "Michael Hudson-Doyle" michael.hudson@canonical.com Date: 27 May 2014 22:12 Subject: Re: [Linaro-validation] using debian-installer and preseeds to deploy in lava To: "Neil Williams" codehelp@debian.org Cc:
On 27 May 2014 20:37, "Neil Williams" codehelp@debian.org wrote:
On Tue, 27 May 2014 15:00:07 +1200 Michael Hudson-Doyle michael.hudson@linaro.org wrote:
For reasons that probably aren't especially good[1] I've been poking a bit today at using a preseeded debian-installer to get an image onto a LAVA system. It turns out to be mostly possible, with a job like this:
http://paste.ubuntu.com/7526204/and a preseed like this:
http://paste.ubuntu.com/7526152/but there is a hard coded timeout on boot_linaro_image of 5 minutes, which is not long enough for d-i to run. Oh well!
:-(
How far did the install get? Is it just a case of saving a few seconds on downloads or doubling the timeout?
More the latter, I think. I haven't timed it, but I think it takes about 15 mins.
Maybe skip the openssh-server tasksel and install that as a separate action after the install has booted?
Yes, that's a good idea. I'll try tomorrow.
ports.ubuntu.com is often *really* slow - a local mirror of that will be a lot more useful, both for the archive and the installer image.
I don't think that's a huge part of the issue here – when I (unpreseededly) d-i-ed some mustangs last week, the first wasn't much slower than the rest (which presumably got most things from squid).
So I guess I have two questions really:
- Would it be possible to override this timeout? I.e. add a
timeout= parameter to boot_linaro_image?
There's no support for that right now - it may be better to have a install_image action added to the list of elements for the upcoming sprint.
- Is there any sense in LAVA supporting d-i as a deployment
method? I guess the dispatcher could even handle generating the preseed for you, at least mostly.
Yes, the dispatcher certainly could handle the pre-seeding of debconf for d-i and for other package installs, using parameters where required. It would be a different kind of deployment with custom deployment data based on the underlying OS.
A separate action would be the best way to implement that.
Oh yes, a separate action is definitely the Right Thing™.
Cheers, mwh (Phone reply, apologies for typos)
--
Neil Williams
http://www.linux.codehelp.co.uk/
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation