Mountroot issues after 2.2 upgrade
-
how did you backup the package? or just import the anything after autoupgraded?
No need to backup the package. All packages that does not have explicit option to remove config options will be there after package reinstall.
so the procedure is
- make a backup config
- uninstall all package
- run auto upgrade
- import the backup config
right? thanks :D
-
- reinstall and test each package.
-
-
all package need to be config again?
No. Only those that needs this wipe on upgrades(like snort).
-
all package need to be config again?
No. Only those that needs this wipe on upgrades(like snort).
the package config file will remain in the upgraded system?
-
the package config file will remain in the upgraded system?
Yes. It's on xml config file, not on package dirs.
-
-
i had to do a fresh install as well. no big deal.
-
Same issue here, full upgrade running pfsense 2.15 AMD 64. The auto upgrade made the system dysfunctional.
Basically the way to perfectly upgrade the system is to make a full config backup. Fresh install and restore the config.
It was no biggie for me as I needed to replace the HD anyway. But half a day was gone in getting it running again.
Note: After restoring the config, need to clear the packages lock and reinstall packages.
-
the package config file will remain in the upgraded system?
Yes. It's on xml config file, not on package dirs.
Very unusual, most people would expect that if you delete a package, the related config would be deleted too. Everywhere in the world it works like this, otherwise how can somebody start with a package from scratch?
Nevertheless, I admit that this is useful now.
-
how did you backup the package? or just import the anything after autoupgraded?
Before you start the upgrade you just delete any packages that you have installed from the main Package menu - pfSense seems to remember the package settings that you used and after the upgrade you just re-install the packages again. You'll want to visit the configuration menu for each package after the upgrade just to check but I've always found that all of the settings are preserved.
It's smart to always make a backup of the configuration locally - you can always dig through the XML if there are problems and figure out what most of the package settings were if something does go wrong.
-
the package config file will remain in the upgraded system?
Yes. It's on xml config file, not on package dirs.
Very unusual, most people would expect that if you delete a package, the related config would be deleted too. Everywhere in the world it works like this, otherwise how can somebody start with a package from scratch?
Nevertheless, I admit that this is useful now.
Yes, "it depends". Sometimes it is really handy that you can uninstall a package, then install again, and the settings are preserved. Other times it is some crap combination of settings that is the problem and actually you want to remove all settings also and start from scratch.
It would be handy to have an option on both deinstall and install to select "get rid of any settings for this package". -
It would be handy to have an option on both deinstall and install to select "get rid of any settings for this package".
Some package does have, but the idea of a cleaner package is good.
-
It would be handy to have an option on both deinstall and install to select "get rid of any settings for this package".
Some package does have, but the idea of a cleaner package is good.
+1 here! Somewere around the backup/restore area, where you can select which parts of the config to manipulate.
Btw: not all parts of the config are selectable from the dropdown, this should be completed too. -
Each package should have an option in its "General" settings Tab to enable/disable "keep settings". This option is available in Snort/Suricata and also in pfBlockerNG.
Each package de-install function should have code to fully remove all files that it adds to the system and any settings stored in the config.
Having it as a global option would be a nice option but the first step would be to create a universal format that each package should follow. Maybe the addition of a new XML tag in each packages xml file?
-
The easiest way would probably be to just implement a message box on the package manager tab, where when somebody wants to delete a package it could ask "Are you sure you want to delete the package?", if answered Yes it would ask "Do you want to delete configuration too?" and if answered Yes it would delete the package and the config, if answered No it would just delete the files and keep the config.
-
The easiest way would probably be to just implement a message box on the package manager tab,
The problem is that the Package Manager does not know what files and/or config changes were made by the package… Those particulars are handled by each package specifically. Having the option to select "Complete De-install" or "Keep Settings" in the package manager is a great idea, but it would need some integration with the packages.
So for example... Snort.xml has the following tags for Install/Deinstall
<custom_php_install_command>include_once("/usr/local/pkg/snort/snort_post_install.php");
]]></custom_php_install_command>
<custom_php_deinstall_command>snort_deinstall();
]]></custom_php_deinstall_command>The file snort.inc has the functions for Install/De-install
[ [color=blue]function snort_deinstall() ]
If the keep setting is not enabled in the package it will remove the custom settings in the config and also remove the modified files/downloaded files.
/* Keep this as a last step */
if ($config['installedpackages']['snortglobal']['forcekeepsettings'] != 'on')
–--------------------------------------------------------------------------------------So I think it would be best to introduce a new tag say "Custom _php_keep_deinstall"
<custom_php_install_command></custom_php_install_command>
<custom_php_deinstall_command></custom_php_deinstall_command>
<custom_php_keep_deinstall_command></custom_php_keep_deinstall_command>Then each package could have a function that will handle "keep settings" on De-Install. Its also worth noting, that even on a Re-Install. The de-install function is called first.