DaemonForums  

Go Back   DaemonForums > Miscellaneous > Guides

Guides All Guides and HOWTO's.

 
 
Thread Tools Display Modes
Prev Previous Post   Next Post Next
  #1   (View Single Post)  
Old 8th February 2009
carpman carpman is offline
Shell Scout
 
Join Date: Jul 2008
Posts: 94
Thanked 0 Times in 0 Posts
Default Remote FreeBSD server upgrade - Guide!

Hello, ok following my recent experience of updating a remote freebsd server for this first time i have come with following method for future updates/upgrades.

This is a work in progress and will try and keep it upto date from feedback.

This was put together after help from:

TerryP
robbak
DutchDaemon
phoenix

Version 2
Updated 18 Feb 09

If there are any points that still need clarification and if you spot anything incorrect or that could be added i would appreciate it

Those marked with * have info in notes section which you should read.

Code:
1. Turn OFF kern_securelevel=2 in rc.conf

2. Reboot

3. cd /boot

4. cp -Rp kernel kernel.works *

5. Edit stable-supfile file to required version

6. run: csup stable-supfile

7. cd /usr/src

8. less UPDATE - check for important notes

9.  make -j3 buildworld

10.  make -j3 buildkernel KERNCONF=MYKERNEL *

11.  make KODIR=/boot/kernel.new KERNCONF=MYKERNEL installkernel *

12. nextboot -k kernel.new  *

13.  reboot

14. rename /boot/kernel.new to /boot/kernel

15. mergemaster -p *

16. make installworld

17.  mergemaster -viU *

18.  reboot *

19. Turn ON kern_securelevel= in rc.conf

20. reboot

Notes:

1.
I never found any mention of this in docs or guides as they assume you will be in single user mode, if you don't comment out kern_securelevel= and reboot the make installworld will fail.

4.
(name it after the kernconf file name, version number, or something that is easy to remember). This isn't as big a deal when doing remote upgrades as you can't get a loader prompt (unless using a serial console), but it's a good habit to get into and you may get datacenter to boot for you, as you can then you can use
Code:
load /boot/kernel.works/kernel
load /boot/kernel.works/acpi.ko
to load the known-good kernel.

If you use 11. & 12. this is less of an issue.

9. & 10.
The standard recommendation is to use (NUMCPUS + 1). Using too high of a -j setting will slow things down immensely. You judge this on server load, use low setting if doing it when server has high load or higher setting when server not busy, it is case of balancing 'get it done quick with high load on server' or 'take longer but don' load server as much'.
You may want to do a few test runs to find the optimum setting for your systems. Run the following with various -j settings:
Code:
# /usr/bin/time -h make -jX buildworld
11.
This will install the kernel as /boot/kernel.new and leave the working kernel as /boot/kernel. (recommended)

If you wish you can also have entry in make.conf that will build generic and custom kernel but only use custom kernel.

KERNCONF= is a space separated list of kernels to build/install, in the order to build/install them. So you can use things like:

Code:
# make KERNCONF="MYKERNEL GENERIC" buildkernel
# make KERNCONF=GENERIC KODIR=/boot/kernel.generic installkernel
# make KERNCONF=MYKERNEL KODIR=/boot/kernel.custom installkernel
to build the two kernels one after the other, then install them individually. You can also use the following, which will install the two kernels one after the other, which has the effect of making /boot/kernel==GENERIC and /boot/kernel.old==MYKERNEL:
# make KERNCONF="MYKERNEL GENERIC" installkernel

12.
This boots into new kernel, if it all goes foobar up then a remote reboot by datacenter should get you back into old kernel.

13.
To make sure the kernel works. You can run an old world on a new kernel, but you can't run a new world on an old kernel. So if you reboot after installworld and things fail, you may be screwed, requiring the use of a fixit CD.


15 & 17
During mergemaster the question about deleting /tmp/temproot kept coming up and was not sure if i should or not, here is explanation given:
Quote:
Not deleting temproot just saves a little bit of time when you run mergemaster again. If you delete it, mergemaster will simply repopulate it. Usually just delete temproot after mergemaster -p and mergemaster -U/ai/whatever.
18.
This just to make sure all is ok with new kernel and world before setting securelevel.

Single user mode.
In handbook and guides tell you to enter single user mode before doing make installworld, trouble is on remote server this is not possible so you have bypass this step. I am told there is risk but with so many remote servers it does appear to work ok.

Quote:
Single use mode is used to ensure that there is no processes that will mess up as system files change. It is rare, and should never cause problems that won't be fixed by the next restart.
Quote:
It's safest to use single-user mode, as nothing is loaded into memory except the kernel, and no users can login. However, if you manually stop as many running processes as possible (except sshd of course), and know that no users will be logging in, you can run installworld without dropping to single-user mode.
Hope this is of use to others in same boat as me in regards to remote update / upgrade.

Last edited by carpman; 18th February 2009 at 06:23 PM.
Reply With Quote
 

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Remote backups server using FreeBSD, ZFS, and Rsync phoenix Guides 1 5th March 2010 12:17 AM
upgrade xorg on freebsd ccc FreeBSD Ports and Packages 5 1st February 2009 04:17 PM
freebsd 7.1 upgrade buildworld error map7 FreeBSD Installation and Upgrading 9 30th October 2008 06:54 PM
A Comprehensive Guide to FreeBSD ijk Book reviews 1 29th July 2008 03:53 PM
Remote Access to File Server Oko OpenBSD Security 7 23rd June 2008 05:17 PM


All times are GMT. The time now is 11:19 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick