5.4 Boot Process and Configuration Recovery
Key Takeaways
Bootstrap software, BOF settings, runtime images, and saved configuration serve different roles.
A successful software boot does not prove the intended configuration loaded.
Commit activation and configuration persistence are separate checks.
A backup configuration file is not automatically the selected startup file.
Booting is a dependency chain
The current Nokia course lists the boot process as a separate topic. Learn what must succeed before routing protocols or customer services can operate. A configuration problem and a software-loading problem can produce very different console symptoms.
A conceptual 7750 startup sequence initializes hardware, locates and executes bootstrap software, reads boot options, loads the runtime image, and applies the selected system configuration. Exact media, filenames, secure-boot checks, and recovery behavior depend on platform and release. The sequence is a diagnostic model, not an instruction to reboot equipment to discover what is wrong.
| Item | Role in a conventional SR OS startup |
|---|---|
Bootstrap loader, commonly boot.ldr | Starts software initialization and reads boot options |
Boot Options File (BOF), commonly bof.cfg | Identifies image and configuration locations and boot-related settings |
| Runtime image files | Supply the actual operating-system software |
Saved configuration, commonly config.cfg | Recreates configured router interfaces, protocols, and services |
| Running configuration | Active state after software and configuration processing |
These are separate objects. Saving customer service configuration does not necessarily save edited BOF settings. Copying a runtime image does not automatically change which image the BOF will select.
Primary and alternate locations
Boot settings can identify primary and alternate locations for software or configuration. A location can refer to local storage or a supported remote source. If a chosen source cannot be reached, the documented startup procedure determines which alternate is tried or whether console intervention is required.
A remote image location creates dependencies before normal production routing is fully established. The boot environment needs suitable management connectivity and addressing. A route configured only inside the full operating-system configuration cannot be assumed to exist earlier in bootstrap.
An alternate image and an alternate configuration are also different fallback resources. An available software image cannot compensate for a missing or incompatible configuration file. Conversely, a readable configuration cannot start the operating system when the required runtime software is unavailable.
A structured failure example
Suppose a lab router reaches its bootstrap console but cannot load the primary runtime image. Work from the earliest failing stage:
- Confirm the intended image location and filename.
- Confirm storage is accessible or the supported remote path is reachable.
- Check whether required image files exist and match the platform/release.
- Read the actual error, including integrity or compatibility failures.
- Follow the documented recovery path without overwriting the last known-good resources.
Do not immediately diagnose OSPF or a customer SAP. Those functions may not yet exist because the runtime software has not completed loading.
Now suppose SR OS starts, management login works, but expected interfaces are absent. The investigation shifts to the selected configuration location, file contents, load errors, and whether the intended running changes had been saved. The hardware can boot successfully while loading an older or incomplete configuration.
Commit, save, and BOF selection
MD-CLI commits activate candidate configuration. Automatic saving can persist successful commits when enabled; otherwise the operator must save the committed running configuration. The startup configuration location is determined by boot settings.
Consider a lab operator who changes a route, commits it, and disables automatic saving. The route works until reboot, then disappears because startup loads the earlier saved file. This is a persistence issue, not proof that commit never activated the route.
A different operator saves a backup file at an alternate path but leaves the primary startup location unchanged. After reboot, the router still loads the original primary configuration. A successful backup write did not silently redirect startup.
When changing boot options, use the correct BOF management and save workflow for the CLI mode and release. Do not assume admin save of the main configuration saves every boot-related object in every management model.
Observe without disrupting
Read-only checks include the running software version, storage listings, configured boot options, and saved configuration references. Use the matching release manual for exact commands and file paths. A console transcript can show which startup stage was reached; current operational displays can show which version actually loaded.
Record the relationship between the intended files and selected boot locations. If redundant control modules or storage devices exist, understand their synchronization and failover rules before replacing media or changing paths. Redundancy does not mean every file is automatically an identical backup in every situation.
For study, draw two arrows: boot options point to software, and boot options point to configuration. Then add the dependencies of each location. This makes it easier to distinguish a missing file, a stale startup reference, a network-fetch failure, and an invalid configuration.
Recovery priorities
Preserve access to the console or another independent management path before a risky change. Preserve a known-good compatible image and configuration. Review compatibility and integrity requirements before selecting new software.
A rollback of configuration and a rollback of the operating-system image are separate operations. A configuration checkpoint may help recover a bad route or policy; it does not necessarily repair a corrupted runtime file or an unsupported image.
The exam-level reasoning is to identify the failed dependency first. Booting the software, applying configuration, obtaining physical link state, forming routing sessions, and forwarding customer traffic are successive checks. Passing one does not establish that all later checks have passed.
Primary reference
Nokia boot options documentation, checked October 20, 2026. Consult the selected platform's current manual for exact media and recovery procedures.
A route works after an MD-CLI commit, but disappears after reboot. Automatic configuration saving was disabled and no manual save was performed. Which explanation fits?
The commit could not have changed running state
OSPF must always remove static routes at boot
Startup loaded the earlier saved configuration
The BOF automatically deleted every route
Sections you finish are checked off in the contents.