On Thu, 2011-11-17 at 16:53 -0500, David Cantrell wrote: > > 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). Why do they require an interactive element? What input is needed? Device name? Filename? Why wouldn't boot args plus default device/filename suffice? e.g.: If you pass 'dd', we'd look for a file named "drivers.img" on a device labeled "RHUPDATES". If you actually need to use different label/filename you could do: 'dd=<device>:<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. Possibly? This prompt would only come up if you don't boot from media - i.e. only on netboot. If you've already set up the netboot server.. couldn't we just use a sensible default, again? Like, if nothing is passed for 'repo=' or 'root=', try a few URLs: http://<server-ip>/<client-ip>/install.img http://<server-ip>/<product>/<arch>/<version>/os/images/install.img Maybe even: http://download.fedoraproject.org/pub/fedora/linux/releases/<version>/Fedora/<arch>/os/images/install.img It's kind of like PXE - if there's no files for the system to PXE boot, you don't get a PXE prompt saying "hey what files do you want to load?". It's already a pretty specialized environment - just set up the server properly and it'll work fine. Or, if you want to make things simpler, you can just cram install.img into the initrd.img. Then you don't need to set up the network etc. to find it. > 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. Sure, but again, this is only needed if you're doing netboot. All the simple cases already work (ip={dhcp,dhcp6,auto6}). Most netboot setups seem to automatically set up the boot commandline anyway. Is it easier/necessary to have us maintain a super-limited pre-stage2 interactive UI than to have better docs on setting up netboot environments? > 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? I can definitely understand that this is Required for some Business Use Cases, but I don't fully understand the actual requirements. So yeah, where can we get more info about who uses this, and how, and why, and what they need? -w _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
