Re: KERNCONF instead of KERNEL?
> > Date: Fri, 02 Mar 2001 23:34:19 +0900 > From: "Daniel C. Sobral" <[EMAIL PROTECTED]> > Subject: Re: KERNCONF instead of KERNEL? > > [EMAIL PROTECTED] wrote: > > > > What is the prefered way to update a remote machine now? For years, I've run > a > > make buildworld, installworld, cd /sys/i386/conf config, build and install a > > kernel, then reboot. All through telnet or ssh. I've never had problems in > > the past, and all goes well. Is there a better way to do this on a machine > > that you can't get to the console? > > Here is the order suggested and the why: > > 1) make buildworld -- because the new kernel may depend on new tools > (config(8) is a common example, but no the only one). > 2) make buildkernel -- some programs may depend on new syscalls, so > build the kernel before installing the world. > 3) make installkernel -- install a new kernel (the copy of the old one > is preserved) > 4) reboot single user -- make sure the new kernel works You can't reboot to single user mode when you are doing a remote update. He is specifically asking about the best way to do a remote update. You have to do everything multiuser and accept the risk, but there is still the question of what order minimizes the risk. > 5) mount filesystems, make installworld -- install the rest of the world > 6) mergemaster -- update /etc -- the new userland tools may require new > /etc scripts and configuration files. > > - -- > Daniel C. Sobral(8-DCS) > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > I think you are delusional, but that is OK. Its part of your natural > charm! - Bob To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: KERNCONF instead of KERNEL?
On Fri, Mar 02, 2001 at 01:52:33PM -0500, Bob Johnson wrote: > You can't reboot to single user mode when you are doing a remote > update. He is specifically asking about the best way to do > a remote update. You have to do everything multiuser and accept > the risk, but there is still the question of what order minimizes > the risk. The give one is it. It's going to be pretty easy to talk a NOC monkey through booting the system on the old kernel, but damn near impossiable to get them through recovering a system with a busted kernel and a userland that won't work with the old one. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: KERNCONF instead of KERNEL?
Brooks Davis <[EMAIL PROTECTED]> types: > On Fri, Mar 02, 2001 at 01:52:33PM -0500, Bob Johnson wrote: > > You can't reboot to single user mode when you are doing a remote > > update. He is specifically asking about the best way to do > > a remote update. You have to do everything multiuser and accept > > the risk, but there is still the question of what order minimizes > > the risk. > The give one is it. It's going to be pretty easy to talk a NOC monkey > through booting the system on the old kernel, but damn near impossiable > to get them through recovering a system with a busted kernel and a > userland that won't work with the old one. How well does setting the serial console help in this case? I've not used it, as my remote admin experience is with hardware that lets you talk to the mobo rom via a serial line. If the appropriate serial flags will let you work in single user mode over a serial line, then you can do the installworld in single user mode. If they let you boot an alternate kernel over a serial line, then you're set, aren't you? http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: KERNCONF instead of KERNEL?
On Fri, Mar 02, 2001 at 01:59:48PM -0600, Mike Meyer wrote: > How well does setting the serial console help in this case? I've not > used it, as my remote admin experience is with hardware that lets you > talk to the mobo rom via a serial line. If the appropriate serial > flags will let you work in single user mode over a serial line, then > you can do the installworld in single user mode. If they let you boot > an alternate kernel over a serial line, then you're set, aren't you? If you have a serial console then you should follow procedure described in /usr/src/UPDATING since you can boot your system into single user mode. There is really no difference between doing a remote upgrade via serial console and doing a local upgrade. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: KERNCONF instead of KERNEL?
Nik Clayton wrote: > > On Fri, Mar 02, 2001 at 11:34:19PM +0900, Daniel C. Sobral wrote: > > Here is the order suggested and the why: > > > > 1) make buildworld -- because the new kernel may depend on new tools > > (config(8) is a common example, but no the only one). > > 2) make buildkernel -- some programs may depend on new syscalls, so > > build the kernel before installing the world. > > 3) make installkernel -- install a new kernel (the copy of the old one > > is preserved) > > 4) reboot single user -- make sure the new kernel works > > 5) mount filesystems, make installworld -- install the rest of the world > > 6) mergemaster -- update /etc -- the new userland tools may require new > > /etc scripts and configuration files. > > I think the attached diff to the Handbook brings it up to date with > reality. I've also attached the generated HTML file, for those of you > that don't want to build the docs. Comments? Yes, there are several things that I think are basically wrong. On the -j4 option, what was -current is now 4.0-release or later. On a fast uniprocessor system, using -j4 on the make actually causes the buildworld to run 10% or more longer by the clock. Your user and system time may be shorter but the build takes forever. You are adding overhead to access I/O that the HD's can't provide and the cpu is left in an idle state waiting for I/O. This becomes especially true on large single HD's. Turning on softupdates helps. I have a AMD Thunderbird 900 with 256MB of PC-133 memory that I tried various combinations on. I added ATA-100 HD's until I had reasonable build times. I eventually ended up with 3 and had each on its own controller. I haven't tried fast scsi yet but I think the majority of the new users are building systems around IDE drives and you can see the slowdown when you use -jx with x >= 2. It isn't bad for people running setiathome because it will continue to use 40% or more of the cpu and doesn't interfere. When the percentage reported by time goes over 100%, which it can for multiprocessor systems, setiathome didn't get much time. That data also wasn't included in my table. The only system that can use -j4 is a dual headed system (2-P-III 866's with 256MB of PC-133) with the source on a 2-HD HPT-370 raid-0 array. The system has 3-30GB Maxtor ATA-100 HD's all on different controllers. The variation in build time ran from 1:21 to 34 minutes with softupdates and /usr/src on the raid-0 array. If I tee the output from the build to a file, it only slows the build down to 35:xx minutes. Some entries from my build times log are: buildworld, softupdates, 1-HD 1597.238u 629.123s 47:52.34 77.5% 1227+1393k 42713+11617io 1575pf+0w raid-0 for /usr/obj but no softupdates. 1599.347u 628.302s 1:21:36.28 45.4% 1230+1395k 44554+138574io 1828pf+0w raid-0 (64k) for /usr/src, -j4, and softupdates for everything but / 1655.441u 730.090s 34:16.34 116.0% 1210+1380k 47507+3918io 1881pf+0w make buildworld with tee'ed logging and current setup from above 1665.892u 702.004s 35:14.42 111.9% 1211+1387k 51575+4140io 1918pf+0 The chflag noschg isn't needed on 4.2. I don't know when that was changed but you don't have to use it to rm -rf * files in /usr/obj. Of course, if you have a kern_secure level set in 4.2, you can't noschg anything from multi-user mode and the installkernel will die trying to mv the kernel's around. You have to be running in single user mode to get around the kern_secure level setting. Kent > > N > -- > FreeBSD: The Power to Serve http://www.freebsd.org/ > FreeBSD Documentation Project http://www.freebsd.org/docproj/ > > --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- > > -- > Name: makeworld.html >makeworld.htmlType: Hypertext Markup Language (text/html) > Encoding: quoted-printable > > Name: mw.diff >mw.diffType: Plain Text (text/plain) > Encoding: quoted-printable > >Part 1.2Type: application/pgp-signature -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re[2]: KERNCONF instead of KERNEL?
-BEGIN PGP SIGNED MESSAGE- Hello Bob, Friday, March 02, 2001, 7:52:33 PM, you wrote: > You can't reboot to single user mode when you are doing a remote > update. He is specifically asking about the best way to do > a remote update. You have to do everything multiuser and accept > the risk, but there is still the question of what order minimizes > the risk. While I'm fully aware that it isn't officially allowed to do multiuser make installworld / installkernel runs, I've been doing it for more than half a year now without (at least 30 times on different machines) any problems except for one time where the box didn't come up anymore because of a screwed kernel. I've done it on servers 20cm away from me as well as on those in our colocation 15min by car from here as well as with them in another colocation which is essentially on the other side of the earth. Other administrative mistakes (mistyped rootshell, accidentally misconfigured firewalls etc) have caused far more downtime for us than any make world stuff. My conclusion: I'm not member of the project but according to my experiences, this risk is acceptable (and for the second colo, I simply haven't got any chance, to do it any other way at the moment). But there IS a possibility to go to single user from remote (although I never actually tested it): use serial console and crossconnect two servers so one can access the other (or use some Portmaster or similar gear). This way, you should be able to go to single user via the other box and then using serial console. Serial console has saved my life several times when there went something wrong (one time, sshd didn't want to come up anymore, for example). Best regards, Gabriel -BEGIN PGP SIGNATURE- Version: PGP 6.0.2i iQEVAwUBOp/qLMZa2WpymlDxAQH5Xgf/aHdFCzX+vaeM78+9JNnTdFiW67jnTaae eNaeRs6m9nFH1nWDv44SqDhaOWyiraaPAJV8rECZFFNGOeuewT6lHjPYZKQY7Tl8 7cxRbyhwzrB6uHYfndQaurll3482xefQFExiJtMI1cSgtyAUcW8J3OaFipEdasYh +2LM5DxY43kPq4xxAUCs6dtJnNgdEYDn4TCfHFcHfKtUMfxzXcA1RTAFxoysA/Am y44TL6HVI5SAaFZotlP0Um1OfX7FbCf0F3QCGDjsuXJH38so+GZhe2zGSlGzKKIJ CpFEcA1JvxIEE7fUNE28Q65XdtLQwN5JIu9S+6K7jhiSHy5ZMMFkTw== =LEjw -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Installing the world on remote machines (was Re: Re[2]: KERNCONF instead of KERNEL?)
It's perfectly safe to do an installworld on a multi-user system providing: (1) That you've kicked any other users off and (2) That you've killed any daemons that might exec something on a regular basis. sendmail, cron, webserver, etc... (not sshd, but make sure nobody ssh's in while you are updating the source base). The issue here is that the installworld does not use a 'create file under temporary name and rename it' scheme. It uses a 'remove the old file, create the new file' scheme so an exec() at the wrong time can cause a program to try to load a partially written shared library (e.g. libc). Some daemons really take exception to this and wind up getting into fork/exec/core loops which can make the machine unusable. -- I always update my remote machines by building all necessary kernels, building the world, and installing it all on a build machine first to make sure I've got the upgrade procedure down. Then I NFS-export /usr/src and /usr/obj read-only to the remote machines and do the kernel install and the installworld on each remote machine. (note: /usr/src and /usr/obj should be part of the /usr partition, without using any softlink tricks, or running installworld on the remote machines will not work as expected). I never build the world directly on a remote machine. NOTE DANGER!!! When doing an installworld over NFS, it takes much longer for the installworld to copy any given file (such as files in /usr/lib), which increases the chance of a daemon trying to fork/exec a program and dying a horrible death, possibly making the machine unusable. All remote machines should have some sort of serial console and power cycler setup to allow recovery from these and other potential problems. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Installing the world on remote machines (was Re: Re[2]: KERNCONF instead of KERNEL?)
Matt Dillon <[EMAIL PROTECTED]> types: > I always update my remote machines by building all necessary kernels, > building the world, and installing it all on a build machine first to > make sure I've got the upgrade procedure down. Then I NFS-export > /usr/src and /usr/obj read-only to the remote machines and do the > kernel install and the installworld on each remote machine. > (note: /usr/src and /usr/obj should be part of the /usr partition, > without using any softlink tricks, or running installworld on the > remote machines will not work as expected). The critical thing here is that src & obj have to have the same real directory name on all systems concerned. If you have a shared partition and symlink /usr/src & /usr/obj to /shared/src and /shared/obj on the build system, then the client systems must mount the shared space as /shared, and symlink /usr/src and /usr/obj the same way the build system does. Or if you have one of them symlinked that way (to split the build process across spindles), then the client system must mount both /usr/src (or /usr/obj) and /shared, and symlink /usr/obj (or /usr/src) to /shared. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
