Chris Lumens wrote:
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.
The updates repo isn't guaranteed to contain the entire package set,
though. It's just going to have packages that have published updates
since the final release. So we can't really use the updates repo for
the URL.
This would be just a default place to look for the availability of the
latest, just one file, updates.img, if booted with "updates=auto",
updates=/path would work as now, which is what rawhide could use. The
updates.img is just a patch to what is on the boot.iso, it wouldn't need
the whole (any?) rpm set, the users' choice of method/media would still
be retained/used. How does/would fedora infrastructure deal with having
the primary repo updated? I recall the 586 issue that just passed, a
revised stage2 could not be (or didn't get) deployed, you had to wait
for a "respin", with no revised boot.iso being released at all. I
thought that was the idea behind the updates repo, the latest code for
that release is in one area.
What I'd really like to do is have a checkbox in the repo selection UI
(tasksel.glade in case you're curious) that enables the updates AND
check that box by default. I know we've threatened this in the past.
I like that, would be the same as passing repo=updates=path as a repo in
a kickstart file, updates without rebooting.
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.
Yes, though not really a complete replacement. The final goal is that
stage2= points to just the stage2.img file, while method= points to just
the package repository. Perhaps at that point we rename it to repo= to
avoid confusion? Don't know quite what to do here yet.
/wish list
Maybe stage2.img and related boot.iso could just be moved to the updates
repo all together. The boot.iso could then be updated, containing the
latest changes that lead to the need for a updates.img in the first
place, as required. Now you really have disconnected the location of
stage2 from the primary repo.
wish list/
Back to what is required now in loader, The boot.iso is mounted for
stage2, if present, else look for an iso-image to use for stage2 for
nfsiso, hd(iso), or tree-path for nfs. That just leaves net installs,
where what you're really being asked is for the location of stage2 and
not the location of a repo in stage1. Anaconda should then discard the
net install's method-path, but not method, that is passed from loader
when building its own repo list with data supplied from a kickstart file
and/or the repo editor.
Does that sum up what maybe required here? Think all the *install.c
files could become just one install.c file here. Is that what I should
work towards?
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.
If you PXE boot, you can specify multiple initrd lines and they'll all
get combined together to work. I'd just make a second initrd containing
gdbserver and add a new target for booting with it.
For other booting methods, I don't know right now. I'm sure we can
figure something out for CDs and the like.
Something new to play with in time.
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.
Hm, no, it's not my intention to remove all the support for customizing
ISO image installs. I do want to keep around the implicit updates.img
locations so you don't have to rebuild images, as I agree that's a
total pain. We just need to think up good ways to support these
customizations without creating a giant mess.
I know you don't want to kill off the iso installs, you want to kill off
the NON-iso installs. If you keep thinking that the primary repo/mirror
should have the updates.img, it becomes harder to kill off non-iso
nfs/hd installs. My thinking would be if I could copy the content of my
dvd somewhere for nfs/hd and add the newest updates.img, it should just
work, and be supported. You have provided the complete tree, the same as
if your were to setup a net install, IMHO.
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?
Yeah, probably best to get used to using updates.img.
You're looking to have a new comps.xml file in the updates.img that
overrides the one in the installation repo? I don't think we support
that in RHupdates or updates.img right now. Anyone else want to take a
stab at answering this part?
Yes that is what I had in mind, override the one in the installation
repo. For your own use it is just so easy to edit the comps.xml file,
then run createrepo, for a custom non-iso nfs install source without
having to jump thought the "respin" hoops. But it looks like non-net,
non-iso sources are going away, sad, IMHO.
As for the modified repo editor... I'll be posting my UI mock up for
that later today I think. I want to make sure the list stays lively,
after all.
- Chris
Have not had a chance to look yet.
Just my 2 cents,
Jerry
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
