Date: Wed, 03 Dec 2003 12:40:35 -0500 From: "Jonathan T. Sage" <sagejona@theatre.msu.edu> To: freebsd-questions@freebsd.org Subject: Re: Is there a guide to Upgrading a FreeBSD server remotely Message-ID: <3FCE2013.1080806@theatre.msu.edu> In-Reply-To: <20031203065356.X741@pukruppa.net> References: <3FCBF280.9060108@acm.org> <20031203021242.GB562@dds.nl> <20031203065356.X741@pukruppa.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE156B51183CB8C2BA079B367 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Peter Ulrich Kruppa wrote: > On Wed, 3 Dec 2003, Alex de Kruijff wrote: > > >>On Tue, Dec 02, 2003 at 03:01:36AM +0100, Denis Fortin wrote: >> >>>Greetings, >>> >>>I've Google'd a bit, but I cannot find a "survival guide to upgrading >>>a FreeBSD system remotely". >>> >>>The Handbook's procedure is excellent (cvsup to the RELENG branch and >>>then make'ing world), but it requires going into single user mode and >>>using the console, two things which may not be possible in the context >>>of a server sitting unattended in a hosting center 10000 kilometers away. >>> >>>Has anyone written a quick guide on issues that can arise in this kind >>>of situation? (For instance, one the the issues is that one might end >>>up with a bad kernel: have people devised a way for the boot code to >>>interact with "reboot -k xxx" to revert to the default kernel after an >>>unsucessful boot, or after a specific time?) >>> >> >>Although its not recommended to do this, it can be done. It basicaly >>comes down to following the manual (without rebooting into single >>usermode) and be very very carefull. Read everything you need to read, >>run every command you need to run and have someone sitting there in case >>it goes wrong. >> >>Note: I've never done this on a busy system. > > That is the really important thing: there shouldn't be any other > traffic on the system. > Do everything step by step and keep a logfile to check if > everything worked o.k. . Do something like > # make buildworld > logfile & > In case your connection breaks, buildworld will go on and you can > check everything when it is up again. With > # tail -f logfile > you can check the advance anytime you whish. > > Uli. alternativly, check out the screen utility. it keeps tty's alive on disconnects (among other things) /usr/ports/misc/screen ~j -- "Yesterday upon the stair I saw a man who wasn't there, he wasn't there again today, oh how i wish he'd go away" Rev. Jonathan T. Sage Lighting / Set Designer Professional Web Design [HTTP://thr.msu.edu] [wisesage98@yahoo.com] [PGP: www.keyserver.net] --------------enigE156B51183CB8C2BA079B367 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/ziAToVmW2UUup/ERAmlTAJ97bUZflG1Pik9hk82hnTJCC6CaBQCdHD/O Zli9hpwSKDLvZ3MS3dWUFNQ= =1a08 -----END PGP SIGNATURE----- --------------enigE156B51183CB8C2BA079B367--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FCE2013.1080806>