[Etherboot-developers] Additional Features in Etherboot

[Anselm M. H. <an...@ho...>]

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