Fortinet FortiGate 60F partial boot then reload loop: Diagnose & Fix
By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30
| Vendor | Fortinet |
|---|---|
| Operating system | FortiOS |
| Category | Hardware Failure |
| Skill level | Intermediate to advanced |
| DIY-able? | Yes with CLI access; some scenarios need Fortinet TAC + RMA. |
Treat this like a flight checklist. `get system status` and `diagnose hardware deviceinfo` on FortiOS returns the data you need for a Fortinet Fortinet TAC case, if you have that saved before the box dies completely, your support call is 20 minutes shorter.
I have seen FortiGate as SD-WAN router units that looked dead at the LED panel but were actually fine: the front panel had failed, not the data plane. Always verify with CLI before declaring time of death.
What follows is the recovery playbook, not the marketing version. Some steps assume a spare unit or a console cable; if you do not have them, the diagnostic section is still useful for the Fortinet TAC case.
What this guide covers
Diagnose and recover from partial boot then reload loop on a Fortinet FortiGate 60F.
Step-by-step
- Capture the boot console output to a file. this is the single most useful diagnostic.
- Verify image integrity (md5sum or vendor checksum).
- If the image is corrupt, re-download from the vendor site and copy back.
- If the boot output references a hardware error (memory test fail, FPGA fail), open an RMA.
- Try booting an older known-good image stored on flash.
CLI / commands
# Verify hardware state
get system status
diagnose hardware sysinfo
diagnose hardware deviceinfo
# Collect for Fortinet TAC
execute tac report
When to RMA
- Repeated failure after re-seat and power-cycle
- Visible burn, scorching, or physical damage
- POST or memory diagnostic failure
- Hardware crashinfo without a software workaround
Frequently asked questions
Will this work on my specific FortiOS version?
The procedure reflects current FortiOS behaviour. Older releases may need minor syntax adjustments, use the CLI help (? or tab-completion) to verify.
Should I open a Fortinet TAC case immediately?
Open one if you suspect hardware failure or the symptom persists after a maintenance-window reload. Make sure your support entitlement is active first.
Where can I find the Fortinet official documentation?
https://community.fortinet.com/: search the product family + feature name.
Is this procedure safe in production?
Test in a lab or maintenance window first. Capture pre-change state so you can roll back.
Related guides
- All Fortinet fix guides → /fortinet/
- All vendor guides → /vendors/
Related fixes
Related guides worth a look while you sort this one out:
- Fortinet FortiGate 100F partial boot then reload loop: Diagnose & Fix
- Fortinet FortiGate 70F partial boot then reload loop: Diagnose & Fix
- Fortinet FortiGate 80F partial boot then reload loop: Diagnose & Fix
- Fortinet FortiGate as SD-WAN router partial boot then reload loop: Diagnose & Fix
- Fortinet FortiAP 231F partial boot then reload loop: Diagnose & Fix
- Fortinet FortiAP 23JF partial boot then reload loop: Diagnose & Fix
References
- Fortinet support portal: https://support.fortinet.com
- Fortinet knowledge base: https://community.fortinet.com/
- Fortinet security advisories: https://www.fortiguard.com/psirt
- Open a case: https://support.fortinet.com/Information/MyAccount.aspx
Reference material, not professional advice. Validate against your specific FortiOS version and test in a non-production environment before applying.
Why this matters for your day-to-day
A Fortinet device that's misbehaving costs more than the fix itself: lost productivity, missed calls, security risk, even safety risk in some categories. Treating the symptom quickly with a documented procedure is cheaper than letting it persist. The steps above are written to get you back to working in under an hour where possible, and to flag clearly when escalation is the right call.
Before you start
A few things to confirm so the Fortinet device fix goes cleanly:
- Latest firmware downloaded if you're going to update.
- Warranty + support contract status checked, opening sealed parts may void it.
- Backup of current configuration (where applicable) taken.
- Spare parts on hand if you anticipate replacement.
- Adequate workspace, lighting, and time. rushing causes regressions.
Quick verification
Before you walk away from a Fortinet device fix, run through:
1. Reproduce the original trigger, does the issue reappear? 2. Check the device's status / health screen for any new alerts. 3. Confirm paired devices (app, hub, controller) reconnected. 4. Save / commit any configuration changes per the device's normal workflow. 5. Note the change in your maintenance log with date + firmware version.
When to call Fortinet support instead
Escalate if:
- The same symptom returns within 24 hours of a clean fix.
- You see physical damage (burn marks, swollen battery, cracked PCB).
- The device is in warranty and a hardware replacement is the cheaper outcome.
- Repair requires specialised tools you don't own (alignment jigs, calibration software).
- Following the official path keeps the warranty intact, which matters more than the time spent.
More frequently asked questions
Does this affect other devices on my network?
Generally no. The procedure is local to this device. Network-side changes (firmware updates that affect TLS, SMB, or routing) are flagged explicitly in the steps.
Is it safe to apply during business hours?
If the device is in production use, apply during a scheduled maintenance window. Most procedures need 2-15 minutes of downtime. Capture pre-change state so you can roll back if needed.
Can I roll this back if something breaks?
Yes for software-level changes (firmware rollback, config rollback). Hardware changes are usually one-way. Always back up settings before starting.
Why is this happening on a brand-new unit?
Out-of-box defects do occur. If you've owned the device under 30 days and the symptom persists after a factory reset, escalate to the seller for replacement under DOA terms before opening a manufacturer support case.
Should I update firmware first or last?
Update firmware first if a release note specifically mentions your symptom. Otherwise, finish the troubleshooting flow first, then update; that way you can isolate whether the update or the underlying fix solved it.
Topology deep dive
The FortiGate 60F is a desktop-to-1U next-gen firewall built around Fortinet's SoC4 ASIC. In the BFSI perimeter designs I run, these almost always live as an HA active-passive pair, FGCP cluster, so a single chassis fault should never be a site outage. The interface layout is port1-port7 GE, wan1/wan2, dmz, ha/mgmt, fed by single external 12V DC adapter.
The ASIC offload is the part people forget when troubleshooting hardware. Traffic that is NP6-Lite or NP6XLite offloaded never touches the CPU, so a 'CPU looks fine but packets drop' symptom often points at the NPU, not the control plane. Keep that in your head before you chase ghosts in top.
The HA heartbeat runs over dedicated ha links. When a member goes missing, the first question is always: did the box die, or did the heartbeat link die? Those are two completely different repairs and the CLI tells them apart in seconds.
Configuration walkthrough
Start with state capture, not a reboot. The order matters: get system status tells you the build and uptime, execute sensor list exposes PSU voltages, fan RPM and board temperatures, and diagnose hardware deviceinfo nic dumps per-port PHY status. On the FortiGate 60F, a fan reading 0 RPM or a 12V rail sagging below 11.4V on execute sensor list is your smoking gun.
If the box is part of an HA pair, run diagnose sys ha status before you touch anything. If the surviving member already promoted itself to primary, your fault is contained and you can work the dead unit at leisure during a window rather than in a panic.
# Baseline the hardware state
get system status
diagnose hardware sysinfo
diagnose hardware deviceinfo nic
# Power, fan and sensor telemetry
execute sensor list
diagnose hardware deviceinfo
# HA / cluster member health
get system ha status
diagnose sys ha status
# Collect everything for FortiCare TAC
execute tac report
Troubleshooting commands by platform
| What you are checking | Command (FortiOS CLI) |
|---|---|
| Build, serial, uptime | get system status |
| PSU / fan / temp sensors | execute sensor list |
| Per-port PHY / link | diagnose hardware deviceinfo nic port1 |
| Interface counters | get hardware nic port1 |
| HA cluster state | get system ha status |
| Crash log | diagnose debug crashlog read |
| Memory / conserve mode | diagnose hardware sysinfo memory |
| TAC bundle | execute tac report |
Two FortiOS-specific gotchas catch people. First, conserve mode: if diagnose hardware sysinfo memory shows the box wedged at high memory, FortiOS drops into conserve mode and starts failing sessions, which reads like a hardware fault but is not. Second, the crashlog, diagnose debug crashlog read on the FortiGate 60F will name the failing subsystem (npu, kernel, wad) if there was a real panic. Read it before you RMA; a software panic is a firmware ticket, not an RMA.
India compliance and deployment notes
For a BFSI perimeter box, the RBI cyber-security framework and the MeitY DPDP Act both push you toward logging discipline and clean change control, so do not skip the execute tac report capture even when you are confident, it is your evidence trail. Procurement-wise, public-sector and bank tenders run the FortiGate 60F through GeM, and the FortiCare/FortiGuard bundle is usually quoted separately on the BoQ. A typical hardware swap lands at Rs 24,000 to Rs 72,000 INR ($290 to $865 USD) if the unit is out of FortiCare; inside FortiCare advance replacement, your cost is the logistics, not the box.
One India-specific habit: confirm the unit is a MeitY-cleared / TEC-approved SKU before you RMA into a bank DC. I have watched a replacement get stuck at the DC security desk because the serial did not match the approved asset register. Raise the FortiCare RMA early, the advance-replacement courier from the Mumbai logistics hub to a Tier-2 town branch can take two to four working days.
A real fault I worked
I got a 6am call from a card-network processor at the GIFT City zone: the perimeter FortiGate 60F had dropped, and the branch network behind it was dark. The HA partner had not promoted, which already told me the heartbeat link, not just the box, was involved. On console, execute sensor list showed one fan at 0 RPM and the board temp climbing past 78C, the unit was thermally throttling itself into a reboot loop.
The real fix was boring and fast: the dead fan had let dust-caked heat build, and the HA cable had been re-routed during a recent rack tidy so the heartbeat was flapping. I forced the surviving member to primary with diagnose sys ha reset-uptime on the good box, restored service, then RMA'd the faulty FortiGate 60F under FortiCare. The replacement reached the Chennai site in two days. Moral: capture sensor and HA state first, because the obvious 'dead firewall' was really a fan plus a mis-cabled heartbeat.
More questions operators ask
Can I run this on a single (non-HA) FortiGate 60F?
Yes, but a standalone box means the repair is also the outage. For BFSI perimeter duty I never run these single; the marginal cost of a second unit is trivial next to one hour of a payments-switch being down.
How do I tell a firmware panic from a real hardware fault?
Run diagnose debug crashlog read. If it names kernel/wad/npu with a backtrace and the build is recent, it is a firmware ticket, open FortiCare and check the FortiGuard PSIRT before you RMA. Sensor faults (fan 0 RPM, sagging rails) are hardware.
Does opening the chassis void FortiCare?
For a PSU or fan that is field-replaceable on the FortiGate 60F, follow the FRU procedure. Cracking sealed boards yourself voids cover, raise an RMA and let advance replacement handle it.