On 12/1/08, Darrick Hartman <[EMAIL PROTECTED]> wrote:
> Philip H W Schroth wrote:
>
> > Is it normal that astlinux 0.6.2 takes about 1 min and 40 seconds on my
>  > alix board?
>  >
>  > Askozia takes only 15 seconds.
>
>
> Yes.  Hook up a serial cable and you'll see why.  During the boot
>  process, an initial boot loader (runnix) loads.  That looks into the
>  'os' directory for the Astlinux.run and .run.sha1 files.  It does an
>  sha1sum check on the run file and checks that against the .run.sha1 file
>  before it actually loads Astlinux.  This allows for automated updates in
>  the field.
>
>  If you have one or two Astlinux boxes, upgrading can be simple, but if
>  you have 10 or 15 and many of them more than an hour drive away, it's
>  much easier to upgrade.  Simply copy the correct files into the 'os'
>  directory and reboot.
>
>  I was initially put off by the longer boot time, but the benefit
>  outweights the delay in my case.
>
>  It's still faster than several other commercial pbx systems.
>
>
>  Darrick
>

I'm glad this came up.

The current boot system was implemented with the desire to have almost
foolproof remote upgrade capabilities.  Runnix is a good start to
this.

While the time to boot has always been of some concern up to this
point very little effort has been put into speeding up this process.

Some areas for improvement:

- Strip the runnix kernel down a bit.  The current runnix kernel is
EXTREMELY generic, offering support for anything 386 and up with
support for just about every ethernet controller, most disk
controllers, etc.  It takes at least a few extra seconds to probe for
the various controllers.  This hardware support could probably be
scaled back a bit.

- Speed up the sha1sum, skip it, etc.

- Make the runnix output quiet.  In my own basic tests one of the
slowest parts of the boot process is sending kernel boot output to a
serial port.  Adding "quiet" to the runnix boot params can shorten the
output significantly.  I usually do this anyway to avoid confusion
because yes, it does look like Linux is booting twice (because it is).

- Optimize AstLinux startup.  There is currently a lot of code that
runs on boot.  We read rc.conf individually for each startup script
and run various shell stuff to generate the relevant configs.  This
takes time and has nothing to do with runnix.  By optimizing some of
this code we can improve the overall AstLinux boot time.  Not that I'm
delegating but this seems like something Philip would be interested in
(I'm sure he's brought it up before).

  If AstLinux were a desktop or consumer-device oriented distro
(PVR/DVR/MythTV/etc) boot time would be a priority.  The very nature
of a PBX or network appliance requires long uptimes and minimal
reboots.

  I know it might take a while to get used to some of the
disadvantages of runnix (higher complexity, longer boot times, etc)
but once it has saved you from a couple of truck rolls (as Darrick
points out) an extra 60 seconds to startup every six months won't seem
so bad ;).

  A very dramatic example is Star2Star's starbox usage.  We routinely
upgrade customer equipment, often times with no expertise available on
site to remedy any potential problems.  We've performed (literally)
thousands of remote upgrades without ever rendering a machine
unbootable.  I'm pretty happy with that track record!

-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Astlinux-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to [EMAIL 
PROTECTED]

Reply via email to