11-11-2020 01:07 PM
Anyone else having trouble upgrading FMC to v6.7.0? I'm working on my test box to move from a v6.2.x to the latest v6.7.0 and no matter which upgrade path I choose, the v6.7.0 upgrade always stops with a fatal error on the LDAP External Auth fix script (looks wrong coding IMHO). I've got rid of AD integration and external user authentication settings in the hopes the upgrade process would skip this task, to not avail.
The error message is as follows:
Maybe I'll stick with v6.6.1 for a while and wait for a fix for v6.7.
Solved! Go to Solution.
11-23-2020 07:56 AM - edited 11-23-2020 10:14 AM
***Update. TAC responded to me and said its related to bug CSCvw38870.
From CLI do the following:
expert
sudo su
mv /new-root/etc/sf/sfmail /new-root/etc/sf/sfmail.old
upgrade_resume.sh
11-12-2020 07:26 AM
I upgraded my lab FMC to 6.7 successfully. But I keep it up to date so I was going from 6.6.1 as the previous version. It does have AD integration and uses RADIUS external user authentication - both of those are still working OK.
6.6.1 is Gold Star now so that may be a better initial choice.
11-12-2020 10:24 AM
Hi Marvin. Thank you, as always, for your comments.
v6.6.1 is working with a few minor caveats such as custom IPS policies that used to deploy on the ASA 5500-X platform that won't deploy on the FPR - deployment fails with "Device does not have required amount of memory resource" message, even while it only have 5 rules inside the policy and minimal, custom sensitive data detection flags turned on. But that's for another topic.
This test FMC and its database was migrated and updated with no errors at every new upgrade since the early code. Historically this box was born as FMC v5 and it just insists in keep going forward
Maybe because I'm also doing a technology change (moving away from the ASA5500-X series, which some sensors aren't supported at all by past FMC v6.6), things are not as straightforward as it should be.
And I agree staying at v6.6.1 is indeed the sane thing to do at this point. Because it's on a lab environment, I wanted to push boundaries to find out what else we could extract off the product, but until Cisco catches up with the competition and adds TLSv1.3 decryption, I have no real reason to go past their recommended code and v6.6.1 will be for the time being.
Thank you again for the note. Should I have more time to play, I might dig up more on this.
11-23-2020 07:56 AM - edited 11-23-2020 10:14 AM
***Update. TAC responded to me and said its related to bug CSCvw38870.
From CLI do the following:
expert
sudo su
mv /new-root/etc/sf/sfmail /new-root/etc/sf/sfmail.old
upgrade_resume.sh
12-09-2020 10:54 AM - edited 12-09-2020 10:55 AM
As backwards as this sounds, it definitely makes 100% sense. I have email notifications on this FMC, and it is part of the error message ("called from /usr/local/sf/lib/perl/5.10.1/SF/Snapshots/IntrusionEmail.pm") displayed during the upgrade. I did removed the email notifications (Policies > Actions > Alerts) and the update was performed as expected. As an alternate test, I recovered the v6.6.1 VM snapshot and manually removed the email notification folder as per your TAC received info, and the upgrade to v6.7 also completed as expected.
While I was off in thinking about LDAP or AD integration, I was right this is indeed a wrong coding, but I do appreciate you to post such findings.
03-15-2021 03:57 AM
Hello Ryan,
I face the same issue when upgrade but when i tried to enter the commands getting an error that no such directory.
root@HQ-FMC:~# mv /new-root/etc/sf/sfmail /new-root/etc/sf/sfmail.old
mv: cannot stat '/new-root/etc/sf/sfmail': No such file or directory
root@HQ-FMC:~#
There is no directory named new-root.
Regards,
Abheesh
03-15-2021 04:45 AM
12-14-2020 12:26 PM
I ran into the same issue above. TAC did gave me the same steps to fix it and completed the upgrade. but when FMC boot up, it take a long time. I'm still waiting on it to completely up. how long does it take? or can I do a hard shut down to reboot it. my FMC is virtual.
thank you,
12-14-2020 12:40 PM
I recommend looking at the console of the VM to see what it is doing. Depending on your system recourses, especially disk i/o will determine how long the upgrade takes.
12-14-2020 01:04 PM
12-14-2020 01:11 PM
IIRC, my upgrade took approx 2-3 hours for the GUI to become available again. I would wait 6 hours before assuming the upgrade did not work based on past experiences.
12-14-2020 01:18 PM
12-14-2020 01:39 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide