Recover config file from ISO during (re)install?
-
[quote]
Perhaps create a small 1G "disk" in the virtual environment, layout a filesystem and have a copy of the config.xml file as a "ready to go" option.
[/quote]That's exactly what I wanted to do here. Although planned, so I had all the time to figure things out and copy the config file to the correct location myself. But yes, in case of true disaster and both HA nodes fail or whatever, it would be nice be up and running in like two minutes rather than 10 when you manually need to configure network before being able to access it. Which would still be fast but still.
-
@justme2 said in Recover config file from ISO during (re)install?:
There are a vast number of lines that fly by stating something about restore option(s) not specified and then truncates the config.xml file on the freshly installed system to 0 bytes.
You have any logs from that? That function has worked well for years I'm not sure what could have changed there.
Steve
-
Grep'ing through the logs and apparently whatever process does the restore - does not write any output directly (or via syslog) to anything under /var/log. But on the console (physical monitor/keyboard) there was more one than one "screen's worth". It was a message about ?4? different options and at least one had to be specified in order to perform the restore. ie: At least one of a, b, c or d must be specified type of message. I recall "x" being one of the options. Thus, whatever process actually performs the restore is being called without a parameter and failing. Perhaps if the output from the restore process had been captured in the system log/s (as the restore/recover occurs as part of the first reboot after install, thus it should be possible to capture on the installed storage) - it would be possible to provide that information.
-
Hmm, you can try running it manually if you drop to the recovery shell from the installer and run:
/usr/libexec/bsdinstall/copy_configxml_from_usbThat should show you any errors that it hits.
-
Would need to schedule another change control (as it impacts prod services) in order to test - not sure that it would be approved until sometime after the middle of January.
Looking at the installed system, there is nothing in that directory. Any reason that the install wouldn't carry that over? (Checked a couple other firewalls that were 'upgraded' from prior versions - not "fresh" installs and they lack anything in that directory as well). If one had the script to actually review, could probably find the error that comes back (if it's in that file).
-
Yeah it's on;y in that location in the installer. Otherwise:
https://github.com/pfsense/FreeBSD-src/blob/RELENG_2_7_2/usr.sbin/bsdinstall/scripts/copy_configxml_from_usb -
@stephenw10
OK - so there's not an "x" parameter in that script. The config was NOT encrypted, so that shouldn't come into play either.Coming at it from a different angle: What in the boot process would 'grok' on the config.xml file that would output an error about restoring or reading the config.xml on the first boot >25 times? Or perhaps create this scenario on initial boot where there are no files in the backup dir? Keep in mind that this occurs as part of the initial boot (eg: after install and during the 1st actual boot on the installed media). What would actually output something about truncating the configuration?
-
The External Config Locator will try to import a config at every boot if it's attached.
https://github.com/pfsense/pfsense/blob/RELENG_2_7_2/src/etc/rc.ecl -
Will it truncate (zero out) config.xml if it thinks it is invalid? Suspect that whatever would truncate the file is closer to where the issue resides.
-
I would not expect it to. Ever. What you're seeing is odd.
