>> - Support the following installation sources: http/ftp, dvd/cd, nfs, >> nfsiso, hdiso. It'd also be nice to support regular hd installs. > Think I have that one worked out worked out... ...assuming we even want to do it. See Jeremy's mail later in this thread. >> - Each method implies certain locations for updates.img, product.img, >> etc. that are checked for automatically. >> > Noted.. as in ~/images /tmp /RHupdates? Did I forget any? As far as I can tell, these are the options: - RHupdates for NFS installs only - the images/ subdirectory for URL installs, CDs, ISO images, etc. - the same directory as the ISO images themselves for HDISO and NFSISO - on a floppy if 'updates' is given for all methods - via updates= for all methods Also I think (but I'm not sure) that you can have both an updates image or RHupdates in the tree, and then provide additional updates via updates=. Horrifying. > Take away features? Your asking for trouble here... ;-) Oh I knew that the day I started working on anaconda. Anyway I think that if we're going to talk about what we should do with loader/stage2, we might as well leave everything open to discussion. If there's some really bizarre feature that makes everything else difficult, perhaps we should investigate removing it. > Yea, would be looking to the cd for the updates. A screen that asks if > you want to check for updates? If yes, enable the the network and check > the fedora mirrors for the updates.img and product.img that may exist in > ~url/images. The check could entail the main repo or maybe the updates > repo. If updates repo, if chosen by fedora as the spot for their home, > then enable that repo for the rest of the install would be a nice touch, > install and update at first install. I think we're mixing up our terms here. When you say "updates repo", are you referring to the repository of packages made available after a release is made? If so, that's a totally different discussion that I think is also worth having, but we should move to another thread. On the other hand if you mean an updates.img that patches possible bugs in anaconda (which is what I've been referring to throughout this mail - sorry for any confusion) then I don't like the idea of asking the user if they want to check. I'd rather we continue to do what we're doing - have the user provide a cmdline argument in addition to us automatically looking in a few locations. Will Woods also likes the idea of making available a well-known URL that anaconda could automatically check (like http://www.fedoraupdates.org/<arch>/<release>/updates.img, for instance). I don't think I would do this automatically either, but maybe use the 'updates' or add 'updates=auto' to trigger that behavior. I can see there's going to be a lot of talking about updates images. Since we are absolutely going to be preserving this behavior in our loader rework, perhaps it's worth moving all that off into a new thread anyway. >> - We shouldn't be checking if the inferred repo is valid in any way, >> perhaps except that we can at least mount it (if the method requires >> that). This requires making the repo editor in stage2 more useful. >> It also separates the loader from the payload it's installing more. >> In particular, any remaining .discinfo checks ought to die. > That is a PITA IMHO, yes please... Good. I don't think this is going to be one of the controversial points then. >> - We shouldn't leave the repo mounted at the end of loader. >> > > Can you expand on why that is needed? Sure. Our plan for loader is this: "Right now, the loader downloads the stage2 image and sets up the installation repo. Instead, loader should only grab the stage2 image and save the repo setup for later." Why would we want to do this? Well, moving stuff out of loader has its benefits. First it's easier for us to program, test, and debug if the code is in python. Second, it's possible for us to provide updates images to fix bugs in this area if we move it to python. That's not currently possible since it's in the loader. Third, because it's easier to program and test, we can come up with interesting new features quicker. >> Problem: RHupdates/ will no longer work. > Think that still might work, that gets copied to /tmp early in the > loader when validating /mnt/source. Yep, I think we have a handle on this one. >> Problem: This increases the memory requirements, > > That one kills low resource machines. I'm not in favor of that. I think Jeremy has a good handle on this one too. > Then in the future(not right now), with the early mount of stage2, you > could make tty2 available much earlier than it is now. I'm not sure how much earlier we can do it, but I'm all for investigating. Only somewhat relatedly, I'm going to be investigating adding a hook for running gdbserver during the loader. The idea here is that if you provide a second initrd with gdbserver in it, loader will detect that and run it in case of emergency. Then we have better debugging capabilities without adding lots of code that everyone ends up running. You know, since you mentioned debugging and all... > Yes, there would an issue when checking for the hdiso, nfsiso installs with > this idea, when testing for the iso, the test uses the same loop device as > what would be already in use for stage2. That could be fixed with an > unmount before the test or change the test loop device (wow, that is a > bunch easier now that I think of it). What would be a safe loop device to > use? I could dig, but someone should know. > > I think for a cd/dvd the current code would be fine. > > I've been playing around with that, got some of the code done. I'll re-sync > with the current git and see what I might come up with. > > Need some feedback, and I'll post some "rough work" patches to get some > more feedback. Sorry, I won't have any time till Friday to throw at this. Other people may differ with me here, but I would really rather just destroy all the code we've got in *install.c and start over. I think it's really quite a mess and starting with blank files might yield better results. I guess we wouldn't totally wipe out the contents. I'm sure there's some good stuff in there. But you get my point. If that's the approach we want to take, perhaps a better use of your time would be to start thinking about how you would design the code instead of trying to beat the existing stuff into shape. You certainly seem motivated to work on this area, so I'd hate for you to do a lot of work only to make it no longer apply by starting from scratch. Opinions? - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
