Update 2.4.3.a.20180302.1018 breaks installation

A Former User

During package update get syntax error in /etc/rc.bootup then system fails to configure and falls to login prompt.

Error: Parse error: syntax error, unexpected 'conf_path' (T_STRING) in /etc/rc.bootup on line 88

Screenshot of console with error after upgrade attached.
VirtualBox_pfSense_2.4.3.a.20180302.1018_broken.png

jjstecchino

There are 3 offending places on /etc/rc.bootup:

around line 88:

/* Reinstall of packages after reboot has been requested */
if (file_exists('{$g['conf_path']}/needs_package_sync_after_reboot')) {
	touch('{$g['conf_path']}/needs_package_sync');
	@unlink('{$g['conf_path']}/needs_package_sync_after_reboot');
}

around line 94:


/* Triggering of the initial setup wizard after reboot has been requested */
if (file_exists('{$g['conf_path']}/trigger_initial_wizard_after_reboot')) {
	touch('{$g['conf_path']}/trigger_initial_wizard');
	@unlink('{$g['conf_path']}/trigger_initial_wizard_after_reboot');
}

and around line 378:

/* Resync / Reinstall packages if need be */
if (file_exists('{$g['conf_path']}/needs_package_sync')) {
	mark_subsystem_dirty('packagelock');
	if (package_reinstall_all()) {
		@unlink('{$g['conf_path']}/needs_package_sync);}
	clear_subsystem_dirty('packagelock');
}

The syntax error is that single quote were used where double quotes are required. The correct statements are as follow:

line 88:

/* Reinstall of packages after reboot has been requested */
if (file_exists("{$g['conf_path']}/needs_package_sync_after_reboot")) {
	touch("{$g['conf_path']}/needs_package_sync");
	@unlink("{$g['conf_path']}/needs_package_sync_after_reboot");
}

line 94:

/* Triggering of the initial setup wizard after reboot has been requested */
if (file_exists("{$g['conf_path']}/trigger_initial_wizard_after_reboot")) {
	touch("{$g['conf_path']}/trigger_initial_wizard");
	@unlink("{$g['conf_path']}/trigger_initial_wizard_after_reboot");
}

line 378:

/* Resync / Reinstall packages if need be */
if (file_exists("{$g['conf_path']}/needs_package_sync")) {
	mark_subsystem_dirty('packagelock');
	if (package_reinstall_all()) {
		@unlink("{$g['conf_path']}/needs_package_sync");
	}
	clear_subsystem_dirty('packagelock');
}

To restore a functioning system you can login using the physical console and change the /etc/rc.bootup as above.
I am attaching the corrected file as well

rc.bootup.zip

luckman212

thanks for this!
saved me a few hours of mucking around.

FWIW here's the offending commit
https://github.com/pfsense/pfsense/commit/20f8233d2c274d454c90f67f15d9df8bafb97b7b

and the fix
https://github.com/pfsense/pfsense/commit/58a2ba621c390362170aa2e377e4b41c8fdce1c6

2.4.3.a.20180302.2118 contains the fix.

edit: I think I found one more spot
https://github.com/pfsense/pfsense/pull/3909/commits/3ef5904edb6ef1887949ed43b5a652af6221f9fe

jjstecchino

Last update I can see on my box is 2.4.3.a.20180302.1855. The one you mentioned is 2.4.3.a.20180302.2118 which is few hours later, How comes I cant see it?

luckman212

Not sure. Maybe there are some mirrors that aren't updated. Should show up soon.

w0w

I have installed 2.4.3.a.20180302.1855 and I don't see any errors on start, but now 2.4.3.a.20180303.1129 is available already.

Hugovsky

2.4.3.a.20180303.2038 with clean install with same problem.

Edit: Not exactly the same error. This appears at gui:

Parse error: syntax error, unexpected 'conf_path' (T_STRING) in /usr/local/www/wizard.php(194) : eval()'d code on line 1

luckman212

Yes, see my above post. I submitted PR#3909 to fix that, but it hasn't been merged just yet (should be soon). For now, you can manually edit /usr/local/www/wizards/setup_wizard.xml and change the outer quotes in L37+38 to double-quotes as shown in the commit.

Element2

I had this same problem the other day with the same revision. My box most likely encountered this same error. And it seemed to have dropped the config file.

This simplest fix I found for this was manually assigning the LAN and WAN interfaces from the shell. At that point I was able to regain local access to my gateway. And then I just simply updated to the patched development build in the repository and reloaded my working config file.

Seemed a bit faster then manually going in with nano and applying the patch.

Let me know if this works for anyone else, although I suspect only a few of us applied the revision causing this issue.