Feature #8147
closed
include a serial console file tranfer utility like "kermit" in the installer image
0%
Description
Scenario¶
- I updated from 2.3 => 2.4 (FreeBSD 11) and it went badly
- I wanted to recover my config.xml (I know I should have backed up first)
- I downloaded the 2.4 memstick installer and booted off that
- The installer gave me a lovely option (!!) to recover my config.xml from existing install
- This worked great, so I now have the file on one of the ramdisks (the installer USB is read only...could it be re-mounted read/write? I didn't try that)
How to get the config.xml off the FW box? I have serial console access only. No network. I fiddled around with getting it to recognise a second USB stick (formatted as UFS etc), lots of problems. I also tried capturing serial console output and "cat'ing" the file..but this resulted in a corrupted file.
Request¶
If the installer image recovery root prompt had access to kermit: http://www.columbia.edu/kermit/ckututor.html
or something similar, it would have been trivial to:
- connect to FW box via kermit running on laptop
- boot the installer image
- do the lovely config.xml recovery
- run kermit on the FW box (...REQUIRES kermit to be part of the installer image...!)
- use kermit "send" command to send the file back to my laptop over the serial console.
- proceed with install, get basic operation working, and then use webconfigurator or scp/ssh to re-install the recovered config.xml
- might also be nice to have kermit as one of the INSTALLED packages (or at least have it available from the pfsense package respository)
How I solved it¶
- In the end I managed to get hold of my config.xml, by booting into the semi-broken 2.3 install and saving it to USB from there (USB seemed less problematic when fully booted, rather than from installer image recovery console which has "less stuff")
- once the box was fully restored, I tried the kermit idea. I installed kermit with "pkg add ...fbsd_repo_url".. and .. it works like a charm! I had the recovered config.xml back on my laptop in minutes.
Happy to write an article on how to use Kermit for these sorts of operations (the man page is pretty scary!)
Updated by Oliver Schonrock over 6 years ago
Just found this article (I had limited internet access during recovery)
https://doc.pfsense.org/index.php/Automatically_Restore_During_Install
Pick the existing installation drive (e.g. ada0), the selection list shows the disk name, size, and filesystem type which should be enough to identify the disk
Proceed through the installation as usualThe firewall will boot off the target disk with the restored configuration.
The last point is staggering...(having just been through all the above).
How does it do that?
Does it just look for it in /tmp/config.xml (which is where it was saved if I remember correctly)?
Did I miss a message that told me that this restored config was going to "automagically get used"?
I was just happy to have the file, and then struggled to get it off the box...
Updated by Jim Pingle over 6 years ago
- Status changed from New to Closed
The automatic restore looks at the selected disk, runs a disk check, then mounts it and looks in /cf/conf/config.xml - if it finds a copy of a configuration, it copies it to a temp directory in RAM and then later on in the installer, it checks that temp directory and uses whatever configuration it finds there instead of the default stock configuration.
As for transferring a configuration over serial, there is no need to bundle a serial transfer utility into the base system. Set your serial client to log, and simply cat the old configuration file, and then edit it out of the serial log. Or you can mount/copy to USB, as you did.
Updated by Oliver Schonrock over 6 years ago
I agree this should be closed, because your recovery process is very good (if it works and people know about it and understand it).
Perhaps consider making it more obvious that "the found config will be used on the new install" in the curses UI.
as for this:
Set your serial client to log, and simply cat the old configuration file, and then edit it out of the serial log.
As I said above, I did that, and edited out the extra crud, but ended up with a file about 20% bigger and clearly not the same. The devil is in the detail here, it will be about character encoding, transfer encoding etc etc.
This is NOT a reliable method.
USB mounting (under the recovery shell, not the full install system) was also fraught with problems.