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

H

Hanky-panky

Guest
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?
 
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.
 
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.
 
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:
Code: 
<<<<<<<<<<<<<<<<
{some code}
---- 
{new code}
>>>>>>>>>>>>>>>
If those are left in it would definitely cause problems.
 
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.
 
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.
 
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.
 
Last edited:
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.
Click to expand...
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.
 
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.
 
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.
Click to expand...
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.
 
Few quotes from the Handbook at https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html:

Code: 
# 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.
Click to expand...

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.
 
kpa said:
Few quotes from the Handbook at https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html:

Code: 
# 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



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.
Click to expand...
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
Code: 
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.
 
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.
 
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
 
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:

image.png


Then we apply ALL the latest security and errata patches:

image.png


image.png


So now that we have a fully patched system:

image.png


We can safely proceed with the actual UPGRADE:

image.png
 
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.
 
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.
Click to expand...

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.
 
gkontos said:
PS. There is a conspiracy theory behind how a FreeBSD machine boots.
Click to expand...
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.
 
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:

- 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.
Click to expand...
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.
 
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.
Click to expand...

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.
Click to expand...

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.
 
  • Thanks
Reactions: Oko
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.
Click to expand...
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.
 
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.
Click to expand...

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.
 
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
Code: 
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.
Click to expand...
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.
Click to expand...
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?
 
You must log in or register to reply here.
Back
Top