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
