2.1.2 Update: editing broken?
-
Sounds like autoconfigbackup package.
-
Update the autoconfigbackup package to 1.22.
If you can't, first do this and then update the package:
rm /etc/inc/crypt_acb.inc /usr/local/pkg/autoconfigbackup*
Might reboot for good measure.
-
Thanks everybody. To those, that may encounter the same problem:
After upgrading to 2.1.2 (coming from 2.1.1) the packages weren't updated or reinstalled (as I assumed wrong) and so autoconfbackup 1.21 still was running and effectively breaking the whole freakin' UI. Every save, delete or other config-safe-related button was broken.
So after removing it (package removal didn't work as the textarea containing the status stayed empty and nothing was processing) with brute force (like jimp suggested by removing the pkg dir) and reinstalling it, everything is back to normal again.
Note to self: don't upgrade the cluster remotely to safe working-time. Gets your pulse-rate up ;)
Thanks to all and greets to the team for quick and great work so far!
Jens -
That does sound a bit worrysome that the main pfsense image depends on a package being updated first (during an upgrade of course). If someone does not update autoconfigbackup again when/if the next release is out could they have the same issue?
EDIT: Oh… never mind... I think the version check was for the autoconfigbackup package version which just forgot to get bumped in that one spot. I don't think the main pfsense package version check would be an issue for the future. I am just guessing though as I don't really understand the code :).
-
Note the "rm" should be:
rm /etc/inc/crypt_acb.php rm /usr/local/pkg/autoconfigbackup*
(JimPs post had .inc and should have been .php)
The post in the other thread about this has the correct crypt_acb.php file name.
I'm sure JimP will quickly modify his post, then I can delete this. -
That does sound a bit worrysome that the main pfsense image depends on a package being updated first (during an upgrade of course). If someone does not update autoconfigbackup again when/if the next release is out could they have the same issue?
It was just a dumb bug in AutoConfigBackup that tested for "1.2" anywhere in the version string, which now matches "2.1.2". It only effected people who use AutoConfigBackup (hey, that's the paying customers) and JimP fixed it in 5 minutes after it was reported.
From now, people who upgrade will get the correct AutoConfigBackup files installed and will never see this issue. -
Thanks for the info. After looking at the commit in github I figured that as much and it looks like I edited my post the same time you posted your info. Thanks for the clarification.
-
Update the autoconfigbackup package to 1.22.
If you can't, first do this and then update the package:
rm /etc/inc/crypt_acb.inc and /usr/local/pkg/autoconfigbackup*
Might reboot for good measure.
Note the "rm" should be:
rm /etc/inc/crypt_acb.php rm /usr/local/pkg/autoconfigbackup*
(JimPs post had .inc and should have been .php)
The post in the other thread about this has the correct crypt_acb.php file name.
I'm sure JimP will quickly modify his post, then I can delete this.Doh! I just deleted my custom 'and' file that was in my directory! ;)
-
And I thought this was something from the Australian Cricket Board.
-
I have a similar issue where my packages weren't installed. And of course I can't remember which packages I had. Is there a way to restart the upgrade process and get packages in?