On 05/07/2015 05:39 AM, Karanbir Singh wrote: > On 05/07/2015 04:54 AM, Ian McLeod wrote: >> >> Some quick further updates here: >> >> I have been unable to generate a working install tree using the current >> mirror content combined with the "cah" repo. The lorax runs complete, >> but the resulting Anaconda fails during installs in one way or another. >> >> I initially hit some python-blivet version mismatch issues. Even after >> fixing these, I end up with an install that hangs when creating the >> initial filesystems. At this point, I attempted to dial back the kernel >> version pulled in by lorax, to match the somewhat older version present >> in the RHELAH installer. This, it seems, is impossible using the >> existing mirror content, which is now irreversibly newer. >> >> If, however, I use the composed ostree generated from the current >> "downstream" branch of the Atomic SIG repo, combined with the Anaconda >> used to generate the SIG images, all is well. Using local runs of Image >> Factory, I've generated a vagrant/libvirt box that boots successfully >> into Atomic and this system contains the "cah" repo packages. To be >> clear, I'm talking about the install tree hosted here: >> >> http://buildlogs.centos.org/centos/7/atomic/x86_64/atomic-anaconda-nightly/latest/ >> > > The included code must have worked, Red Hat did a release based on it :) > > But if in the interim we can get around the blocker by using the > upstream anaconda, lets do that while we go back and figure out what the > problem with the released code is. Sounds good. What is the next step here? At the risk of sounding like a broken record, it would be great to get tree composes onto buildlogs. This will immediately allow me to spin cloud and vagrant image candidates with publicly visible build logs, kickstarts, etc. > > - KB >