Custom kernel - upgrade from 8.0 to 8.2

I am currently on:
Code:
uname -a
FreeBSD abc.xyz.com 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Sun Jan 24 09:14:42 GMT 2010     xy16644@abc.xyz.com:/usr/obj/usr/src/sys/ALPHA  i386

and would like to upgrade the system to 8.0-RELEASE-p6

I tried do this as follows:
Code:
freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 8.0-RELEASE from update5.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

The following files are affected by updates, but no changes have
been downloaded because the files have been modified locally:
/var/db/mergemaster.mtree

The following files will be updated as part of updating to 8.0-RELEASE-p6:
/usr/share/man/cat2/unmount.2.gz

WARNING: FreeBSD 8.0-RELEASE-p2 HAS PASSED ITS END-OF-LIFE DATE.
Any security issues discovered after Wed Dec  1 00:00:00 GMT 2010
will not have been corrected.

but that didn't seem to work...even after a reboot I am still running p2. I do run a custom kernel, could this have something to do with it?

Once I have updated my current version to 8.0-RELEASE-p6 then I would like to upgrade to 8.2-RELEASE.

Can someone help me get there please? :e
 
killasmurf86 said:
Yes, you need to recompile and install your custom kernel in order for uname -a version to be updated

Thanks for that but could you explain that in a bit more info please. I'm not really sure as to what the next steps are. I have never tried this with a custom kernel before :e

Do I even need to update my current 8.0 p2 to p6? Or can I upgrade straight to 8.2?
 
I have run the following command:
Code:
freebsd-update upgrade -r 8.2-RELEASE

and it came back saying:
Code:
alpha# freebsd-update upgrade -r 8.2-RELEASE
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 8.0-RELEASE from update5.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Inspecting system... done.

WARNING: This system is running a "alpha" kernel, which is not a
kernel configuration distributed as part of FreeBSD 8.0-RELEASE.
This kernel will not be updated: you MUST update the kernel manually
before running "/usr/sbin/freebsd-update install".

The following components of FreeBSD seem to be installed:
kernel/generic src/base src/bin src/cddl src/contrib src/crypto src/etc
src/games src/gnu src/include src/krb5 src/lib src/libexec src/release
src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin
src/usbin world/base world/dict world/doc world/manpages

The following components of FreeBSD do not seem to be installed:
world/catpages world/games world/info world/proflibs

Does this look reasonable (y/n)?

So I said yes and it is busy downloading the patches. Once this download is complete I am unsure how to proceed. I *know* I need to update the kernel manually before running freebsd-update install but am unsure how this is done?

Do I just:

Code:
cd /usr/src
make KERNCONF=ALPHA kernel

ALPHA is the name of my custom kernel. :) Will this update the kernel manually and enable me to proceed (safely) with the next next step in upgrading to 8.2 with:
Code:
freebsd-update install
 
That should be it, yes. I'm assuming you have a generic kernel in /boot/GENERIC. That's the one freebsd-update updates automatically. Any custom kernel needs to be built from the sources that freebsd-update updated for you (that's the src/* stuff in the output).
 
No, when using freebsd-update you must build your custom kernel from the source tree maintained by freebsd-update. That's the only way to keep userland and kernel in sync. As far as the binary update part of freebsd-update goes: it only works with/on the GENERIC kernel, but as far as the source code update part of freebsd-update goes: that's what you build your custom kernel from.
 
@Dutch,

From the handbook:
Unless the default configuration in /etc/freebsd-update.conf has been changed, freebsd-update will install the updated kernel sources along with the rest of the updates. Rebuilding and reinstalling your new custom kernel can then be performed in the usual way.
So, what you say is what the handbook also says. But I wonder why updating the source via cvs is not the proper way in this case.
 
Thanks to everyone for their amazing help. I updated my system this evening to 8.2-RELEASE and am still running with my custom kernel. I did come across an error with my:
Code:
/etc/mail/mailer.conf

On lines 3 and 5 it had put some ====== on a line and this caused mail being delivered to my domain to bounce. I simply commented these lines out and all works fine now!

Hope theres not more of these lurking within the new version...:e
 
gkontos said:
@Dutch,

From the handbook:

So, what you say is what the handbook also says. But I wonder why updating the source via cvs is not the proper way in this case.

Because then your source tree will be out-of-date with your installed binaries, and building a kernel from there has the potential to break things.

If you use freebsd-update, then stick with freebsd-update to manage your sources.

If you use csup/svn to manage your source tree, then use the buildworld cycle to update.

Don't mix the two.
 
phoenix said:
Because then your source tree will be out-of-date with your installed binaries, and building a kernel from there has the potential to break things.

If you use freebsd-update, then stick with freebsd-update to manage your sources.

If you use csup/svn to manage your source tree, then use the buildworld cycle to update.

Don't mix the two.
I never use freebsd-update because at the moment my desktop runs 9-Current, my SOHO server 8-Stable and a production VPS that I own 8.2-Release but with a couple of jails as well.
My question was sort of rhetorical. And still I am confused. Say, you follow a release and you choose to upgrade binary, via freebsd-update. That procedure should bring your source tree identical to a cvs update with a release tag. Am I missing something here ?
 
If you use freebsd-update to update to 8.2-RELEASE, then yes, the source tree for that system will be the same as one using tag=RELENG_8_2_0_RELEASE.

If you update your system using freebsd-update to get some patches to 8.2-RELEASE, the source tree will no longer be the same as the one above.

And, depending on when you do the freebsd-update, compared to when you do a csup run, the source tree for freebsd-update may or may not be the same as the one for tag=RELENG_8_2.

However, if you upgrade using freebsd-update, the binaries installed on your system will exactly match the source tree.

And, if you upgrade your system using csup/buildworld, your binaries will exactly match the source tree.

If you upgrade via freebsd-update (getting 8.2-RELEASE-p1), then csup the source tree using tag=RELENG_8_2 (getting 8.2-RELEASE-p4), then install a custom kernel ... your kernel sources (and thus kernel) will be newer than your installed binaries, and bad things may happen. In theory nothing bad should happen, but the possibility is there.

If you are going to use the csup/buildworld method (compiling from source), then only use that to keep kernel/userland/sources in sync.

If you are going to use freebsd-update (precompiled binaries), then use only that to keep kernel/userland/sources in sync.

It's the same for mixing pre-compiled binary packages and using the ports tree. While you can mix and match the two, eventually bad things will happen. Sticking to one (packages) or the other (ports) will save you headaches down the line.
 
@phoenix,

I agree with you that one should stick to either binary or sources, especially regarding ports versus packages.
However, if I choose to follow the RELEASE branch and a security update regarding the kernel comes out, my source tree should be the same regardless if I update them with csup or freebsd-update. (Release tag is assumed in this example)
Now, if freebsd-update could be used to track stable as well, then yes it would be impossible to much the source tree.

I also believe that someone who chooses to compile their own kernel should probably go through the world + kernel procedure given the fact that most modern hardware don't need more than an hour for this.
If I had to update a lot of boxes with customized kernel then I would consider using my own freebsd-update server.
 
Back
Top