> > - loader should be moving to just doing what is required to fetch and > > mount the stage2 image. This can perhaps include inferring an > > installation repo based on the location of the stage2 image, but the > > I wouldn't so much say that the loader would infer the installation repo > location. But that information on where stage2 came from is available > to stage2 and then we can do munging in stage2 to suggest a repo based > on that. Or upon a mirrorlist or the like. I like this even better because it involves moving stuff out of loader. We already have the information about where stage2 came from thanks to the -m <whatever> argument to anaconda. Doesn't seem like there's a whole lot to do here. I might still like to pre-populate the URL box in loader with the mirrorlist, but I haven't thought about how to do that without hardcoding values. > > Problem: If the user booted off a CD and we don't have any method > > configuration screen, the implied updates.img and product.img checks > > will never work. > > The implied updates.img should map to the stage2 location more than the > repo I think. product.img needs some more thought, though updates.img: Sounds good. Anything that decouples loader from the installation payload sounds good to me at this point. product.img: What prohibits us from doing the same as with the updates.img? The two are arguably really about the same thing - making modifications to the stage2 image. The product.img just modifies the available installclasses. That's still modifying anaconda's source files if you think about it. > > Problem: RHupdates/ will no longer work. > > We could just copy the contents of RHupdates to /tmp/updates just like > we do with an updates.img That should work. > > Problem: This means both loader and stage2 will have to have some > > code for mounting installation sources. This probably isn't such a > > big problem because stage2 will already require it for error > > handling. > > Arguably, we could just not mount the install source at all from the > loader and just have it always done in stage2 If the stage2 is on NFS or HDISO, we'll still have to have the code to handle those in the loader. That's what I was referring to. On the other hand if you're proposing the stage2.img cannot be on either of those methods... > > Problem: This increases the memory requirements, which no one likes. > > If we have things disconnected, there's no reason we can't have the same > thing mounted more than once. So we could have the source for stage2 > mounted at /mnt/stage2 (as you've already started down the path of) and > then we should be able to failover with repo problems. Hm yes, that probably would work though it has the potential to be a little tricky. Worth looking into, certainly. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
