Re: DTBs in cd images, kexec & installer testing
On Sun, 2014-07-13 at 11:48 +0100, Neil Williams wrote:
> On Sun, 13 Jul 2014 10:32:46 +0100
> Ian Campbell <ijc@hellion.org.uk> wrote:
>
> > On Sat, 2014-07-12 at 22:54 +0100, Neil Williams wrote:
> >
> > > The big issue with testing installers on ARM is the variability in
> > > bootloaders and device support. What LAVA can provide is a common
> > > base. A known working Linaro kernel/bootloader combination could
> > > get the board to a known state and then use kexec to boot into the
> > > ARMMP kernel. The first kernel would need to also be using device
> > > tree and a similar vintage but this could act as an incentive to
> > > get device support into mainline and hence to be available in ARMMP.
> >
> > If I were working on LAVA I'd be rather concerned about relying on
> > kexec in this way, since IME it's subtle and easy to break (if indeed
> > it works to start with), but I suppose you deliberately want to catch
> > that ;-).
>
> We have had kexec working in a LAVA context - there are lots of calls
> and methods used in LAVA which are less reliable...
Interesting. IME it's rather fragile and prone to breakage, but that's
mostly on x86.
> > > What needs to happen in Debian is to make the dtb available to a
> > > kexec call inside the ISO.
> >
> > A kexec call seems to be fairly specific to the lava workflow, I think
> > we'd want this to be equally usable from u-boot or UEFI, wouldn't we?
>
> UEFI yes. u-boot is just too variable. One of the reasons to look at
> kexec is that it isolates the variability of u-boot support.
But how do you boot that initial kernel (the one which does the kexec)
if not via u-boot?
> As a means of testing the installer, u-boot is only usable for one
> specific type of device at a time and needs to mangle part of the
> installer or have explicit support already embedded. Not particularly
> friendly for the ARMMP kernel.
I'm not sure what you mean here, what needs mangling in the Debian
installer?
AFAIK the Debian installer should run on all the platforms which it
supports out of the box, that's the goal at least.
For platforms which are unsupported I'm not sure why booting the
installer via kexec instead of uboot should make a difference to how
well it bodges along.
If we care about those platforms we should add the necessary support for
them to the installer, since our end users surely aren't going to be
kexecing from LAVA.
> However, u-boot support is already in-place for a large number of
> boards whilst UEFI is not. How many existing boards will add support
> for UEFI is uncertain. With a kexec, the original u-boot can still be
> there, so it's potentially less work to get to the point of being able
> to test.
>
> Although LAVA can add this workflow, it isn't specific to LAVA. During
> testing, LAVA can use a variety of methods to get to the pointed where
> a suitable kernel has booted and then do the kexec. With that data and
> the images and calls that produced it, the same method could be
> scripted (in the same way that my previous company used kexec) to
> boot the installer on other systems of the same type.
>
> Once installed, it's down to u-boot to use the installed files.
>
> > Why ISOs BTW? They don't seem all that typical on ARM systems,
>
> As a route to the default packaged ARMMP kernel.
>
> ISOs are more permanent than a weblink and easier to reproduce over a
> number of deployments and
I don't believe that the netboot installer images hosted on debian.org
change any more or less frequently than the ISOs (that goes for
images/ISO which are part of stable).
Either way if you care about permanence and reproducibility then you
need to copy the thing locally.
> the Debian ISO has never been tested on ARM.
Is there even any ARM platform out there with a optical drive on it?
> It's also, arguably, the easiest deployment for random developers to
> set up at home without needing a extra infrastructure or having to get
> involved in actual uboot commands.
Why does ISO vs. netboot image require more or less infrastructure or
exposure to u-boot commands?
> > wouldn't netboot be more normal? We already publish the DTBs for
> > those e.g.
> > http://d-i.debian.org/daily-images/armhf/daily/device-tree/ (needs a
> > new upload of d-i before that layout will hit Jessie)
>
> Didn't know about those ....
>
> https://staging.validation.linaro.org/scheduler/job/49915/log_file#L_57_136
>
> Not sure how to convert the console output to something recognisable or
> how to get LAVA to recognise that output, but it looks reasonable to
> me....
That's the curses installer output.
I usually use "DEBIAN_FRONTEND=text" if I want to log it rather than
interact with it.
Note that the netboot installer doesn't differ from the installer on the
ISOs wrt it's use of curses by default, so if you have it working with
ISOs then you most likely have the scaffolding somewhere...
Ian.
Reply to: