# /etc/rc: Error Usage load load_rc_config name. Can't boot after upgrade to 11-RELEASE



## Hanky-panky (Nov 11, 2016)

Like in the thread title.

I upgraded my system very many time and this never happened. I googled then I still can't have any idea about how I should try to fix this problem. I'm stuck out of my system by this.

Even replacing /etc folder with /etc backup folder I made before upgrade help me to boot the system.

Can you guys help?


----------



## SirDice (Nov 11, 2016)

There's either a mistake in rc.conf or a botched mergemaster(8). In either case, you need to boot to single user mode to be able to fix it. This requires console access, but it can also be done using a remote KVM or IPMI.


----------



## Hanky-panky (Nov 11, 2016)

Hello Sir and thanks for your interest. I've been familiar to single user mode and I always booted there. rc.conf is the same I had before 11.0-RELEASE, pretty simple, no NFS stuff. And working fine because before second upgrade stage from 10.3-RELEASE, 11.0-RELEASE just installed kernel booted pretty fine. I upgraded via freebsd-update(8).

The machine is now out of order, lucky I do have a backup I did before upgrade, then I will try to fix it myself before rebuilding backup, if you guys here can't help, I have no idea what happened.

As I said in my previous message, I replaced /etc with /etc backup without any luck, I replaced every /etc and subfolder instance with the backup, so also /etc/rc.d and /etc/rc. With my surprise the system still didn't boot with the same error message.

Any other help or idea?

PS: I do have enough skills to remount file system read and write so there is no problem for me accessing the system in single user mode. Once I tried to boot the system with minimal rc.conf and had a look to whats inside rc.d folder and then replace /etc with /etc backup I'm totally out of any possible idea.


----------



## SirDice (Nov 11, 2016)

The freebsd-update(8) does a mergemaster(8) run automatically. But sometimes it can't figure out what to do when files are locally changed. In which case you end up with files containing something like this:

```
<<<<<<<<<<<<<<<<
{some code}
---- 
{new code}
>>>>>>>>>>>>>>>
```
If those are left in it would definitely cause problems.


----------



## Hanky-panky (Nov 12, 2016)

I give up. After a quick check of rc.d folder apparently I didn't find anything broken in configuration files. Also becouse if you remember, I always load the /etc backup before. I need my machine back, so I simply rebuild the backup I made before upgrade. I can't loose hours becouse mergemaster (or whatever, I simply accepted defaults) is broken.

This thread is NOT solved.


----------



## Hanky-panky (Nov 12, 2016)

I confirm this is a BUG in freebsd-update/mergemaster (where?). I tried the procedure in two DIFFERENT other systems with the same results: fail at reboot with the same error message.


----------



## gkontos (Nov 12, 2016)

You can always file a PR. However, keep in mind that this is something that only affects you. I have successfully upgraded quite few machines from 10.3-RELEASE to 11.0-RELEASE using freebsd-update.
Maybe you can describe how did you upgrade and from what version, so we could help you with your problem.


----------



## Hanky-panky (Nov 12, 2016)

gkontos said:


> You can always file a PR. However, keep in mind that this is something that only affects you. I have successfully upgraded quite few machines from 10.3-RELEASE to 11.0-RELEASE using freebsd-upgrade.
> Maybe you can describe how did you upgrade and from what version, so we could help you with your problem.


Hello and thank you for your reply. All the three systems failing to upgrade are upgrades from 10.3-RELEASE like yours. I always accepted reasonable defaults offered by mergemaster and the rest is just what I explained in previous postings.

Sorry for basics formatting but I actually post using my iPhone. Thank you.

PS Google or FreeBSD handbook doesn't help me to find this file name load_rc_config complain about.


----------



## kpa (Nov 12, 2016)

Please try to make a repeatable test case for the problem report by specifying the exact starting point of the upgrade, version and patch level and how the system was initially installed and with the update/upgrade history.  If you just report that the failure happens when a 10.3 system is upgraded to 11.0 it's very very little information and your PR won't go far.

Another thing is that make it very clear if the systems were upgraded by freebsd-update(8) or by using the source based upgrade. This is very important because freebsd-update(8) does not use mergemaster(8), it uses its on configuration file merge method.

I have upgraded numerous 10.X systems including 10.3 to 11.0 using the sources and I so far haven't run across any such issues in merging the configuration files.


----------



## Hanky-panky (Nov 12, 2016)

