> 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). Driver disks may require an interactive element, but can't that just be another screen in anaconda proper? We're already going to have network bring up UI there (as well as cmdline handling in dracut), as well as language and keyboard. It seems to me that we could just toss in another screen at an appropriate place in the UI. Note - likely not an F17 thing. > 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. Right now, if we can't find an install source and the user didn't tell us anything, we hit the Fedora mirror list and use the first out of there. askmethod-like functionality is probably required, but should be done in the UI as well. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
