[CUWiN-Dev] power+serial+ethernet over cat-5 ?

[David Young]

On Mon, Sep 19, 2005 at 02:45:57PM -0700, Matt Westervelt wrote:
> I'm with you on the 30 seconds.   It's pretty bad...  But.
> 
> 1. how often do you reboot.

Every time we upgrade the software.  I do that often enough that I
will notice.

> 2. is a 30 second wait more inconvenient than climbing the roof/tower 
> and pulling the box down so you can plug in a serial.

It is safer and less expensive to wait 30 seconds.  However, nobody will
notice the safety and cost-savings like they will notice the the PITA of
a lengthy reboot.  I predict that a year from now, we will second-guess
the decision to PXE boot in the same way we second-guess the decision
*not* to PXE boot, today. :-)

I am leaning toward a 30-second (gulp) PXE boot, because it solves the
problem of losing control in the short term.  If PoE+RS-232 over Cat-5 can
be made to work inexpensively, it only helps us in the long-term solution,
since we have to buy new nodes, or retrofit all of our existing nodes,
to take advantage.

> 3.  If a dhcp server is present (but not offering PXE images), the boot 
> process does not wait.
> 
> 4. If the box does not have eth0 link (power only on ethernet) the boot 
> process does not wait.

3 and 4 do not usually hold.

Dave

> 
> 
> 
> 
> Bill Comisky wrote:
> 
> >On Mon, 19 Sep 2005, David Young wrote:
> >
> >>On Mon, Sep 19, 2005 at 12:22:37PM -0700, Matt Westervelt wrote:
> >>
> >>>Why don't you set the nodes to PXE on every boot (set before installing
> >>>in hard-to-reach-places).   If there is no image available, the box
> >>>boots normally (with a small delay).   If the box is lobotomized, 
> >>>either
> >>>trigger your PXE over the network (in the case of an already installed
> >>>dhcp server), or bring a laptop onsite to re-image.
> >>
> >>
> >>I don't remember why we don't PXE boot.  It is something I will 
> >>consider.
> >>
> >>Dave
> >
> >
> >
> >Below is from last August. The 30-45 second delay waiting for PXE 
> >booting to fail is certainly an inconvenience if it isn't adjustable..
> >
> >bill
> >
> >-- 
> >Bill Comisky
> >bcomisky at pobox.com
> >
> >
> >From dyoung at pobox.com Fri Aug  5 11:48:06 2005
> >Date: Wed, 18 Aug 2004 17:25:53 -0500
> >From: David Young <dyoung at pobox.com>
> >To: cu-wireless-dev at ucimc.org
> >Subject: [CUWiN-Dev] [rob at nocat.net: Re: [Soekris] comBIOS boot 
> >sequence....]
> >
> >More PXE developments.  A 30-seconds timeout for PXE boot, ouch.
> >
> >Dave
> >
> >----- Forwarded message from Rob Flickenger <rob at nocat.net> -----
> >
> >From: Rob Flickenger <rob at nocat.net>
> >Subject: Re: [Soekris] comBIOS boot sequence....
> >Date: Wed, 18 Aug 2004 15:21:47 -0700
> >To: Soren Kristensen <soren at soekris.com>
> >X-Mailer: Apple Mail (2.619)
> >Cc: soekris-tech at lists.soekris.com
> >
> >Excellent.  Thanks, Soren!  That works great.
> >
> >One last question...  I want to use PXE as a "safety net" for units 
> >that are installed on a tower that have corrupted their flash, or 
> >anywhere that having access to the console port is not practical.  The 
> >only problem with attempting PXE on every boot is that it now takes 
> >about 45 seconds for PXE to fail before it attempts to use the flash.
> >
> >Is there any way to adjust the amount of time that PXE will wait for a 
> >DHCP response?  If there is no bootp offer in, say, 3 seconds, there 
> >will likely never be one.  As it is, it waits about 30 seconds before 
> >giving up.
> >
> >Cheers,
> >
> >--Rob
> >
> >On Aug 17, 2004, at 1:34 PM, Soren Kristensen wrote:
> >
> >>Hi Everybody,
> >>
> >>I was planning to add the functionality to the BIOS the right way 
> >>using the "set" function, but since it keep comming up, let me 
> >>explain how to do it now....
> >>
> >>The comBIOS currently store the boot sequence in the 4 cmos locations 
> >>at 0x21..0x24. 0x80 mean the first harddrive, 0x81 mean the 2nd, 0xF0 
> >>is the PXE rom, 0FF is none.
> >>
> >>The comBIOS will try booting starting with the value in location 
> >>0x21, and continuing with the next one if failing.
> >>
> >>to change it, do:
> >>
> >>>cmosread                    (see whats there now)
> >>
> >>
> >>>cmoswrite 21 XX XX XX XX    (new values)
> >>
> >>
> >>>cmoschecksum                (generate new checksum)
> >>
> >>
> >>
> >>If something goes wrong experimenting with the cmos, you can always 
> >>write some random value and reboot without doing the cmoschecksum, 
> >>the comBIOS will then load it with defaults when the checksum fails.
> >>
> >>Also, note that most empty CF modules come with a broken dos boot 
> >>sector that do not return correctly, and therefore the comBIOS can 
> >>not continue the boot sequence with a fresh empty CF module.
> >>
> >>And please note, my long term plans have always been to not have 
> >>anything if the cmos, all setting will be stored in the flash at some 
> >>point.
> >>
> >>
> >>Regards,
> >>
> >>
> >>Soren Kristensen
> >>
> >>
> >>_______________________________________________
> >>Soekris-tech mailing list
> >>Soekris-tech at lists.soekris.com
> >>http://lists.soekris.com/mailman/listinfo/soekris-tech
> >>
> >
> >_______________________________________________
> >Soekris-tech mailing list
> >Soekris-tech at lists.soekris.com
> >http://lists.soekris.com/mailman/listinfo/soekris-tech
> >
> >----- End forwarded message -----
> >
> 

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933