Questions before upgrading from 8.0 to 8.1

B

BeastieBoy

Hi,

I'm running a FreeBSD server 8.0 Release. And I would want to upgrade it to 8.1.

In the handbook, the steps seem a bit complicated in contrast with what the announcement says at url: http://www.freebsd.org/releases/8.1R/announce.html

The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.[0123]-RELEASE, 8.0-RELEASE, 8.1-BETA1, or 8.1-RC[12] can upgrade as follows:

# freebsd-update upgrade -r 8.1-RELEASE

During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new userland components, and the system needs to be rebooted again:

# freebsd-update install
Click to expand...

Is that it?

So far I have fetched the latest ports collection with "portsnap fetch update" and I'm upgrading each port to its latest version before taking the big step.

Any caveats I might fall into? Missing steps?


Thanks for your assistance, this is the first time I'll be upgrading the whole system.
 
The handbook explains how to do a source update. Which is different from the binary update mentioned in the release notes.
 
All my apps have been installed using portmaster from source, this means it is preferable for me to upgrade using the source method shown in the handbook?
 
Ports aren't the Operating System. You don't need to upgrade any ports when you upgrade to a minor release update. If you are running the GENERIC kernel, you can do a binary upgrade, if you choose to update that way. The other option is to update your system via source update, but that has nothing to do with ports. Think of them as separate entities. You only need to update/rebuild all ports when moving from one major release to another (ie. 7.x to 8.x)
 
jgh said:
You don't need to upgrade any ports when you upgrade to a minor release update.
Click to expand...
Do read /usr/src/UPDATING. Sometimes ports do need to be rebuild because of API/ABI changes or changes in data structures.
 
I am not sure about some merge issues I am seeing

Running 8.0-RELEASE-p4. I did # freebsd-update upgrade -r 8.1-RELEASE and it does a bunch of downloads and patches and such.

What has me concerned is that it then starts complaining about changes that require manual intervention, but after doing 3 or so of these (files like /boot/devices.hints that I have never changed), I noticed that the only changes are the initial revision lines.

Why is it unable to do that part automatically? I assume I am missing something, but I don't know what, offhand :(
 
Looking at this more, I am guessing it is because it is comparing the files against stock 8.0, not 8.0p4? I assume rolling back to the vanilla 8.0 is not feasible? Or somehow telling freebsd-update to use 8.0p4 instead of 8.0? Or am I just stuck editing each file as it is presented to me and fixing up the revisions?
 
Sigh. So I just spent a couple of hours doing cut&paste merges of files that didn't really require any action (from appearances anyway.) I then went into a phase of several dozen files where I didn't have to edit anything, but did need to answer 'y' or 'n'. On one of them, I messed up and typed 'n'. Imagine my surprise when the entire update process bailed out to command level and I had to re-do *everything* up to that point. Is this really what you have to do to update from a security patch system to a newer base system? Sorry if I sound irritated, but this has not been fun :( I think I may just do a full backup and then rollback all the way to vanilla 8.0-RELEASE and see if I can go from there...
 
Look at the -i & -U options to mergemaster(8) to skip all that tedious upgrading of files you've never edited. As for the rest: yeah, it's a PITA, but it's better than blindly stabbing a musk ox from a moving bus.
 
I guess I'll look into this again the next minor release. For now, I just updated the 107 or so files manually (well, walking through the diff process, there were really only one or two files that actually needed merging) and am now on 8.1. This is a production server, so I don't feel very comfortable experimenting with it...
 
You should be able to do a:

freebsd-update rollback && shutdown -r now

to go back to the previous version. Then you could edit your mergemaster file under /etc/ and then do the update again.
 
Thanks for the suggestion

but given that it is a production server and I have already upgraded it (sorry if that wasn't clear from my previous post), rolling back to experiment with another way of upgrading seems ill-advised. Also, unless I am totally confused, the freebsd-update script does not use mergemaster (at least groveling through the script does not seem to indicate this...)
 
dswartz said:
I guess I'll look into this again the next minor release. For now, I just updated the 107 or so files manually (well, walking through the diff process, there were really only one or two files that actually needed merging) and am now on 8.1. This is a production server, so I don't feel very comfortable experimenting with it...
Click to expand...

I found that a more recent version (2011-05-11) of freebsd-update addresses this issue. The latest version of freebsd-update() can be found on the CVS site.

cperciva said:
Revision 1.25
SVN rev 221780 on 2011-05-11 15:23:27Z by cperciva

Make freebsd-update(8) smarter in how it handles $FreeBSD$ tags in
configuration files.

If the current file differs from the canonical version from the old release
only due to differences in the $FreeBSD$ tag (which can happen if the system
was installed from source code, depending on how the src tree was checked out)
then freebsd-update will treat the file as "unmodified" and silently update
it to the "clean" version in the new release.

If the only change being made to a configuration file is in the $FreeBSD$
tag (e.g., for any configuration files which have been modified locally, now
that we're using SVN and the $FreeBSD$ tag changes when a branch is created),
freebsd-update will no longer print the diff and prompt "Does this look
reasonable (y/n)?".
Click to expand...

Revision 1.25 works as advertised for me, drastically reducing the number of unnecessary "merges."
 
You must log in or register to reply here.
Back
Top