----- Original Message ----- > From: "Dan Callaghan" <dcall...@redhat.com> > To: "Jan Stancek" <jstan...@redhat.com> > Cc: "Don Zickus" <dzic...@redhat.com>, "Artem Savkov" <asav...@redhat.com>, > "Prarit Bhargava" <pra...@redhat.com>, > "Jeffrey Burke" <jbu...@redhat.com>, "Hannes Sowa" <hs...@redhat.com>, > "beaker-devel" > <beaker-devel@lists.fedorahosted.org> > 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 <jstan...@redhat.com> wrote: > > Hi, > > > > 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 > short term. > > 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, > > Hannes > > 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 etc. > > 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 - RPMs/repos - 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: <netboot> <vmlinuz>http://...</vmlinuz> <initrd>http://...</initrd> </netboot> + 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 distro - 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) Regards, Jan > > 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 <dcall...@redhat.com> > Senior Software Engineer, Products & Technologies Operations > Red Hat > _______________________________________________ Beaker-devel mailing list -- beaker-devel@lists.fedorahosted.org To unsubscribe send an email to beaker-devel-le...@lists.fedorahosted.org
