FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 04-24-2008, 09:14 AM
Chris Lumens
 
Default loader/stage2 interaction

> > It may have in the past. It hasn't as long as I've been working on
> > anaconda, which admittedly has only been three years now.
>
> We did long ago, but removed the support due to an extreme number of
> cases where people would only mirror the things they "thought" they
> needed and then end up in a bad place. If we go back to supporting it,
> we need to add some significant checking to ensure that the packages are
> there in advance

Ugh, okay. So then we're in the situation where the repo metadata
refers to (potentially) tons of packages that don't exist. You know, if
the stage2 also contained createrepo we could just rebuild the metadata
on the hard drive partition and.... wait, no, bad idea.

Realistically we could be in the same position with NFS installs as
well. However I bet a lot more people would do HD installs than NFS
installs so we are probably setting ourselves up for real problems here
if we re-enable this.

I'm not attached to the idea. It just seems like we've already got all
the code in place to do it.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 09:15 AM
Chris Lumens
 
Default loader/stage2 interaction

> > That's an interesting idea. What about having two sets of media
> > (iso's), one that contains stage#2 and packages, and another that's just
> > used to get you to the "Method selection screen"?
> >
> > This sounds familiar (aka boot.iso). The difference here being we would
> > never prompt you if you booted from DVD or disc1. Would this make
> > things simpler?
>
> Unless you pass 'askmethod', we never prompt you for a method when
> booting from DVD or disc1.

And booting from the full DVD or disc1 and adding askmethod is just
weird, man. I wish we could stop supporting so many unusual things.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 09:20 AM
Chris Lumens
 
Default loader/stage2 interaction

> > - We shouldn't leave the repo mounted at the end of loader.
> >
> > Problem: RHupdates/ will no longer work.
>
> How frequently do folks use RHupdates these days? If recent memory
> serves, I've been using nothing but updates.img's for all http, ftp, and
> nfs installs.

I'll be honest, it's typically the easiest thing for me to do so I use
it quite often. On the other hand, making an updates.img and tossing it
on a website is really simple too.

I think we could make RHupdates work in a world where nothing is mounted
at the end of loader, but only if we are all convinced we should keep
this feature. It wouldn't take much to convince me. I think updates=
is a really flexible option that's not tied to a single installation
method, and I like that.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 10:14 AM
Chris Lumens
 
Default loader/stage2 interaction

> > - 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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 10:23 AM
Chris Lumens
 
Default loader/stage2 interaction

> Another problem I can see right now:
> boot off CD/boot.iso and perform a network install. Useful in cases where:
> no PXE available, ISOs not mirrored - only packages

You can do this now by adding 'askmethod' to the cmdline parameters.

> The stage2= needs a repo= cousin (or ks.cfg) so we can use any compatible stage2
> with any compatible repos.

I think Jeremy's talked about this a little in the past but I don't
remember what decision was reached. Also we haven't even begun to
consider the implications of stage2= vs. method= for kickstart. Right
now there's just the url/cdrom/nfs/whatever command to give the method.
Perhaps that should be converted into a way to specify the stage2 image
and the repo command should be used to specify the installation source?

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 10:35 AM
Chris Lumens
 
Default loader/stage2 interaction

> 1. Look at local media (floppy, usb, ??) for a ks file. If one is found,
> use it. By way of reference to another authority, this is what Windows
> does.

I don't really like the idea of making kickstart file use quite this
automatic. We've already got ks= that's easy to toss into PXE boot
arguments and so forth. I suppose we could do some work on making it so
that ks=floppy automatically probes for a floppy drive, etc. though.

> A sane value for filename might be the install URL, or the ks file. Use of
> other information such as log-servers, time-offset and ntp-servers would be
> beneficial (the filesystem would have correct timestamps that really
> reflect the time of the install).
>
> Implementation of one or both of these would mean that users could do
> automatic installs with standard media, without having to key potentially
> long and fairly meaningless strings of data such as the URL to an install
> server.

I'm all for making these sorts of things more automatic, however. Would
you believe me if I said we are already at least partially using values
out of DHCP for the kickstart file location:

http://git.fedorahosted.org/git/?p=anaconda.git;a=blob;f=loader2/nfsinstall.c#l400

There's probably a lot more we can do there, though. I don't think this
area has seen much activity at all lately.

As for using the other DHCP values like for ntp-servers, I'll have to
defer to David for how easy that might be. I'm not really familiar with
the DHCP side of things.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 11:40 AM
Chris Lumens
 
Default loader/stage2 interaction

>> - 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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 11:59 AM
Alexander Todorov
 
Default loader/stage2 interaction

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Chris Lumens wrote:
|> Another problem I can see right now:
|> boot off CD/boot.iso and perform a network install. Useful in cases where:
|> no PXE available, ISOs not mirrored - only packages
|
| You can do this now by adding 'askmethod' to the cmdline parameters.
|
|> The stage2= needs a repo= cousin (or ks.cfg) so we can use any compatible stage2
|> with any compatible repos.
|
| I think Jeremy's talked about this a little in the past but I don't
| remember what decision was reached. Also we haven't even begun to
| consider the implications of stage2= vs. method= for kickstart. Right
| now there's just the url/cdrom/nfs/whatever command to give the method.

| Perhaps that should be converted into a way to specify the stage2 image
| and the repo command should be used to specify the installation source?
|

Sounds perfect to me. stage2 + repo.

- - Alexander.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFIEHYwhmd3WOiFct4RCqW0AJ9mm40pqLBkwJkE+Zg4W3 Vyr3n+4ACfV5tV
O7p8WX26kBdNu5yyGO3w8vY=
=4zFb
-----END PGP SIGNATURE-----

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 12:28 PM
James Laska
 
Default loader/stage2 interaction

On Thu, 2008-04-24 at 05:20 -0400, Chris Lumens wrote:
> > > - We shouldn't leave the repo mounted at the end of loader.
> > >
> > > Problem: RHupdates/ will no longer work.
> >
> > How frequently do folks use RHupdates these days? If recent memory
> > serves, I've been using nothing but updates.img's for all http, ftp, and
> > nfs installs.
>
> I'll be honest, it's typically the easiest thing for me to do so I use
> it quite often. On the other hand, making an updates.img and tossing it
> on a website is really simple too.
>
> I think we could make RHupdates work in a world where nothing is mounted
> at the end of loader, but only if we are all convinced we should keep
> this feature. It wouldn't take much to convince me. I think updates=
> is a really flexible option that's not tied to a single installation
> method, and I like that.

Yeah, good points. At the risk turning into a "my favorite method
is ..." discussion, the updates.img's lend themselves well as a
"package" for collecting a set of one or more fixes and distributing
them to consumers. Additionally, write access to the installation
source isn't always available (mirrors, netapps etc...).

If you're looking to reduce code paths, you have one vote for dropping
RHupdates and relying solely on updates= and
os.path.isfile("images/updates.img").

Thanks,
James

> - Chris
>
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list
--
==========================================
James Laska -- jlaska@redhat.com
Quality Engineering -- Red Hat, Inc.
==========================================

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 12:49 PM
Jeremy Katz
 
Default loader/stage2 interaction

On Thu, 2008-04-24 at 05:20 -0400, Chris Lumens wrote:
> > > - We shouldn't leave the repo mounted at the end of loader.
> > >
> > > Problem: RHupdates/ will no longer work.
> >
> > How frequently do folks use RHupdates these days? If recent memory
> > serves, I've been using nothing but updates.img's for all http, ftp, and
> > nfs installs.
>
> I'll be honest, it's typically the easiest thing for me to do so I use
> it quite often. On the other hand, making an updates.img and tossing it
> on a website is really simple too.
>
> I think we could make RHupdates work in a world where nothing is mounted
> at the end of loader, but only if we are all convinced we should keep
> this feature. It wouldn't take much to convince me. I think updates=
> is a really flexible option that's not tied to a single installation
> method, and I like that.

RHupdates is from the days before updates= and our flexibility there.
The more I think about it, the more I think that its time is past

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 11:48 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org