Chris Lumens wrote:
I think everyone's familiar with the mess that is prompting for the
method in loader and fetching the stage2 image. It's too late to do
anything for F9 besides patch the bugs, but it's time to start thinking
about what to do for F10. So, let's start thinking about it.
The way I see it, the loader currently does the following things
regarding setting up the method:
- 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...
- If stage2= is given, use that as the stage2 image.
- If there's a CD in the drive and there's a stage2 image on it, use
that. stage2= overrides this.
That is do-able..
- Support configuration from UI, cmdline, and kickstart.
- Configure and bring up the network if required for a method.
Or if ks= or updates= are passed and need the network...
- DVD/CD should prompt for media check.
- 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?
Those are the current features, best I can see. Are there any of these
features we want to do away with? Does anything no longer make sense?
Take away features? Your asking for trouble here... ;-)
Now for the more controversial stuff. Here's what I would like to see
happen in this area for F10. All these things are open for discussion,
so jump right in.
- There shouldn't be any differences between booting off the network and
booting off media.
- 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
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.
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.
- 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...
- We shouldn't leave the repo mounted at the end of loader.
Can you expand on why that is needed?
Problem: RHupdates/ will no longer work.
Think that still might work, that gets copied to /tmp early in the
loader when validating /mnt/source.
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.
- Part of the last one... we should copy the stage2 image out of its
initial location. My reasoning for this is still that it makes
error handling easier when the repo has trouble. This requires
making the repo editor more useful too.
Problem: This increases the memory requirements,
That one kills low resource machines. I'm not in favor of that.
Your thoughts? Once we at least have some concept of what should be
going on, I can get started on working on a code design - hopefully one
that removes a lot more than it adds.
There is the "findAnacondaCD" call in loader.c that will try to mount
the "anaconda iso". It is one of the first things loader does, that
would be the best place to do /mnt/stage2 across all installs when the
boot.iso is found. Check first /mnt/source with requirepkgs=true, if
met, use that. Then if that fails, try mount at /mnt/stage2 with
requirepkgs=false. Guess you'd need to check for stage2= flag first
before the above test. Does that make sense?
Then in the future(not right now), with the early mount of stage2, you
could make tty2 available much earlier than it is now.
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.
Jerry
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
