I'd like to know more about the flash device(s) that
you're using. I've just ordered a couple of ROMDisk
and PCMCIA adapters (for desktop machines) to
experiment with these configurations myself.
>> Is there any way to completely disable the system logs?
>
> The log files are kept by the syslogd/klogd processes. Pull the
> appropriate symlinks out of the /etc/rc?.d directories (or edit the
> etc/rc.d/rc.? scripts, depending on your distribution) and they won't
> be started.
>
>> Is there any way to log to ramdisk, so that corruption does not exist on
>> restart?
>
> Yes, just make sure the ramdisk partition is mkfs'd and mounted before
> syslogd/klogd are started.
>
>> Better yet, is there some recovery scheme that does not require console
>> intervention?
>> (apparently the file system check will not run unattended)
>
> You can hack e2fsck... throw in some failure case handlers (like
> automatically trying backup superblocks if the primary is invalid,
> etc) and throw out any checks to make sure "the user is really
> there"... but remember, that stuff is probably there for a reason.
Yuck! Why hack the fsck binary -- you can just run
it under 'expect' to do the unattended stuff.
(In addition to being trivial to script -- even for
non-programmers -- your 'expect' script can have
conditionals to respond to specific error messages
with specific responses).
Another option -- better for this embedded system
situation -- is to run e2fsck -n || restorefs
(Where restorefs is a script that does the appropriate
mkfs and whatever other restore procedures you want).
In other words -- if there is any error have the fs
re-created automatically. From what I recall this is
the strategy taken by McAfee's "WebScan" -- which is
a package that uses Linux as an "embedded/turn-key"
system.
> I realize this is an embedded system, but if its networked or has
> serial outut it may be a better option to just have syslogd direct all
> logging data over the network/serial port/etc. This way you can have
> persistent storage of the logs on the far end and won't have to worry
> about doing a "proper" shutdown... (man syslogd.conf)
> Adam
--
Jim Dennis (800) 938-4078 consulting@starshine.org
Proprietor, Starshine Technical Services: http://www.starshine.org
PGP 1024/2ABF03B1 Jim Dennis <jim@starshine.org>
Key fingerprint = 2524E3FEF0922A84 A27BDEDB38EBB95A
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu