Hello, a really good point. The order is an important point.
To solve all those combinations I see some ways, but I cannot say, which is the best. 1) network stuff only done in preset menu (never done by GRUB itself): - setup for serial is possible before - loading keymap is possible to do afterwards - order is fully free - with `bootp --with-configfile' the main menu is loaded from net or with `configfile NAME' the menu can be started from where you want - with this method, a special diskless GRUB version is never needed any longer (REMARK: with this generic way we can further go ahead and say: the preset menu is mandatory and is also responsibe to start the menu file. On the other hand we loose the option to define the path+filename of the menu.lst file we can specify at installation of GRUB). 2) network stuff is initialized after preset menu (my current implementation): - setup of serial console is possible before BOOTP call - original design of main menu and preset menu is kept - in special cases, if there is a need to have an network access for loading keymaps, etc, the user can add `bootp' and `root (nd)' in the preset menu, so thje network setup is done twice, which is no problem - No change in the GRUB build 3) network stuff is initialized before preset menu (current implementation): - preset manu and main menu may have network access * - NOT POSSIBLE to setup serial console to observe problems in doing BOOTP plus NIC probe - original design is kept - no changes in GRUB anywhere 4) having two preset menus, one before and one after the network setup - little bit too much for a poor user I really want to list all possibilities and do a comparison. But if we do not want, that the user has to specify all the action in the preset menu, then only variante 2 fullfills all possibilities. For variante 3 there is additional work to do, to have (again) another method to setup the console type. I hope we will find a satisfied method here. But again, I want to say thank you for leading this good project with the ultimative boot loader I have ever seen. The points we discuss here are only unimportant details, but the right way for solutions for all special usages like embedded systems. With friendly regards Christoph P. "Yoshinori K. Okuji" wrote: > > At Thu, 10 Jan 2002 17:35:39 +0100, > Christoph Plattner wrote: > > Sorry, if I had something wrong ! > > You never answered to my last email, I do not hope > > I said (wrote) something, which was not good ... > > Don't mind. I just didn't notice you asking something at all. > > > What is the problem in your oppinion to have the > > network setup between preset menu and main menu ? > > If the user wants networking in the preset menu, he/she wants GRUB to > initialize his/her network before reading the preset menu. This is a > bit theoretical, as GRUB doesn't have any command obtaining a file > which can be executed at the reading time (i.e. the type of > BUILTIN_MENU). This is because GRUB cannot open multiple files at a > time gracefully in the current implementation. > > However, this will change in the future. For example, GRUB will have a > command to ``include'' another configuration file in a file. This is > supposed to be used, for instance, to change a keymap. > > If the user wants a non-QWERTY keymap, he would consider to set it up > in the preset menu, because this permits him to use his favorite > keymap, even if GRUB cannot find his real configration file. When the > keymap file is on a remote host, GRUB must use a network in the preset > menu. This implies that his network must be initialized before the > preset menu. > > That example above is quite similar to your situation. The order is > quite important, but you cannot say which order (yours or his) is more > important. So I judged that the user should choose the order himself. > > If I'm wrong, let me know, please. > > Thanks, > Okuji -- +--------V--------+ [EMAIL PROTECTED] | A L C A T E L | ----------------------------- +-----------------+ Phone: +43 1 27722 3706 T A S Fax: +43 1 27722 3955 _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub