Can one restore a pre 2.3 config.xml to a 2.3 installation?
-
Where the last output you get is the mounting root, you likely restored a config with the serial console set as the primary. That's where it switches to primary console only and dual console doesn't start again until it gets to the console menu (and you probably have an interface mismatch so it's not getting that far).
Check the source in diag_backup.php to see what it does to decrypt, you can hack together a small bit of PHP to do same.
-
@cmb:
Where the last output you get is the mounting root, you likely restored a config with the serial console set as the primary. That's where it switches to primary console only and dual console doesn't start again until it gets to the console menu (and you probably have an interface mismatch so it's not getting that far).
I see. Here's the thing: it would be great to be able to force the OS to boot all the way through, regardless what's up with the interfaces. If I have to configure a device for a remote location, chances are, the interface definition isn't compatible with what the local network is like, so unless I have a few spare devices, and I create a simulation of the remote location's network setup, I'll be flying blind. So maybe the unit would magically work when back in its original environment, but who knows…
...can't risk it. So I have to make a dummy setup that works locally and should be good enough to let me control the box once in its final location, and then I have to carefully modify the setup without cutting off the branch I'm sitting on.So it would be nice if the boot process wouldn't be so picky on the network config, and would simply boot and do what it's told configuration wise, and not worry if there's actual connectivity, etc.
-
If the interface assignments aren't right on a system with a user-defined config, it's not safe to make guesses about what should be what. For instance that might happen if a NIC dies and all your interface numbers are shifted, in which case making a guess would leave things badly broken and potentially in dangerously insecure ways. The only guaranteed safe thing you can do in that case is stop and force the interface assignment.
In 2.3, if you reset to factory defaults, it'll try to auto-assign interfaces on the next boot if there is a mismatch. That's reasonably safe because there is no user-defined config.
It doesn't matter whether you have connectivity, the assigned interfaces just have to match what's actually in the system.
-
@cmb:
If the interface assignments aren't right on a system with a user-defined config, it's not safe to make guesses about what should be what. For instance that might happen if a NIC dies and all your interface numbers are shifted, in which case making a guess would leave things badly broken and potentially in dangerously insecure ways. The only guaranteed safe thing you can do in that case is stop and force the interface assignment.
In 2.3, if you reset to factory defaults, it'll try to auto-assign interfaces on the next boot if there is a mismatch. That's reasonably safe because there is no user-defined config.
It doesn't matter whether you have connectivity, the assigned interfaces just have to match what's actually in the system.
I'm not saying the system should make unsafe assumptions, but it should finish booting properly, such that I can use the console to assign interfaces.
Also, what should be possible, define at the console level what interface the anti-lockout rules should apply to.
In one of my units, all there is, is a WAN interface. All administration goes through the WAN interface. The moment ANYTHING goes wrong, I'm totally locked out, because as you say it would be wrong to make guesses about what's safe. But then, if the unit doesn't boot all the way, such that I can't use a KVM setup to take over the console, I'm screwed. But even if I get that far, I must assign the WAN interface, but there's no anti-lockout rule for the WAN, so I'm still locked out.
So what I'm asking:
a) no matter what: boot through to the console
b) if there's an issue with the interfaces, disable them, but do a clean boot, such that matters can be fixed from the console
c) setting up interfaces should also include the option for each interface to activate anti-lockout rules on that interface, regardless if its LAN, WAN, OPT, whatever.Currently, it's sweating blood and tears, because it's the second time an OS update with a configuration that worked just fine resulted in "interface issues" after the OS update induced reboot, resulting in me having a unit fedex-ed across the country because there was no way to take control of if through a KVM setup. So currently, each OS update feels like playing a round of Russian Roulette…
Interestingly enough, installing from scratch and restoring a previously backed up config resulted in an inaccessible system. And since the unit doesn't even boot to the point where I get to the console menu. I don't know if the config was corrupt, or if this was "only" because my LAN obviously doesn't match the remote location. I could have risked sending the unit out, and could have hoped it would magically recover in the proper environment, but it could also mean at great expense of time and money to repeat the exercise, because the backup of the config was corrupt.
(after all, restoring individual sections (avoiding interfaces) of the backup didn't restore either the aliases nor the certificates that used to be defined/installed.
So at this point, I'm not sure how far I can trust the config backup, the OS update mechanism, and I sure as hell can't trust being able to do anything useful at the console level, because if things go wrong, the boot doesn't proceed far enough for me to get to the point where I can do something useful with the console.
-
After re-reading one of the replies here: if connectivity to the interfaces doesn’t matter, but just the kind of interfaces present, then we can rule all of that out. All my interfaces are firmly built into the motherboard, and they are all functional before and after.
So for the OS to become confused about interfaces, even though they are invariable, we either have an issue with
a) configuration settings becoming corrupted in the course of an OS update
b) some other bug, because even restoring a configuration several months old will not work.As a matter of fact, the hoops I had to jump through to get going again sound EXACTLY like this here:
https://forum.pfsense.org/index.php?topic=110554.msg616493#msg616493
-
The system won't stop at the interface assignment prompt if all the interfaces match what's installed in the system. That was just my guess as to why the system didn't complete boot, as that's the most common circumstance. Without knowing what's on the console, it could be any number of things. If the interfaces definitely match up, then it's something else.
You can switch it to VGA primary at the loader prompt to see the output.
https://doc.pfsense.org/index.php/Boot_Troubleshooting#Booting_with_an_alternate_consoleThen set it back under System>Advanced once you get back into the GUI.
-
Rescue config.xml resulted in an error.
We don't have this fully documented yet, but always attempt a "rescue config.xml" action multiple times before deciding it doesn't work. Reason being, sometimes it doesn't fix filesystem errors fully on the first pass or it has some issue mounting the disk that time. So try it, fail, reboot, try again, etc. I've had it work on the second try more often than not, and a couple times on the third. Beyond that it's unlikely to help with more tries. The exact nature isn't fully known yet so it's hard to code a fix around that.
Is there a way to decrypt the file (having the password of course), so I can inspect the actual data?
From a BSD/Linux/OS X/*nix-like shell:
cat config-enc.xml | sed -e '1d' -e '$d' | base64 -d | openssl enc -d -aes-256-cbc -out config-dec.xml -k 'xxxx'Where config-enc.xml is your encrypted config and xxxx is the config password.
-
@cmb:
Older configs to newer versions is always fine. Newer configs to older versions isn't.
Not 100% true.
When restoring my pre-2.3 XML to 2.3 I had to:
-
Remove link-local IPv6 addresses assigned to the various VLANs (prevented DNS Resolver from working)
-
Manually remove all traces of vnstat2 (which caused cron errors)
The first problem resulted in a system that hung on boot because the package updater couldn't get the meta data for the pfSense-Core repository. Fortunately, the Web UI worked (barely) well enough to let me do a Diagnostics / Restore of a hand-edited XML file.
The second problem resulted in constant errors because the cron system was still trying to run vnstat2 every few minutes.
-
-
Remove link-local IPv6 addresses assigned to the various VLANs
There needs to be some upgrade code put into upgrade_config.inc for 2.3.1 that will do that automagically. However it came to be in old configs, it needs to be cleaned up on upgrade. I added a Redmine issue so this gets investigated:
https://redmine.pfsense.org/issues/6343Manually remove all traces of vnstat2
vnstat2 is in the list of not-converted packages https://doc.pfsense.org/index.php/2.3_Removed_Packages. Ideally people will cleanly remove those packages in their 2.2.* system before upgrading. But again it would be handy if the upgrade process itself worked out what packages to remove - hmmm, I have a feeling that something is done already for 2.3.1 to help that, by removing all packages pre-upgrade then installing the converted/supported ones post-upgrade?
-
Not 100% true.
It is true for valid configs. Your <ipaddrv6>FE80</ipaddrv6> isn't valid, that's not link local, it's a string that isn't a valid IP. Not permitted by the GUI and never has been at least in release versions. That was either manually edited into the config, or around from an early pre-2.1.0 beta version before all the proper input validation was in place.
Packages that no longer exist can be edited out, but that's not strictly necessary. The worst you end up with there is log spam when restoring to a clean install. In 2.3.1, those are automatically uninstalled pre-upgrade, then those that still exist are reinstalled post-upgrade. If restored to a clean 2.3.0+ version, it'll just log that it can't reinstall packages that are missing. If they had cron entries in the config, those may need manual removal.
