----- Original Message -----
From: "Dan Callaghan" <dcallagh(a)redhat.com>
To: "Jan Stancek" <jstancek(a)redhat.com>
Cc: "Don Zickus" <dzickus(a)redhat.com>, "Artem Savkov"
<asavkov(a)redhat.com>, "Prarit Bhargava" <prarit(a)redhat.com>,
"Jeffrey Burke" <jburke(a)redhat.com>, "Hannes Sowa"
Sent: Monday, 21 August, 2017 8:46:38 AM
Subject: Re: temporary way of booting custom kernel and initrd in Beaker today
On Fri, Aug 18, 2017 at 10:45 AM, Jan Stancek <jstancek(a)redhat.com> wrote:
> Jeff&I arrived to an idea how (maybe) we could start playing with
> booting custom kernel/initrd today:
> We create a custom distro, for example we copy Fedora26 with different
> name: "SKT26", and we place it somewhere where we have RW access to it.
> Then we import it to Beaker manually.
> If my understanding of Beaker is correct, we can freely replace
> kernel/initrd in our distro and Beaker will always copy latest
> files to tftp when we run a job.
> Obviously the problem is concurrency and reproducibility of jobs,
> but it would a quick way to allow us experimenting with custom
> kernels/initrds today.
> Any comments/thoughts?
Yes I think this should work and would be a good workaround for the
We would just need to make sure that the new fake distro tree is not
picked up by beaker-pxemenu to be included in the PXELINUX menu. If it
is included in the menu, the kernel+initrd will be cached on the LC and
beaker-provision will just re-use the cached images instead of
re-downloading them each time.
Is this already possible to configure with current Beaker/LC?
Excerpts from Hannes Frederic Sowa's message of 2017-08-19 18:49 -04:00:
> What about synchronizing /lib/modules directory with initrd + vmlinuz?
> In a lot of cases we depend on dynamically loaded modules even during
> testing phase. Is this also possible with this schema?
> Thanks for looking into this,
This is a good point. I guess it is not enough to just replace
pxeboot/vmlinuz and pxeboot/initrd.img, but also the kernel-related
packages (and the Anaconda stage2.img as well?) -- almost an entire new
compose in place each time.
I don't see a problem here, as soon as we can boot custom kernel+initrd
and change kernel_options, any approach should be possible:
- put everything into initrd
- standard vmlinuz+initrd + stage2 (or equivalent)
- nfs rootfs
Which begs the question... if you are doing an entirely new compose each
time, whys not just register each one in Beaker separately?
I'm not sure we are doing entirely new compose. To get us on same level
as for example F26, we'd need:
- kernel+initrd (possibly stage2 install.img)
- compose metadata
- same distro/system install options
- same excluded families
I don't have a good answer for this. We can try to compare the 2 approaches:
1. Overriding kernel+initrd for existing distro:
For example, by adding following to job xml:
+ seems easier to implement
+ we only need to build kernel+initrd (and stage2)
+ kickstart would automatically contain rpm repos for "base distro"
+ distro specific install options and excluded families continue to work as for base
- doesn't address BZ 911515
2. Registering new compose:
? Would it get imported automatically based on same job tag, or by a person/script?
? What would be the lifetime of such distro? We would probably have a lot
scratch builds/composes daily.
- slightly more difficult for us, we'd need to generate some metadata and
figure out how to provide repos/packages/RPMs from base distro
+ covers our use-case and also BZ 911515
? Can we re-use major/minor base distro names? (to pick up same install
options and excluded families as base distro)
> Let's continue the discussion on the devel list (cc'ed) so others can
> see. Coincidentally Anwesha has just started working on proper support
> for "user-supplied distro trees" in bug 911515 so we should see some
> progress on that soon.
> Dan Callaghan <dcallagh(a)redhat.com>
> Senior Software Engineer, Products & Technologies Operations
> Red Hat