kpa said:


> Please try to make a repeatable test case for the problem report by specifying the exact starting point of the upgrade, version and patch level and how the system was initially installed and with the update/upgrade history.  If you just report that the failure happens when a 10.3 system is upgraded to 11.0 it's very very little information and your PR won't go far.
> Another thing is that make it very clear if the systems were upgraded by freebsd-update(8) or by using the source based upgrade. This is very important because freebsd-update(8) does not use mergemaster(8), it uses its on configuration file merge method.
> 
> I have upgraded numerous 10.X systems including 10.3 to 11.0 using the sources and I so far haven't run across any such issues in merging the configuration files.


Hi and thankx foe your interest.

Sir Dice said here in this thread, as you can read, that freebsd-uodate DO USE mergemaster. Now I don't have enough clue to understand if I should believe you or him.

The point to help solving this problem would be to lnow how FreeBSD boot process works or to have less cryptic error message like the one I do experienced on this issue.

Google and FreeBSD handbook didnt be my friends on the subject.


----------



## kpa (Nov 12, 2016)

Few quotes from the Handbook at https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html:


```
# When upgrading to a new FreeBSD release, files which match MergeChanges
# will have any local changes merged into the version from the new release.
MergeChanges /etc/ /var/named/etc/ /boot/device.hints
```



> List of directories with configuration files that freebsd-update should attempt to merge. The file merge process is a series of diff(1) patches similar to mergemaster(8), but with fewer options. Merges are either accepted, open an editor, or cause freebsd-update to abort. When in doubt, backup /etc and just accept the merges. See Section 23.6.4, “Merging Configuration Files” for more information about mergemaster.



