Hi, > msivak, can you expand on why we need these elements interactive? Well, - automatically detected driver discs have to be confirmed before loading (#570053) - we support network method for getting driver discs, so we might need something to let the user set the network up - right now we allow the user to manually select driver update disc or it's image to load. Sources include USB, hard drives, ... That requires some kind of interactivity. Martin ----- Original Message ----- > 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 > _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
