Chris Lumens wrote:
- 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.
I'll just keep it for myself then, but sure makes testing easier,
remount rw and I can copy the log/dumps somewhere.
- 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.
I like /RHupdates, I used that with the livecd install from anaconda
hack from while ago, for the same reason I like the straight HD non-iso
option, ease of testing.
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.
Sorry, run on thought.. both...
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.
Yes, for sure, updates=auto, setup the fetch from a URL. That leads to
the question, where should this image live? I'm in favor of having
updates.img live in the updates repo. Then that same trigger could be
used to enable the update.repo later in the install.
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.
I'm suggesting the use of the updates repo for the URL, as that is the
one that would be sync'd by advanced users, to keep things updated in
their home mirrors. Once I download the original tree for a release, I
don't try to re-sync that one, the content shouldn't change, that is
what updates repo is for. A new thread would be the best, I'll leave any
more talk for that one.
- 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.
OK, should I be thinking that stage2= will be the replacement for
method= for stage1? I'm getting that feeling, just want to be sure.
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.
Right after the mount of stage2 would be nice, bash is now there.
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...
Sounds interesting, how would you go about the second initrd.img? Just
in general, a pointer to a wiki page would be enough for me.
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.
I'm getting the feeling that if it's not an iso type of install, then
support for the that which maybe used for a custom tree on a hard drive
or via nfs is unwanted. I understand that from a support point of view,
just that limits outsiders(me) from playing around with the install
tree. Having to do a re-make of an iso for something like testing
changes to comps.xml makes me a bit ill. Could just be a "use at your
own risk / unsupported" option with the patches welcome warning... Guess
I'll just use net based installs to test my custom repos then.
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
I suppose I'll have to get used to using just the updates.img, that does
have support for using of a custom comps.xml file for the anaconda repo?
That, and the repo editor would make a great tool. Sorry, I have not
kept up with that part of the code, or can the repo editor make use of a
custom comps.xml file? I toggle some of the default/options, or does
that fall under unsupported?
Jerry
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
