Date: Tue, 2 Jan 2001 23:55:35 -0500 From: "James Halstead" <james_bond_79@yahoo.com> To: <freebsd-hackers@freebsd.org> Subject: Re: Boot process robustness Message-ID: <019101c07541$6a573cc0$0601a8c0@halstead007>
next in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "James Halstead" <james_bond_79@yahoo.com> To: "Poul-Henning Kamp" <phk@critter.freebsd.dk> Sent: Tuesday, January 02, 2001 11:30 PM Subject: Re: Boot process robustness > > ----- Original Message ----- > From: "Poul-Henning Kamp" <phk@critter.freebsd.dk> > To: "Walter W. Hop" <walter@binity.com> > Cc: "FreeBSD hackers" <freebsd-hackers@FreeBSD.ORG> > Sent: Thursday, December 28, 2000 9:31 AM > Subject: Re: Boot process robustness > > > > In message <Pine.BSF.4.31.0012281359140.22167-100000@surreal.nl>, "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. > > > > Couldn't you just modify the shutdown command to have an option for revert > on fail, which would create > a file on the root filesystem with a timestamp of when the reboot started. > Then at boot time, if that timstamp > is still there, and has been around for too long, boot the kernel.old > instead of kernel. Then the question is > what amount of time is reasonable for the wait period. This may have the > machine boot the new kernel > and panic a few times, but at least you can be assured that it would after x > minutes boot the old kernel > instead. Once a boot was successful the times stamp file could be removed. > > Just a thought. > > ~James > > > 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 > > phk@FreeBSD.ORG | 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 majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?019101c07541$6a573cc0$0601a8c0>