Hi Will, > I may have been unclear here - what I'm concerned about is whether we > need *user-facing* interactive elements. We support manual driver disc selection: You have a hard drive with dd.iso and right now can select disc, partition and file to load. > Or we need to be able to re-initialize after loading the driver > disk. I'm pretty sure that's easy to handle for network > drivers.. not sure about storage, but I don't think it's > impossible. To be exact, we have to be able to unload all network and storage drivers and instruct udev to load them again. Unloading just storage and network supposes we know which modules are network and storage.. that is why we currently save a list of modules loaded before loader and restores to that state (no guessing that way..). > 1) DD support needs to be in dracut if (and only if) there are > supported install cases where dracut must load a driver disk > before it will be able to load install.img. Network install and new unsupported scsi/cdrom/blade controllers are the main reasons. And PPCs still have the 32MB limit during PXE initrd download. 2) We need a driver disk before loading install.img if (and only > if) there are devices that can hold/fetch the DD, but not > install.img. Sure, DD on usb key is the only thing we can be almost sure works. Install.img on network or new unsupported hardware are common cases and the reason we update drivers that early. This all are cases I have to solve. Unless we use single image dracut+install.img and the firmware is able to load it. Can we be sure this will always work (100% and no exceptions)? Because if not and we have to use two stages on some obscure machine, the feature would be useless there (too late..). We are talking about hardware which is yet to be invented and I do not want to limit ourselves. I can simply do much more before install.img starts. Martin ----- Original Message ----- > On Fri, 2011-11-18 at 17:05 -0800, John Reiser wrote: > > >> 1) Driver update disks require an interactive element at boot > > >> time. > > [snip] > > > > > Why do they require an interactive element? What input is needed? > > > Device > > > name? Filename? > > > > For me, the interactive element is for diagnosis and recovery from > > errors. > > I may have been unclear here - what I'm concerned about is whether we > need *user-facing* interactive elements. > > Diagnosing and debugging problems is a *developer* problem, > generally. > We can easily have a nice (English) error messages and bash/readline > interactive UI for error recovery - with the default (us) keymap[1]. > I > have no problem with this stuff. > > On the other hand, I feel we have a responsibility to properly > translate > and localize *user-facing* UI elements. Which requires us to have > further UI to pick the language and keymap. > > Most install cases (CD, DVD, Live USB, etc). will not require any > user-facing UI in initramfs - they'll immediately load stage2 and be > merrily on their way. PXE and other netboot scenarios should do the > same, unless the server is misconfigured[2]. > > Basically: I understand that you, as a developer, want interactive > debuggability. That's cool, I want that too. > > But do we really expect normal users to have to deal with > unrecoverable > errors (e.g. misconfigured netboot servers) *so often* that we should > write an entirely new language/keymap picker just for that? I'm not > so > sure. > > -w > > [1] This seems to be accepted practice for Linux development - the > bootup messages, for instance, are all in English. No translations. > > [2] Also note that configuring a PXE server can be done on a system > that > will have the proper local language/keymap, using translated > documentation. > > _______________________________________________ > 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
