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