Skip to main content
nathan_emerson
nathan_emerson
New Member
January 9, 2015
Question

FGT80C Configuration changes not held after loss of power

  • January 9, 2015
  • 2 replies
  • 7060 views

We have a non clustered FGT80C which has on more than one occasion lost configuration changes after a loss of power. Looking at logs show some occurrences of kernel and non kernel conservation mode being entered during the time between the last change and the loss of power, but these are temporary and could be one time in 10 days between change and loss of power. 

 

Is there a way we can look at the device and check that it has committed the changes to flash?

 

Are there any specific tests we can perform to check if teh flash or device has issues related to saving the configuration?

 

Cheers,

 

Nathan

2 replies

Christopher_McMullan
Staff
Christopher_McMullan
Staff
January 9, 2015

You could look at the timestamps on the files making up the config saved to flash to determine the last time a file-level change was committed. Use these commands sparingly and cafully: they've been heavily locked down, but you're dealing with the underlying Linux filesystem, and the CLI would no longer be there to protect you from yourself (I'm being half-facetious).

 

McFortiGate # fnsysctl ls -l /data/config

lrwxrwxrwx    1 0        0       Fri Dec 12 13:00:07 2014               40 daemon.conf.gz -> /data/./config/daemon.conf.gz.v000000000

-rw-r--r--    1 0        0       Fri Dec 12 13:00:07 2014              168 daemon.conf.gz.v000000000

lrwxrwxrwx    1 0        0       Mon Dec 22 10:19:33 2014               52 global_system_interface.gz -> /data/./config/global_system_interface.gz.v000000006

-rw-r--r--    1 0        0       Mon Dec 22 10:19:33 2014              738 global_system_interface.gz.v000000006

lrwxrwxrwx    1 0        0       Tue Jan  6 10:26:32 2015               44 sys_global.conf.gz -> /data/./config/sys_global.conf.gz.v000000013

-rw-r--r--    1 0        0       Tue Jan  6 10:26:32 2015             4284 sys_global.conf.gz.v000000013

lrwxrwxrwx    1 0        0       Tue Jan  6 10:30:41 2015               45 sys_vd_root.conf.gz -> /data/./config/sys_vd_root.conf.gz.v000000028

-rw-r--r--    1 0        0       Tue Jan  6 10:30:41 2015             8521 sys_vd_root.conf.gz.v000000028

lrwxrwxrwx    1 0        0       Tue Jan  6 10:18:07 2015               52 vd_root_firewall_policy.gz -> /data/./config/vd_root_firewall_policy.gz.v000000029

-rw-r--r--    1 0        0       Tue Jan  6 10:18:07 2015              602 vd_root_firewall_policy.gz.v000000029

lrwxrwxrwx    1 0        0       Tue Dec 23 15:39:02 2014               56 vd_root_webfilter_urlfilter.gz -> /data/./config/vd_root_webfilter_urlfilter.gz.v000000001

-rw-r--r--    1 0        0       Tue Dec 23 15:39:02 2014              346 vd_root_webfilter_urlfilter.gz.v000000001

McFortiGate #

 

So from my output, at least, there were a batch of changes made on December 22nd and 23rd, but then none again until January 6th, and none yesterday.

Dave_Hall
Dave_Hall
New Member
January 9, 2015

Depending on the firmware installed, I'd would just reformat the log disk; alternately perform a config backup, reformat the bootdisk, reinstall the firmware via tftp, restore the config.  After that, (even though rarely happens) I would check into seeing what is causing the Fortigate to go into conserve mode -- just how close to the 80% memory usage does it get it.  Is the Fortigate is still running 4.0.x code?

Terms & ConditionsAccessibility statement