Linked by Nathan Mace on Tue 19th Mar 2002 17:21 UTC
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
Linked by Thom Holwerda on 06/14/13 20:46 UTC
Linked by Thom Holwerda on 06/14/13 17:32 UTC
Linked by Thom Holwerda on 06/14/13 11:39 UTC
Linked by Thom Holwerda on 06/14/13 11:32 UTC
Linked by Thom Holwerda on 06/13/13 19:39 UTC
Linked by Thom Holwerda on 06/13/13 14:45 UTC
Linked by Thom Holwerda on 06/13/13 11:43 UTC
More News »
Sponsored Links



and after that my customized kernel. Looking through the new GENERIC is always recommended and compiling one is too, just in case your cust kernel doesnt boot or something. If dealing with a remote box, well I think you can stick it into one of the boot config files as well as a copy of your former kernel. Than you might quite safely reboot.
Note that this is about reboot after installworld and mergemaster (upgrade ports after reboot). Can't reboot single user mode and then ssh into the remote box so no try-outs of new kernels in that case. Finish and reboot.
Besides, you should note that you can do binary upgrades from relase to release and then track the RELENG_4_5 branch (and later 4_6, 4_7, etc) to only get bigfixes and security patches, instead of RELENG_4 (= fBSD-STABLE).
If a fix is needed you either apply patch, or cvsup and then either only compile and install that certain part (if it's easily found) or buils/install world. No fiddling with kernels needed then (unless of course there's a kernel fix).