loader/stage2 interaction
 

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.
- 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.
- Support configuration from UI, cmdline, and kickstart.
- Configure and bring up the network if required for a method.
- DVD/CD should prompt for media check.
- Each method implies certain locations for updates.img, product.img,
etc. that are checked for automatically.

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?

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

Problem: RHupdates/ will no longer 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.
- 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.

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.

- Chris

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

loader/stage2 interaction
 

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

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.
| - 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.
| - Support configuration from UI, cmdline, and kickstart.
| - Configure and bring up the network if required for a method.
| - DVD/CD should prompt for media check.
| - Each method implies certain locations for updates.img, product.img,
| etc. that are checked for automatically.
|
| 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?
|
| 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.

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

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

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

iD8DBQFID0y/hmd3WOiFct4RCg8+AJ4hryL/lvRbCfKHp/qS7T2U/qchYgCgtgGe
2+2elNYt0y1fPf8HuF874PU=
=HOtR
-----END PGP SIGNATURE-----

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

loader/stage2 interaction
 

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.





--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

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

loader/stage2 interaction
 

Chris Lumens wrote:

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

Small is good, but which specific memory requirements are we talking about?

If execution-time address space, then "ldd anaconda-runtime/loader/loader" shows
linux-gate.so.1 => (0x00110000)
libnewt.so.0.52 => /usr/lib/libnewt.so.0.52 (0x00c6c000)
libslang.so.2 => /usr/lib/libslang.so.2 (0x00cbb000)
libz.so.1 => /lib/libz.so.1 (0x00ca5000)
libpopt.so.0 => /lib/libpopt.so.0 (0x00a83000)
libdhcp-1.99.so.1 => /usr/lib/libdhcp-1.99.so.1 (0x00de3000)
libnl.so.1 => /usr/lib/libnl.so.1 (0x0016d000)
libdhcp4client-4.0.so.0 => /usr/lib/libdhcp4client-4.0.so.0 (0x001be000)
libdhcp6client-1.0.so.2 => /usr/lib/libdhcp6client-1.0.so.2 (0x00db1000)
libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x009c2000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00c87000)
libsepol.so.1 => /lib/libsepol.so.1 (0x00986000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00a4b000)
libm.so.6 => /lib/libm.so.6 (0x00c3a000)
libc.so.6 => /lib/libc.so.6 (0x00acf000)
libdl.so.2 => /lib/libdl.so.2 (0x00c65000)
/lib/ld-linux.so.2 (0x00aaf000)
which suggests that several of those libraries might be used with
explicit dlopen()/dlclose() for various phases. There is also a style
which uses a chain of execve() to handle various phases,
or even "code overlays" where the .text begins with a new main() from
a new file, but the .data+.bss+.stack remains the same.
If swap space is available, then a series of processes connected via
pipes can reduce the minimum RAM required.

If media storage space, then anaconda-runtime/loader/loader
does not use compression of the executable itself. "upx --lzma"
reduces it from 237904 -> 84556 bytes, which is a ratio of 0.36.

Is stage2.img accessed dynamically as a compressed filesystem
that is not memory resident? Is all of it uncompressed at once
before initial access?

--

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

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

- Chris

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

loader/stage2 interaction
 

Chris Lumens wrote:



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.


As a user, I'd like to see automatic installations easier. Here are some
ideas I have.
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.


2. Request, and use if supplied, information from DHCP. Vendor Options
are specified - http://www.iana.org/assignments/bootp-dhcp-parameters
see tag 43 - as available for vendors (Red Hat, Fedora, Debian) to
request and obtain information from a DHCP server. Anaconda already sets
the option vendor-class-identifier and I use that to provide a special
range of IP addresses for installation:

class "anaconda"
{
match if substring (option vendor-class-identifier, 0,
8) = "anaconda";

option vendor-class-identifier "anaconda";
}

and
pool {
allow members of "anaconda";
deny members of "pxeclients";
default-lease-time 900;
filename "http://Fedora.demo.lan/5/i386/os/Fedora/";
max-lease-time 1800;
range 192.168.9.170 192.168.9.179;
option log-servers 192.168.9.4;
}

This illustrates how ISC DHCP 3 may be configured to provide information
to Anaconda.


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.



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.


In the case of a ks install, this info could be in the ks file. If DHCP
were used, the DHCP server could be configured to provide the information.






--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

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

loader/stage2 interaction
 

John Reiser wrote:

Chris Lumens wrote:


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


Small is good, but which specific memory requirements are we talking about?


I was thinking ramdisk. If one boots off CD or a hdd or a USB disk,
there's something approaching a real disk (at least) for stage2. If you
want the ability to remove the boot medium, then that has to be stored
somewhere else.


The target disk would be nice, but that's not (reliably) available until
partitioning and filesystem layout is done.




--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

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

loader/stage2 interaction
 

>>> - 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.
>>
>> Small is good, but which specific memory requirements are we talking about?
>
> I was thinking ramdisk. If one boots off CD or a hdd or a USB disk, there's
> something approaching a real disk (at least) for stage2. If you want the
> ability to remove the boot medium, then that has to be stored somewhere
> else.
>
> The target disk would be nice, but that's not (reliably) available until
> partitioning and filesystem layout is done.

Yes, exactly. In the URL installation case, we download the stage2.img
and toss it into /tmp, which is a ramdisk. We only have to do this if
they're booting off the network, as the CD has stage2 on it. It'd be a
lot simpler to just always put the stage2.img into /tmp but that
increases the memory usage for everyone. Right now we're only
increasing the memory requirements for people who are booting off the
network and using URL installs.

The memory usage of stage2 is something around 100 MB. We move this to
the target filesystem as soon as it's available. That now happens to be
before package selection and dependency solving, which is where we
really run into memory troubles.

- Chris

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

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
>
> 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?

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

loader/stage2 interaction
 

On Wed, 2008-04-23 at 16:51 +0000, James Laska wrote:
> 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.

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