Date: Mon, 1 Jan 2001 23:45:03 +0100 From: "Leif Neland" <leifn@neland.dk> To: "Dan Nelson" <dnelson@emsphone.com> Cc: "FreeBSD hackers" <freebsd-hackers@FreeBSD.ORG> Subject: Re: Boot process robustness Message-ID: <04ff01c07445$53563d20$0e00a8c0@neland.dk> References: <Pine.BSF.4.31.0012281359140.22167-100000@surreal.nl> <2620.978013915@critter> <20001228170241.D404@ringworld.oblivion.bg> <20001228092057.A15343@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > If an fsck fails, ifconfig the interfaces and start an sshd so > > > people can get in remotely and fsck... > > > > What if an fsck on /usr fails? Other than that, I love the idea! > > Force-mount it read-only if necessary, or simply copy a static sshd > into /sbin. Runnning fsck -y is the wrong solution, since if fsck > can't fix an error automatically, something pretty bad has happened > (physical media error, someone dd'ing onto the raw disk, etc).. > Even so, unless the machine contains invaluable data, I guess 99% still does a fsck -y if fsck fails. I'd rather have my remote boxes do that by themselves, and perhaps email me, than I either have to drive there, or give somebody the root password, and remote control that person to just do fsck -y. In almost all cases, when a machine can't fsck itself after a power failure, a fsck -y fixes it. But then, most of the disk is either squid's cache, or unused stuff like termcaps, kernel source, man pages etc. Most stuff is there just because it could be handy one day, and it is not worth the trouble pruning it. Leif 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?04ff01c07445$53563d20$0e00a8c0>