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-23-2008, 06:57 PM
James Laska
 
Default loader/stage2 interaction

On Wed, 2008-04-23 at 10:32 -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.

Thanks,
James
--
==========================================
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-23-2008, 07:12 PM
Jeff Bastian
 
Default loader/stage2 interaction

On Wed, 23 Apr 2008, James Laska wrote:

On Wed, 2008-04-23 at 10:32 -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 use it on occasion when debugging something in anaconda. It's a bit
faster than spinning an updates.img.


Jeff

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

On Wed, 2008-04-23 at 14:12 -0500, Jeff Bastian wrote:
> On Wed, 23 Apr 2008, James Laska wrote:
> > On Wed, 2008-04-23 at 10:32 -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 use it on occasion when debugging something in anaconda. It's a bit
> faster than spinning an updates.img.

I said that for a while, but now that we can have updates.img being a
cgz, I'm less convinced.
find $foo |cpio -H newc -o |gzip -9 > updates.cgz
is pretty straightforward and no more difficult really. The problem
with the filesystem images was always having to be root

Jeremy

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

On Wed, 2008-04-23 at 16:51 +0000, James Laska wrote:
> On Wed, 2008-04-23 at 10:32 -0400, Chris Lumens wrote:
> > - 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.
>
> Caveat: Thinking out loud ... insanity likely.
>
> 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?

This sounds pretty much exactly like what we have now...

Jeremy

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

On Wed, 2008-04-23 at 11:18 -0400, 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.
> >
> > It doesn't? I'm sure I did one or two, back before hdiso was invented. RHL
> > 7.x.
>
> 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

Jeremy

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

On Wed, 2008-04-23 at 10:32 -0400, Chris Lumens wrote:
> - 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

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.

> 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

> - 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.
> - We shouldn't leave the repo mounted at the end of loader.

Sounds reasonable.

> 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

> 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

> - 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, 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.

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 02:05 AM
Jerry Vonau
 
Default loader/stage2 interaction

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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 02:21 AM
Jesse Keating
 
Default loader/stage2 interaction

On Wed, 2008-04-23 at 21:44 -0400, Jeremy Katz wrote:
>
> I said that for a while, but now that we can have updates.img being a
> cgz, I'm less convinced.
> find $foo |cpio -H newc -o |gzip -9 > updates.cgz
> is pretty straightforward and no more difficult really. The problem
> with the filesystem images was always having to be root

OOoh, http://fedoraproject.org/wiki/Anaconda/Updates should be updated
with that method. I've been doing the sudo mount, copy, umount dance
for a bit now and it's tedious.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 02:33 AM
Jeremy Katz
 
Default loader/stage2 interaction

On Wed, 2008-04-23 at 22:21 -0400, Jesse Keating wrote:
> On Wed, 2008-04-23 at 21:44 -0400, Jeremy Katz wrote:
> >
> > I said that for a while, but now that we can have updates.img being a
> > cgz, I'm less convinced.
> > find $foo |cpio -H newc -o |gzip -9 > updates.cgz
> > is pretty straightforward and no more difficult really. The problem
> > with the filesystem images was always having to be root
>
> OOoh, http://fedoraproject.org/wiki/Anaconda/Updates should be updated
> with that method. I've been doing the sudo mount, copy, umount dance
> for a bit now and it's tedious.

It's a wiki... :-P

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 04-24-2008, 07:21 AM
Elliot Peele
 
Default loader/stage2 interaction

On Wed, Apr 23, 2008 at 09:44:41PM -0400, Jeremy Katz wrote:
> On Wed, 2008-04-23 at 14:12 -0500, Jeff Bastian wrote:
> > On Wed, 23 Apr 2008, James Laska wrote:
> > > On Wed, 2008-04-23 at 10:32 -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 use it on occasion when debugging something in anaconda. It's a bit
> > faster than spinning an updates.img.
>
> I said that for a while, but now that we can have updates.img being a
> cgz, I'm less convinced.
> find $foo |cpio -H newc -o |gzip -9 > updates.cgz
> is pretty straightforward and no more difficult really. The problem
> with the filesystem images was always having to be root
>

cramfs works as well. Any user can run mkcramfs.

Elliot

--
Elliot Peele
rPath, Inc.
elliot@rpath.com

_______________________________________________
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 05:20 AM.

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