FortiManager 5.2.6 upgrade - Post Upgrade Config Update stuck at 76%

[DirtyBlueshirt]

Hi,

We just applied the 5.2.6 FortiManager upgrade. We're coming from 5.2.4. After the upgrade, the login page shows the usual "The system is unavailable due to configuration update. Device logs are not accepted at this time." and the progress bar is stuck at 75% for the past 10 minutes or so. Is this expected? I haven't had an update take this long before.

[scao_FTNT]

this install error is returned from FGT that this URL is not a support format, but if config on FMG side is like this for a while, looks weird that after upgrade FMG to 5.2.6 then see this install error

for can not delete that "Access Granted" on FMG side, may because of the space in the name, FMG 5.2.4 or earlier still allow to create name with space, but in 5.2.6 we added syntax check to follow FOS side logic which does not allow space in the name (I tested on 5.2.5)

v8c # conf webfilter ftgd-local-rating v8c (ftgd-local-rating) # ed "a a" node_check_object fail! for url a a value parse error before 'a a' Command fail. Return code -257 v8c (ftgd-local-rating) # ed "a.a" new entry 'a.a' added

but may cause delete issue for upgraded config, I will double check this case, and see if can run script to delete this entry from backend db

Thanks

Simon

[scao_FTNT]

I did a quick test for FMG 5.2.4 + 5.2.5 FGT, install will have error, but in old release, FMG install logic will ignore this error, but in FMG 5.2.6 we added more restriction for this part check when update the URL syntax check

Starting log (Run on device)


Start installing
v8c $  config webfilter ftgd-local-rating
v8c (ftgd-local-rating) $  edit "a a"
node_check_object fail! for url a a

value parse error before 'a a'
Command fail. Return code -257
v8c (ftgd-local-rating) $  set rating "3"
v8c (ftgd-local-rating) $  next
v8c (ftgd-local-rating) $  end
v8c $  config firewall vipgrp
v8c (vipgrp) $  edit "vipgroup1_002_001_001_001"
v8c (vipgroup1_002_00~001) $  set uuid f376f856-ee0c-51e5-c96c-67103d95a381
v8c (vipgroup1_002_00~001) $  next
v8c (vipgrp) $  end
v8c $  config firewall service custom
v8c (custom) $  delete "222"
v8c (custom) $  delete "12345"
v8c (custom) $  end


---> generating verification report
<--- done generating verification report


install finished


Thanks

Simon

[ede_pfau]

In FortiOS sometimes I could delete objects with invalid syntax (after upgrading) in the CLI if I escaped blanks with a backslash: delete 'an\ object'. Maybe worth a try.

The only other option I can think of is to take a pre-5.2.6 config, delete the entry and then upgrade again. Should be easily 16 hours left on a Sunday...

[scao_FTNT]

we tried on FMG 5.2.6 753 for this upgraded config case and delete by script works OK, we will open a bug for failed to delete from GUI issue

Thanks

Simon

config webfilter ftgd-local-rating delete "a a" end

[DirtyBlueshirt]

scao_FTNT wrote:

we tried on FMG 5.2.6 753 for this upgraded config case and delete by script works OK, we will open a bug for failed to delete from GUI issue

Thanks

Simon

config webfilter ftgd-local-rating delete "a a" end

Thanks, but the script isn't helpful right now because the object never actually made it onto the FortiGate devices themselves; and best I can tell, I can't delete the object from the FortiManager CLI.

[scao_FTNT]

Hi, Aaron, the script is to delete that invalid syntax entry from FMG ADOM package db, so after delete, FMG will not try to install it and thus trigger that install error (FMG does not have CLI like FGT, so normally we will use script to update backend db config if GUI has issue for some cases)

Thanks

Simon

[DirtyBlueshirt]

scao_FTNT wrote:

Hi, Aaron, the script is to delete that invalid syntax entry from FMG ADOM package db, so after delete, FMG will not try to install it and thus trigger that install error (FMG does not have CLI like FGT, so normally we will use script to update backend db config if GUI has issue for some cases)

Thanks

Simon

Got it, Thanks. he script and it seemed to work. That particular ADOM is unpopulated now, since we migrated all the devices to m new ADOM on Saturday, but at least the offending objects won't hamper our eventual upgrade to 5.4 later this year.