Advantages of reinstalling FreeBSD vs. using freebsd-update

Grell

Grell

Hello, I want to know is there is an advantage in just backing everything up and reinstalling FreeBSD once FreeBSD 11.0 comes out, or using the freebsd-update tool. I have already used the tool once to go from 10.2 to 10.3, although it is 10.3-RELEASE-p4 where I understand that p4 refers to the patch level. I am assuming that when I go from 10.3 to 11.0 it will again have a patch level to it. Would it be better to just reinstall and avoid all these cumbersome patches or does it really not matter? Thanks.
 
Grell said:
I want to know is there is an advantage in just backing everything up and reinstalling FreeBSD once FreeBSD 11.0 comes out
Click to expand...

Backing everything up is always a good practice, specially when performing a major version upgrade. However, I don't see neither the need nor reasons of reinstalling FreeBSD just to perform an upgrade.

That "format & reinstall" is a Windows thing, not a unix one.

Grell said:
I have already used the tool once to go from 10.2 to 10.3, although it is 10.3-RELEASE-p4 where I understand that p4 refers to the patch level.
Click to expand...

Exactly.

Grell said:
I am assuming that when I go from 10.3 to 11.0 it will again have a patch level to it. Would it be better to just reinstall and avoid all these cumbersome patches or does it really not matter? Thanks.
Click to expand...

When you will upgrade, you will get FreeBSD 11-RELEASE, the patching level will be zero (unless you'll upgrade when a security patch is available). Moreover, you don't need to install all the security patches that will be released for 10.3-RELEASE to upgrade to 11-RELEASE.
 
If backing up your configurations and reinstalling is something you can do in an hour, then there's no advantage to either method. In-place updates are useful for those who don't have a couple days to take a server bank offline for testing or potentially need to restore terabytes of data.
 
I can't help wonder what triggered your question? Unlike Windows which keeps gobbling up more and more disk space after each (minor) upgrade you have less to worry about that on FreeBSD. Sure; some things might become a bit larger, but it's not as if we're talking about tens of gigabytes expansion.

But if you want to keep more control over the whole upgrade process then there's yet another way to upgrade instead of using freebsd-update: compiling the source tree yourself and performing the upgrade manually.

This may be a bit daunting at first, I still remember the first time I did this, but it can be a very rewarding experience. You'll get pretty much full control over what parts you want to include in the new system and which are best left out (see src.conf(5)), you can tune and/or optimize the kernel to fully match your system. Even if you don't want to remove things it can still be useful to add functionality (for example IPSec support or resource limiting support). A good read on this is Chapter 8 of the Handbook.

Now, please keep in mind that I'm biased. At one point I started using the source tree and liked it so much that I never looked back at freebsd-update again (it's not even installed anymore on any of my FreeBSD environments). But that's not saying that freebsd-update can't cope: it does a perfect job on upgrading and will even allow you to roll things back if needed. You also don't have to worry about "bulk" getting in your way.

But if you prefer full control then I'd definitely recommend to look into rebuilding the world.

A good source of information on upgrading FreeBSD is chapter 23 of the handbook. It might give you some good impressions on all this.
 
I had a quite unpleasant experience with freebsd-update doing major upgrades. See the thread below for relevant discussion (note that in the thread another user reported similar problems):

https://forums.freebsd.org/threads/49199/#post-279429

I don't think I'll trust freebsd-update on a major upgrade. I guess I haven't really learned how to upgrade FreeBSD properly; almost every major upgrade for me ended up being done through reinstalling the system completely. Somehow it is just the easiest and the cleanest, even though deep in my gut, I always felt I was not doing the right thing.
 
kpa said:
There is work going on for using pkg(8) to package the base system but it's not finished yet.
Click to expand...
I sure hope that remains optional because I can see a lot of risky things there. Especially if we're talking dependencies and packages using wrong dependencies. One of the key features, in my opinion, is that the base system is kept separate; out of the dependency checks and therefor can't be easily affected by a package maintainer who messes up some package dependencies.

Something which I've seen happening with Linux on some occasions (but a very long time ago) where system packages got removed because of a fluke dependency.

Anyway, thanks for the tip, I got something to read up on.
 
That's where the development is heading to regardless and very likely it's not going to be optional on release versions. I'm sure it's going to be done in a way where the base system packages can never depend on ports/packages, only the other way. This would prevent the kind of chaos you have on Linux distros as you described.
 
ShelLuser said:
One of the key features, in my opinion, is that the base system is kept separate ... Something which I've seen happening with Linux on some occasions (but a very long time ago) where system packages got removed because of a fluke dependency.
Click to expand...

The base system is still being kept separate. FreeBSD design and development aren't fundamentally changing; just some aspects of base system distribution will be changing. (The system is already "packaged" in tar archives for use in jails and the installer, so it's not a huge shift in approach). A key part of the PkgBase project is that the build scripts are being rewritten to build the system into packages that will be installed with pkg(8) rather than install(1), and pkg will be updated to manage base-system and third-party packages separately in order to prevent precisely the problem that worries you. It's one of the reasons the change hasn't been finalized. That sort of caution and forethought is what made me fall in love with and switch to FreeBSD. :)
 
ANOKNUSA said:
A key part of the PkgBase project is that the build scripts are being rewritten to build the system into packages that will be installed with pkg(8) rather than install(1), and pkg will be updated to manage base-system and third-party packages separately in order to prevent precisely the problem that worries you.
Click to expand...
Well, one of the problems. There are several caveats which worry me. The obvious one being the already mentioned dependency hell, another would be accidental pkg commands which suddenly start to affect the base system; # pkg delete -x mail for example resulting in both procmail and sendmail getting removed. That could also be prevented by the separation, but until we know exactly how that separation is going to work this is still a cause of concern for me.

Finally the possible overhead. Right now it's relatively easy to handle all the system files during an upgrade using mergemaster. I could imagine that this also gets changed and that patching will also be done through pkg and I'm not too sure I'd be a fan of that either. One of the advantages now is that you can sort out dozens of config files in a relatively short time.

If you're relying on packages which get installed one by one then I could also imagine a setup where the config file updates only take place at the time a package gets installed and only for those related to that package. That could also make the whole process more tedious. After all; it's for that reason why we got # make config-recursive for handling port configurations (or by using portmaster).

Unless of course you'd combine all config files into one package, but that also sounds very counter productive to me ;)

Obviously all of this is speculation on my part, sure, but even so these are some things which worry me. I suppose time will tell :)
 
You must log in or register to reply here.
Back
Top