Re: [Etherboot-developers] Additional Features in Etherboot

[Christoph P. <chr...@al...>]

Hello !

One word to:
	-DLOCALBOOT_DEINIT_NIC

This option should no be an option. IMO it is very important to handle
the full deactivation of all devices touched in the net booting stuff
and in boot loaders.

This is true for etherboot (also for GRUB). Before any system is booted,
kernel is started or a local system is loaded, all devices used or
touched should be clean deactivated. I also so the effect one day under
Windows, that it explicitly cannot operate on the NIC. 

So a good design should include the activation (probing) and a clean
"close" before jumping to the loaded kernel or to the chainloaded image.

With friendly regards
Christoph P.



Anselm Martin Hoffmeister wrote:
> 
> Moin all around,
> 
> I had some special requirements for etherboot functions, so I changed some
> lines in code. Perhaps it would be a good idea to introduce these changes
> into standard etherboot source tree.... That's what I would like to hear your
> opinion about.
> 
> -DSILENT
> ========
> I added this additional switch which suppresses displaying the menu, password
> question and so on.... shortly said, every output between MOTD and [bootdisk]
> resp. [osloader] is suppressed, to the effect that a full-screen-Bootlogo can
> be shown, which in our case displays a penguin and a windumb flag offering
> the selection. We don't want text inside that.... And it's really nice.
> Alternatively, submitting the *keep*shut*up*-option via dhcp (more
> complicated) would allow the boot rom to be used this or that way - which we
> don't need at our site, so I took the way of least resistance.
> 
> -DLAST_MOTD_AFTER_BOOTMENU
> ==========================
> The motd option is VERY useful for designing one's own face of etherboot, but
> supported by the load-file-option ^['filename'# we do not need eight lines of
> text, the first one only indeed. We would prefer to display a text string
> after user chose an operating system, which cleans away our graphical logo,
> brings the display back to text mode and says "Lade Betriebssystem:" (load
> operating system). This is done by modifying the [for]-loop in [show_motd] or
> whatever that function is called so it displays only seven motd-lines, and
> after menu selection displaying the 8th motd line, if defined.
> 
> -DHARDDISK_FALLBACK
> ===================
> What happens when the server cannot be reached? At the school computer room
> where my ltsp project is in development, one time or another the linux server
> may be down, so that a fallback to boot Win3.11 is the best alternative (the
> best existing... Win is sooo slow). We don't want the floppy drive to be
> tried for a boot disk, because some of them are broken, and they are
> hardware-locked anyway. BIOS is too old (486/100). So booting from harddisk
> without any other delay would be best. This option inserts two lines of code
> at the location where server_not_reachable would occur. It just calls
> bootdisk(0x80,0) to load operating system from MBR instead of returning to
> BIOS boot.
> 
> -DLOCALBOOT_DEINIT_NIC
> ======================
> I use to test etherboot at home, on my system with some M$-Operating System
> on it, which is loaded via a menu entry ::::/dev/hda2:::: so via calling the
> function [bootdisk]. Somehow Windumb didn't like being booted by etherboot
> (hanging at some time without further notice.... when trying to find network
> interfaces?), so I tried to investigate why. Entering this switch, which
> de-inits the NIC at the beginning of [bootdisk], made it work.
> 
> -DNO_GFX_COLOUR_CORRECTION
> ==========================
> We really had a hard time finding out what happened to the colours of our
> boot-bitmap. We first tried 256-color-mode, but either bmptoppm or ppmtoansi
> didn't like that. After really frustrating hours of trying and always
> odd-colored logo, we changed to using 16-color images (converted by some
> windumb software to VGA-Color-palette), converting them with a small C
> proggie to ansi and - most important - disabling the colour correction inside
> the ansiesc.c where every colour <= 7 is looked up inside a table and
> replaced by another one. After all this, it went really great. I hope our
> users like it. Obviously, there is need for both measures (disabling colour
> correction AND not using ansitoppm) to work properly.
> 
> That's quite a lot of topic for a single posting, isn't it? But two more
> things I want to mention - kind of request-for-comment. They will go to
> etherboot-users, too.
> a) Is there a need/want for a howto-graphical-boot-logo? We finally managed
> to get one, it was worth the pain. I could also post the program we now use
> to convert bitmap to ansi-graphics.
> b) Is there a need/want for a translated version of etherboot? Our system
> runs in the computer room of a secondary school, and it is kind of teacher's
> policy to prefer german user interfaces... This could be implemented by
> adding symbolic constants instead of strings which would have to be declared
> inside "i18n.h" where a "#ifdef LANGUAGE_GERMAN....." could be done...
> 
> Have a nice day,
> 
> Anselm M. Hoffmeister
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers


-----------------------------------------------------------------
private:  chr...@gm...
company:  chr...@al...