Sent on behalf of [email protected] (not subscribed to virt@). -------- Forwarded Message -------- > From: Martin Gracik <[email protected]> > Reply-to: [email protected] > To: [email protected] > Cc: James Laska <[email protected]> > Subject: [Fwd: Re: Lorax F15 composes - buildinstall rewrite] > Date: Tue, 11 Jan 2011 13:05:23 +0100 > > Hello, > > I'm working on the buildinstall scripts rewrite, called lorax, and I > have one issue. The buildinstall scripts generate the .treeinfo file, > which is used by python-virtinst, and that it looks for the [images-xen] > section. > > What I'd like to do in lorax, is that the section name will depend on > the kernel name. If the kernel is a PAE kernel, it's filename will be > kernel-PAE and initrd filename will be initrd-PAE.img (this is the same > in buildinstall), but the section would be [images-PAE] as opposed to > buildinstall's [images-xen]. > > And if a XEN kernel is installed, the filename will be vmlinuz-XEN > (initrd-XEN.img) and corresponding section will be [images-XEN]. > > Will this change cause you any difficulties? > > -- > Martin Gracik <[email protected]> > email message attachment, "Forwarded message - Re: Lorax F15 composes > - buildinstall rewrite" > > -------- Forwarded Message -------- > > From: James Laska <[email protected]> > > To: Martin Gracik <[email protected]> > > Cc: Jesse Keating <[email protected]>, Adam Williamson > > <[email protected]>, Dennis Gilmore <[email protected]>, > > Christopher Lumens <[email protected]>, David Cantrell > > <[email protected]> > > Subject: Re: Lorax F15 composes - buildinstall rewrite > > Date: Mon, 10 Jan 2011 08:58:20 -0500 > > > > On Mon, 2011-01-10 at 08:51 -0500, Martin Gracik wrote: > > > > > > -- > > > > > > Martin Gracik > > > > > > ----- Original Message ----- > > > > On Sun, Jan 09, 2011 at 06:53:38AM -0500, Martin Gracik wrote: > > > > > ----- Original Message ----- > > > > > > On Tue, 2011-01-04 at 16:24 -0500, Martin Gracik wrote: > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Martin Gracik > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > Hi Martin, > > > > > > > > > > > > > > > > Thanks for reaching out on the topic. Exciting to see the > > > > > > > > lorax > > > > > > > > work > > > > > > > > coming into Fedora. > > > > > > > > > > > > > > > > On Tue, 2011-01-04 at 14:29 -0500, Martin Gracik wrote: > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > I'm working on the Lorax project, which is a rewrite of > > > > > > > > > anaconda's > > > > > > > > > buildinstall scripts. It is now in a state ready for > > > > > > > > > thorough > > > > > > > > > testing. > > > > > > > > > The lorax package was already added to fedora and the build > > > > > > > > > is > > > > > > > > > in > > > > > > > > > koji. I have a patch for pungi, and from the tests I did > > > > > > > > > myself, > > > > > > > > > I'm > > > > > > > > > able to create the install images using patched pungi + > > > > > > > > > lorax, > > > > > > > > > and > > > > > > > > > do > > > > > > > > > a successful install with them. I would like lorax to be > > > > > > > > > used > > > > > > > > > for > > > > > > > > > F15 > > > > > > > > > composes if it will be possible. > > > > > > > > > > > > > > > > > > Lorax as of now only supports i386 and x86_64 architectures, > > > > > > > > > so > > > > > > > > > there's a problem with all the secondary archs. I don't know > > > > > > > > > which > > > > > > > > > solution would be better, if the secondary archs should use > > > > > > > > > unpatched > > > > > > > > > pungi, which will still be running buildinstall, or if the > > > > > > > > > patched > > > > > > > > > pungi should run lorax only if the buildarch is supported, > > > > > > > > > otherwise > > > > > > > > > run buildinstall. > > > > > > > > > > > > > > > > > > After we'll have the patched pungi build, we can get the > > > > > > > > > lorax > > > > > > > > > enabled > > > > > > > > > composes to QA and get more testing. > > > > > > > > > > > > > > > > > > I would like to hear your thoughts and comments, if this > > > > > > > > > stuff > > > > > > > > > is > > > > > > > > > your > > > > > > > > > concern. > > > > > > > > > > > > > > > > Has lorax been used to generate and compare F-14 install > > > > > > > > images? > > > > > > > > If > > > > > > > > possible, I think comparing the resulting images might be > > > > > > > > interesting. > > > > > > > > > > > > > > > > Clumens & I just finished up a new autoqa test that runs pungi > > > > > > > > whenever > > > > > > > > a new anaconda koji build is available. The test runs pungi > > > > > > > > inside > > > > > > > > a > > > > > > > > mock chroot and is intended to capture potential compose > > > > > > > > issues > > > > > > > > ahead > > > > > > > > of > > > > > > > > time. Would any changes be needed for this test? Do we want to > > > > > > > > run > > > > > > > > both lorax and buildinstall versions of pungi at the same > > > > > > > > time? > > > > > > > > > > > > > > We're doing rawhide composes with buildinstall and lorax every > > > > > > > day, > > > > > > > and doing diffs between the initrds. I'm trying to get the lorax > > > > > > > composes as close as possible to the buildinstall ones. I don't > > > > > > > know > > > > > > > if you can access this server, but they are here > > > > > > > http://10.34.39.2/trees/lorax/ and > > > > > > > http://10.34.39.2/trees/rawhide/ > > > > > > > > > > > > Ah perfect, thanks for the links. > > > > > > > > > > > > > The diffs are in the lorax directories. I know the format is > > > > > > > strange, I didn't give a lot of thought to the formatting. It > > > > > > > basically has 3 parts: > > > > > > > > > > > > > > 1. missing files from the lorax compose, that are in > > > > > > > buildinstall > > > > > > > 2. diff of text files that are in both composes > > > > > > > 3. files that are in lorax compose, and NOT in the buildinstall > > > > > > > (leftovers), sorted by size and package they belong to (I used > > > > > > > this > > > > > > > part to remove leftover files, so the image is smaller, the ones > > > > > > > that are left now don't take much space, so I'm getting to the > > > > > > > part, > > > > > > > that removing them is not very effective for the maintainability > > > > > > > of > > > > > > > code, so they are still left there) > > > > > > > > > > > > Careful with some of the tree metadata that several tools rely on > > > > > > (virt-install, cobbler/koan to some degree, snake, beaker ...). > > > > > > > > > > > > * lorax - http://10.34.39.2/trees/lorax/20110105/i386/os/.treeinfo > > > > > > * buildinstall - > > > > > > http://10.34.39.2/trees/rawhide/20110105/i386/os/.treeinfo > > > > > > > > > > > > Two issues jump out from comparing the two ... > > > > > > 1. The [images-*] sections appear to be missing from the lorax > > > > > > generated .treeinfo > > > > > > 2. Also, possibly related, the [general] boot.iso option should be > > > > > > moved to [images-$arch] boot.iso > > > > > > > > > > Yes, thanks for catching this, it must have slipped somehow, > > > > > should be fixed now. > > > > > > > > Looking good. One more comment, the lorax generated treeinfo includes > > > > a > > > > section [images-PAE], while the rawhide treeinfo used [images-xen]. > > > > Should > > > > they match, or do we need to inform consumers that the xen images can > > > > be found > > > > under [images-PAE]? Now that I think of it, is xen-guest support in > > > > the > > > > regular [images-$basearch] anyway? > > > > > > Yeah well, what I did in lorax is that, I take the images-<suffix> from > > > the actual kernel name. > > > If the kernel name ends with PAE, we rename it to vmlinuz-PAE, and > > > corresponding initrd to initrd-PAE, > > > so I put it to images-PAE. If the kernel would end with XEN, it would be > > > all XEN instead of PAE. > > > This looks more elegant to me, but I can change it easily to images-xen > > > if it's a problem. > > > > Looking at the source code of python-virtinst, it does rely on the > > presence of [images-xen]. I'd recommend reaching out to > > [email protected] to let them know of the change. > > > > Thanks, > > James
signature.asc
Description: This is a digitally signed message part
_______________________________________________ virt mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/virt