If you look at the /usr/sbin/freebsd-update shell script (yes, it's a shell script) you'll see that it has no references to mergemaster(8), it uses its own internal merge tool instead.


----------



## Hanky-panky (Nov 12, 2016)

kpa said:


> Few quotes from the Handbook at https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html:
> 
> 
> ```
> ...


So I'm not lonesome with this problem... And not solved here too.

https://forums.freebsd.org/threads/58108/

I personally found it is a problem with rc.subr, I think one of the first files read during bootup after loading the kernel, if not the first. He die at the section 
	
	



```
load_rc_config()
local _name _rcvar_val _var _defval _v _msg _new _d _name=$1
if [ -z "$_name" ]; then
err 3 'USAGE: load_rc_config name'
```
Here where the error message in this thread subject come from.

It is like if it is unable to get the correct env from the bootup shell. Now I don't have any idea how to fix it, then considering I can reproduce this on FOUR different machines, isn't it a bug?

BTW, I do not have a freshly installed 11.0-RELEASE machine to check with, then the OP of the other thread said the rc.subr is radically different from the upgraded one.

So now, people here, said they `freebsd-update` a lot of machines without any issues. Sound really, really strange to me.


----------



## kpa (Nov 12, 2016)

Yes the problem is clear and it's that file (and possible some other files as well) is not being upgraded properly to 11.0 versions,  I'm not contesting that at all. Why it happens requires some more serious investigation and I'm just pointing out that the source based upgrade method and the tools used in it are not involved in this case.


----------



## Hanky-panky (Nov 14, 2016)

Hehehehe THREE other virtual machines upgraded with freebsd-update failed miserably at rc.subr bug. I'm NOT an expert, so I pretty much see NO ONE IN THIS FORUM IS becouse no one knows how the system boot, considering no one been helping me and others with this nasty problem.

For now I upgrade my production machine, the first failing freebsd-update, using world and the real mergemaster (and yes borther SirDice, Kpa is right, freebsd-update do not use mergemaster but some crazy, buggy, ridicolous tool to merge the conf files) and I had no problem merging and personalizing the configuration files using the mergemaster with -iF option, the one I do prefer, offering me total control on them.

BTW, freebsd-update in also buggy in another way: I've been unable to upgrade a 10.2-RELEASE machine to 11.0-RELEASE becouse it said complained about some crc fail. Upgrading to 10.3 before, I've been able to go ahead with 11 with no more errors but, obviously, the rc.subr failing.

Considering no one knows how FreeBSD boot process works on here, I will still study the problem, /etc/rc call /etc/rc.subr and I'm pretty much sure injecting a working 11 rc.subr in the failing process, will do the trick.

Then for now I'm not shy to say: freebsd-update with upgrade option is pure trailer trash.


PS: sorry for no formatting: I'm on my trusty iphone


----------



## gkontos (Nov 14, 2016)

Hanky-panky said:


> BTW, freebsd-update in also buggy in another way: I've been unable to upgrade a 10.2-RELEASE machine to 11.0-RELEASE becouse it said complained about some crc fail.



You obviously missed this errata.


----------



## gkontos (Nov 14, 2016)

This is by no means a HOW-TO!!! I just wanted to show that during a major upgrade we need to follow all the instructions if we want to get the required result.

First step. We install a FreeBSD 10.3-RELEASE:







Then we apply ALL the latest security and errata patches:











So now that we have a fully patched system:






We can safely proceed with the actual UPGRADE:


----------



## gkontos (Nov 14, 2016)

Continued....











So that we can eventually get there:






Always go through the latest errata and security advisories. Never just UPGRADE a system that is not patched.


----------



## Hanky-panky (Nov 14, 2016)

Ok for the 10.2-RELEASE upgrade path, then I can't see any errata for the rc.subr BUG and yes it is a big one considering just for fun I'm now at FIFTEEN MACHINES INVOLVED, and worst of all ZERO machines had a success!!! I talk about very old installs, REAL installs, all 10.3-RELEASE, not machines just built for testing this rc.subr problem...

Ps: and still no one here seems to have a clue about how a FreeBSD machine do boot, or he/she don't want to share it.


----------



## gkontos (Nov 14, 2016)

Hanky-panky said:


> Ok for the 10.2-RELEASE upgrade path, then I can't see any errata for the rc.subr BUG and yes it is a big one considering just for fun I'm now at FIFTEEN MACHINES INVOLVED, and worst of all ZERO machines had a success!!! I talk about very old installs, REAL installs, all 10.3RELEASE, not machines jist build for testing this rc.subr problem...
> 
> Ps: and still no one here seems to have a clue about how a FreeBSD machine do boot, or he/she don't want to share it.



You really don't make any sense. I just showed you that freebsd-update can successfully upgrade a machine to 11.0-RELEASE.

Lessons *not learned* today:

- Always update your machine to at least the latest patch level before the RELEASE you want to upgrade
- Don't mix freebsd-update and mergemaster.

You could have saved yourself a lot of time if you just followed the rules.

PS. There is a conspiracy theory behind how a FreeBSD machine boots.


----------



## Hanky-panky (Nov 14, 2016)

gkontos said:


> PS. There is a conspiracy theory behind how a FreeBSD machine boots.


No, no conspiracy, people simply doesn't know, like me. Or if they knows, and I doubt it, they don't wanna help. Nothing more and nothing less.


----------



## Hanky-panky (Nov 14, 2016)

gkontos said:


> You really don't make any sense. I just showed you that freebsd-update can successfully upgrade a machine to 11.0-RELEASE.
> 
> Lessons *not learned* today:
> 
> ...


Lessons LEARNED today

1) Always did it, but once. And apparently didn't make any difference.

2) Never mixed mergemaster with freebsd-updates. I did mergemaster with great success story as usual when I upgraded a failing machine via make buildworld.

Lessons YOU wanted to learn

1) freebsd-update seems to be an highly unrealable tool and it is not your or my fault, it just is. Considering we do not pay any money for it, it is ok like this.

About the time: I didn't spent a lot of time. In case of real machine, I reinstalled the backup. In case of other try just to demonstrate freebsd-update is mostly bugged I didn't spent any time, they've been done in retail time during other occupations. I have better things to do.


----------



## gkontos (Nov 14, 2016)

Hanky-panky said:


> Lessons YOU wanted to learn
> 
> 1) freebsd-update seems to be an highly unrealable tool and it is not your or my fault, it just is. Considering we do not pay any money for it, it is ok like this.



You can always stick with Microsoft, pay the money and feel more dumb when things break. freebsd-update is as much reliable as the administrator who uses it.



Hanky-panky said:


> About the time: I didn't spent a lot of time. In case of real machine, I reinstalled the backup. In case of other try just to demonstrate freebsd-update is mostly bugged I didn't spent any time, they've been done in retail time during other occupations. I have better things to do.



In case you have not realized it yet. You have cost the company that you work, a lot of money just because you did not read the upgrading instructions.


----------



## Hanky-panky (Nov 14, 2016)

gkontos said:


> In case you have not realized it yet. You have cost the company that you work, a lot of money just because you did not read the upgrading instructions.


Again! is it my fault if freebsd-update is buggy? Can you read, brother?

PS: I like Microsoft as much as I like FreeBSD Foundation or Apple. I do use all this stuff and I deep respect all of them in the same manner.


----------



## gkontos (Nov 15, 2016)

Hanky-panky said:


> Again! is it my fault if freebsd-update is buggy? Can you read, brother?
> 
> PS: I like Microsoft as much as I like FreeBSD Foundation or Apple. I do use all this stuff and I deep respect all of them in the same manner.



Maybe I should not reply but I can't tolerate stupidity. So, my apologies to everyone for being sarcastic. 

I have spent one hour for you just to prove that freebsd-update is not buggy. I made a fresh installation of FreeBSD 10.3-RELEASE and walked you through the steps of properly upgrading it to 11.0-RELEASE.  

Still, you seem to insist that there is a bug somewhere. The only bug is in your head I am afraid. I recently do less technical stuff than I would like because my job forces me to guide new sysadmins. In your case you would be fired. Not because you did something wrong but because you don't want to understand what you did wrong.


----------



## tobik@ (Nov 15, 2016)

Hanky-panky said:


> I personally found it is a problem with rc.subr, I think one of the first files read during bootup after loading the kernel, if not the first. He die at the section
> 
> 
> 
> ...


So add an `echo "fubar: $_name"` (or set rc_debug="YES" in /etc/rc.conf, assuming it doesn't die before reading that file) to see on which file it chokes.

However the snippet you posted looks nothing like the version in FreeBSD 10.3's or 11.0's /etc/rc.subr. In fact it's the one from FreeBSD 9.3.



Hanky-panky said:


> Even replacing /etc folder with /etc backup folder I made before upgrade help me to boot the system.


Don't just copy /etc from an old system to a newer one. That seems like a recipe for disaster.  I assume you cherry picked what files you copied instead of blindly copying them all?


----------



## Hanky-panky (Nov 16, 2016)

Hi Tobik and thank you for your competent help.

Yep, I did try in the first the system debug option you suggest, then like you said it wasn't usefull becouse the system die before processing rc.conf.

The boot order of the files, no one here seems to know about this very important aspect is: rc, rc.subr, rc.conf, obviously each one of this file present and processed also in the defaults subfolder, exactly before in defaults and then in /etc folder.

Related with the /etc copy I did try everything, so both the useless and like you said dangerous blind copy and some cherry picked one, this one for now limited by the difficult to access the system when it hangs with still anything loaded.

I should phisically exyract the disk, connect it to a working machine considering usb subsystem wont work for me in this limited single user mode. Then, like we all here posting in this thread before you, we are not experts, so no one was able to highlight this boot order.

When I do have some little time, considering I still have the backup of the failing machines, I will cherry pick rc and rc.subr from a working 11 machine and copy it to a broken machine and I pretty much I'm sure it will work. I will also diff broken and working files to properly understand code changes.

I want to know whats went wrong and you offered me a GREAT hint: that snippet from rc.subr was extracted from a 10.3 machine upgraded I think from 8 to 10.3 in rolling mode during the years then you said it is a 9.3 one so probably here where is the problem: been not correctly upgraded by vintage software like freebsd-update.

So it is now clear that rc.subr or maybe rc too or rc and rc.subr went upgraded to 11 in a not compatible way with older OS versions.

In my case,  considering I'm at 19 not correctly upgraded machines, that sort of mergemaster implemented in freebsd-update is unable to correctly upgrade those files.

Last night also my FreeBSD based router/NAS crashed badly at rc.subr like all the other machines.

Lucky I'm the backup type of guy, so it was just a matter of time to have it back and running.

For all the three production machines I'm up and running at 11 via source upgrade then I'm still really interested in see which file fail in buggy freebsd-update.


Ps: sorry for no formatting. I type on my beloved iphone.


----------



## Hanky-panky (Nov 17, 2016)

Hanky-panky said:


> When I do have some little time, considering I still have the backup of the failing machines, I will cherry pick rc and rc.subr from a working 11 machine and copy it to a broken machine and I pretty much I'm sure it will work. I will also diff broken and working files to properly understand code changes.



Finally FIXED by me, obviously NOT solved becouse the bug is still there. I will fill a PR when I do have some little time.

As I was wondering it was dumb `freebsd-update` messin with configuration files on NINETEEN in my case failed upgrades.

What I did? Simply booted the 11-0-RELEASE minimal install cd, mounted local file systems of the failed machines and simply copy the /etc/rc.subtr to local mounted file system /mnt/etc.

Rebooting the system was enough to... discover how many others mess dumbly perverted `freebsd-update` makes!

The system this time passed the fixed rc.subr then it doesn't still boot and this time complained iabout wrong errors in /etc/defaults/rc.conf.

Rebooted once again in single user mode, remounted file systems RW and edited with my fav `ee` editor(I always deeply hated stupid `vi` and found how very many mess of <<<<<<<<  >>>>>>> that stupid "mergemaster like" did in that file. I personally and manually correctly edited the file, saved it and just typing exit was enough to boot the system.

Yes, the system booted fine then the debug option I do activated showed me how many (like over 10) messed config files I still had to edit to have a perfectly working system. Dumb "mergemaster like" tool in dumb `freebsd-update` makes so many mistakes even in another vital file like /etc/sysctl.

I hope with this definitive post to really help people facing this problem.

In my experience `freebsd-update` it seems only partially usefull updating between patches and minor upgrades, not surely to upgrade between two majour OS upgrades.

That's all and thankx to no one but myself and tobik..[/FILE]


----------



## Terry_Kennedy (Nov 18, 2016)

Hanky-panky said:


> As I was wondering it was dumb `freebsd-update` messin with configuration files on NINETEEN in my case failed upgrades.


I don't know if this post will be of any help to you because it seems your mind is already made up, but perhaps it will help someone else...

There's a famous quote about "doing the same thing over and over and expecting different results". I can understand why you might try upgrading a second or possibly even a third system to see if it has the problem, but actually rendering 19 systems non-bootable?

I understand the frustration of not having a part of the system perform the way you expect, and I've run into places where incorrect assumptions on the part of a committer led to unexpected results. The most recent one I can remember is that building sysutils/lsof on (at least) early FreeBSD 10.x releases would fail with an inexplicable error if the make.conf(5) file didn't exist. It could be empty, but it had to be there or you'd get the error. There's no requirement that a system have an /etc/make.conf file, a new install didn't provide one, and almost everything worked fine without it. But the developer(s) either made an assumption that the file always exists, or more likely didn't realize they'd introduced an unwanted dependency. If I run into a "it works for everybody else" scenario like that, my first thought is "what did I do wrong", not "gee, those developers screwed up". I asked the developers what I was doing wrong, and after they and I couldn't find anything, we eventually discovered the unexpected dependency.

I believe that one of the sticky posts in the guidelines area mentions that these forums are mostly for user-to-user interactions. While there are some developers on the forums, not all parts of the system are represented and it isn't possible to force developers to participate here [insert witty "herding cats" comment here]. If you're trying to get the attention of a developer, one of the mailing lists or a correctly-targeted PR (to let auto-assignment work) is probably your best bet.


> Rebooting the system was enough to... discover how many others mess dumbly perverted `freebsd-update` makes!


I don't use freebsd-update(8), and there are other major parts of FreeBSD I don't use (for example, I don't use the installer). However, I did follow its development with interest and I hope I can speak cogently about it. Here goes:

freebsd-update's update "blobs" (for lack of a better term) are done by comparing a vanilla install of version A with a vanilla install of version B. If a file didn't change, freebsd-update doesn't provide a new copy. Likewise, it doesn't checksum a user's file to look for missing / incorrect files. It just provides the files needed to get from A to B. In some cases, that involves updates to a file that the user has likely edited, in which case it assists with merging the new version's file with the customized user file. It can't always determine what the user intended, so sometimes manual editing is necessary.

If you change part of the system that freebsd-update doesn't expect, then all bets are off. Most people who make those types of changes also build from source instead of using freebsd-update. If someone decides that /bin/sh should actually be a symlink to /bin/tcsh because all "proper" shell scripts should have a shebang so they always use the right shell, freebsd-update won't save you.


> In my experience `freebsd-update` it seems only partially usefull updating between patches and minor upgrades, not surely to upgrade between two majour OS upgrades.


You probably know this, but the "-STABLE" in a FreeBSD version indicates that interfaces shouldn't be changed in an incompatible way during the life of the major version. That isn't always honored, but it is a definite goal. Creating an update utility that lets you cross major versions is quite an accomplishment (even if it didn't work for you). There are often compatibility shims left in place to ease migration from release A.something to B.something. They generally go away by the time release C.something comes along. You may be running into something like that if your systems were originally FreeBSD 9.x or older.

A case could be made that a desirable tool would be one that checked all the configuration files for the correct SVN revision and SHA1 hash for the "before" version, in order to prevent problems like the one you encountered. The fact that such a tool doesn't exist might be due to lack of interest in creating it, but it is more likely due to a lack of perceived need for it.


----------



## kpa (Nov 18, 2016)

Terry_Kennedy said:


> A case could be made that a desirable tool would be one that checked all the configuration files for the correct SVN revision and SHA1 hash for the "before" version, in order to prevent problems like the one you encountered. The fact that such a tool doesn't exist might be due to lack of interest in creating it, but it is more likely due to a lack of perceived need for it.



This is not realistic as long as the system allows you to skip many versions in one go, the tool would would potentially have to know all the preceding versions to the beginning of FreeBSD's history  and also be able to decide if the files are modified which older version the modified version resembles most closely.

The real concern I have about freebsd-update(8) is that it and its documentation do a very poor job of explaining what the configuration merge process actually is and how it works. You do get it after doing it for a while but neither the manual page nor the handbook have an example run to show what it actully involves and why you should choose this way or that way when asked which option to choose.

On top of that we have two different merge tools that don't work the exact same way as already noted. OpenBSD manages the same configuration merge process with just one tool, why can't we?


----------



## Terry_Kennedy (Nov 18, 2016)

kpa said:


> This is not realistic as long as the system allows you to skip many versions in one go, the tool would would potentially have to know all the preceding versions to the beginning of FreeBSD's history  and also be able to decide if the files are modified which older version the modified version resembles most closely.


The process that creates the freebsd-update "blobs" has information on every system file for each version that freebsd-update allows you to update from. Otherwise it couldn't generate the deltas for what changed. Also, freebsd-update doesn't support all releases back to the beginning of time - it is a relatively new utility.

I just looked at the freebsd-update(8) manpage, and found this:


			
				manpage said:
			
		

> IDS - Compare the system against a "known good" index of the installed release.


So it seems that something like my proposed tool has already been implemented.


> The real concern I have about freebsd-update(8) is that it and its documentation do a very poor job of explaining what the configuration merge process actually is and how it works. You do get it after doing it for a while but neither the manual page nor the handbook have an example run to show what it actully involves and why you should choose this way or that way when asked which option to choose.


From a quick look at the documentation, I agree with you. But perhaps freebsd-update prints some useful information during the process - as I said, I've never used it.


> On top of that we have two different merge tools that don't work the exact same way as already noted. OpenBSD manages the same configuration merge process with just one tool, why can't we?


Aside from the glib "there are always more than one way to do <thing> on a Unix-like system" response, FreeBSD provides one set of tools for users who prefer to use pre-built binaries (freebsd-update, pkg, etc.) and another for users who want to "roll their own" (SVN, make kernel, portupgrade, etc.). Both of those are still command-line-based and there are a number of projects based on FreeBSD (FreeNAS, PC-BSD, etc.) which add a graphical interface as a third method. While simply duplicating the functionality of one tool and calling it something else is a waste of everyone's time, I see the benefit of having multiple tools aimed at users with varying skillsets who have different goals. Aside from people who switched over to using freebsd-update once it became generally available because they didn't want to build everything from source for each update, it seems the two groups of users (freebsd-update vs. build-from-source) are pretty happy with the system they have, and there isn't a lot of switching back and forth. A single tool that tried to be a solution for both group would probably be seen as a poorer tool than the two tools FreeBSD has now. Again, this is just supposition on my part, as I'm in the build-from-source group, haven't used freebsd-update, and don't know anyone who has.


----------



## gkontos (Nov 18, 2016)

freebsd-update is a very powerful tool but it assumes that your system files have not been altered by you. If it notices a difference it will create a:

```
<<<<<<<<<<<<<<<<
{some code}
----
{new code}
>>>>>>>>>>>>>>>
```
You have the ability to edit the file in respect. I have used it many times and it is a life saver if you have to upgrade 20 machines. I am using FreeBSD since 6.0-RELEASE and it has only been a year that I am using binary upgrades. 

Generally speaking, even if you upgrade from source, you SHOULD run a tool like IPMI or VNC, depending on the service that you have. IMHO mergemaster is more difficult to run for a newbie.


----------

