On 11/22/2011 06:49 AM, Martin Sivak wrote:
I have three pieces which have to work:
them are obviously less important (nousb, noprobe)
Look at rhbz#690058, noprobe is very important for a big partner there
And it is related to what David said:
- Driverdiscs have to be supported.
- Networking has to be supported (for install source and for getting the driverdisc).
- Some interactivity has to stay there also for these features to work and be usable..
What is the reason we need these elements interactive in loader? The
only thing I can remember is that some vendors ship internal USB flash
drives with drivers embedded, and users may or may not want to install
those drivers at install time. So looking for and automatically loading
all found drivers on driver disks is not ideal in that case.
msivak, can you expand on why we need these elements interactive?
Syslog arguments are useful for debugging, we use it to start remote logging from anaconda. Also Gdb was used couple of times here in Brno, remote debugging is a nice feature to have (less important if there is no C code in anaconda..).
Martin
----- Original Message -----
On 11/17/2011 01:33 PM, Will Woods wrote:
Courtesans and gentlefops! May I direct your attention to:
https://fedoraproject.org/wiki/Anaconda/Features/NoLoader
In particular, please note the Scope section, which might also be
titled
the Big Damn List Of Stuff To Do.
The short summary is: Yes, we're really trying to remove loader
this
time, for real. And it's gonna take some work. So I'm looking for
advice
and assistance in the following areas:
== Boot Option Priorities ==
Some of these things (ks=, lang=, ip=) are obviously important;
some of
them are obviously less important (nousb, noprobe), and some of
them I'm
just not sure if anyone uses them (gdb=, syslog=, wepkey=).
If you (or someone you know) depends on any of these things, please
give
us some information on how and why you use them, so we can make
sure
things work as expected - and get your help with testing!
== Porting to Dracut ==
Some of these things will probably end up in upstream dracut (e.g.
network stuff can go in the 40network module), but a lot of things
will
end up in our own special dracut module (80anaconda).
I'll need some assistance getting all that done for F17, so if
you've
got some bash skill and want to help with dracut development, this
is a
perfect place to help make a difference in the quality and
stability of
the next release! Let me know if you can help, so I have some idea
how
many people may be involved (and set goals/deadlines
appropriately).
== General Sanity Checking ==
Does this plan look sound to everyone? Can we all agree that
dropping
the stage1 interactive stuff is sane (remember, we'll still have a
text-mode installer in the anaconda runtime - just no more dialogs
in
initrd.img)? Is there anything missing, any improvements you could
suggest?
Once we've got a finished plan of attack, I might take this to
devel-list just to be sure they're all aware (and see if we can
solicit
further info/assistance).
Some things that we need to come up with a solution for (where
"solution" means either keeping something on our own still called
/sbin/loader, or a dracut module, or something else that is run
inside
the initramfs):
1) Driver update disks require an interactive element at boot time.
Doing that once anaconda is not really possible since we may need
that
driver to get anaconda. A dracut module is fine, but we do need to
keep
some level of interactive element. NOTE: It does not have to be an
ncurses interface, but something interactive so that users do not
have
to pass long boot options (well, we will probably want that, but we
should also have an interactive path).
2) Install method... if we can't find an install source and the user
didn't tell us what to use, we prompt in loader. Are we planning to
do
that via the 80anaconda dracut module? I would say this is important
as
well.
3) Some sort of minimal interactive network configuration may be
required, again so users are not solely restricted to passing boot
parameters to dracut. Not sure if this is planned or not.
Really, the important one to me is the driver update disk support and
retaining that functionality. It's complex enough that we may even
want
a separate dracut module just for the driver update disk support
(79dud?). msivak?
--
David Cantrell<dcantrell@xxxxxxxxxx>
Supervisor, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
--
David Cantrell <dcantrell@xxxxxxxxxx>
Supervisor, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
