----- Original Message -----
Excerpts from Don Zickus's message of 2017-07-26 14:37 -04:00:
> Hi Dan,
> I am playing with some KernelCI stuff and one of the topics is fast
> booting/installs of a new kernel. The thought is waiting 20-25 minutes to
> install Anaconda is too long, when you are resource constrained and need to
> run 30-40 tests/day on the same hardware.
> An idea came up about creating a custom kernel and initrd with a testsuite
> builtin. Currently I don't think beaker supports that, only pre-loaded
> distro kernels/initrds.
> How hard is it to add that to the LabController? Or some other
Bill actually floated a similar idea many years ago, to make it
faster/non-destructive to run the Beaker hardware scanning script. Just
build it into an initramfs, boot it up and let it run without installing
anything to disk.
I guess you would be looking at something similar here?
It would be a nice piece of functionality although you are right, it
doesn't really fit with Beaker's current assumptions about installing
There are probably two big pieces you would need in place. One is the
ability to boot a particular installer tree (or in your case, no
installer, just kernel+initrd) by feeding Beaker the exact URL.
Basically bypassing the distro library. If you are producing 30-40
different kernel builds per day (plus corresponding initramfs image) you
don't really want to register each of them with Beaker's distro library.
That would be covered by this RFE:
Can you elaborate on what would be required here? I'm currently imagining
this as "wget" that stores vmlinuz+initrd to tftpboot directory.
More importantly, we would also need a way for a Beaker recipe to skip
the installation step.
I think initially we could work around this. I'm assuming all that's needed
is to make query to $LC's install_start/done as soon as we boot.
We have discussed a similar idea in the past for
image-based "distros" like RHEV-H where there is no installation step,
it just boots straight into the environment. Atomic has a new-ish
"PXE-to-live" feature that works the same way too. It's kind of touched
on in this Beaker RFE:
In your case, it might be enough to just make Beaker skip the kickstart
generation (and hide the relevant bits of the UI that task about the
recipe installation) assuming that the initramfs will contain a harness
that can report back to Beaker.
Kickstart might be useful to have, you can parse some data out of it,
e.g. LC URL/variables, yum repos, etc.
Also I think it still makes sense to keep <distro> tag in jobs. Your
kernel/initrd is going to be based on existing distros, so it'd be nice
if beaker gave you machine that supports it, <distro> is useful for
excluded families. And there might be also specific options that need
to be passed on kernel command line for things to work.