In message <[EMAIL PROTECTED]>, "Walter W. Ho
p" writes:
>Hi all,
>
>I was wondering how to increase the robustness of the booting process,
>so that a box would be able to keep itself on its feet without
>intervention of the console. I think this would be of great value to the
>many people who administer colocated boxes.
>
>I'm not much of a coder so all I can do is mailing this (at the risk of
>wasting your time with total useless crap ofcourse, in which case I
>apologize.)
>
>1. Old kernel recovery
> When 'make install'ing a new kernel, a flag is raised (say,
> 'revert_on_fail') which is only cleared after a successful system
> initialisation. When the new kernel boots, a panic in this state or
> an unexpected reboot (reset after a system hang) would cause
> /kernel.old to be loaded on the next boot instead (maybe the same
> could work for /etc/rc.conf.old)
This is actually more a question of where to store the flag than
anything else.
Julian made a rather hackish thing for Whistle, but I think we lost
that with the advent of the new bootblocks.
>2. Automatic file system checks
> In case of a powercycle or crash, it could be that a filesystem needs
> fixing. Now I don't know much about fs internals, but I guess that in
> most cases just answering 'Y' to fsck's questions will fix things. I
> would appreciate an option where an inconsistency would start up fsck
> in an "automatic" repair mode, with all actions logged and "undo"
> data being saved (in case manual review is needed).
Alternatively it might be worth considering adding a "remote-single-user"
capability:
If an fsck fails, ifconfig the interfaces and start an sshd so people
can get in remotely and fsck...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
