Dell OS10 Factory Reset: delete startup-configuration

Dell PowerSwitch OS10 does not carry the classic restore factory-defaults command that OS9 administrators expect, and that gap sends people into the Linux shell to delete Redis databases by hand. There is a supported, much simpler route: erase the startup configuration from the OS10 CLI and reload. This article documents that two-command method, the exact prompts you must answer, what the switch looks like afterwards, and when the manual file-deletion method is still the right choice.

Method 1: delete startup-configuration + reload (recommended)

From the OS10 CLI:

OS10# delete startup-configuration
Proceed to delete startup-configuration [yes/no(default)]:yes
OS10# reload
System configuration has been modified. Save? [yes/no]:no
Proceed to reboot the system? [confirm yes/no]:yes

Two details decide the outcome. Answering no at the save prompt is essential - answering yes writes the current configuration back to startup and you reboot into the same state. The switch then comes up with default settings: VLAN 1 only, no port channels, no VLT domain, no routed interfaces.

What delete startup-configuration Actually Removes

OS10 splits the configuration into two places, and only one of them is persistent. The running configuration lives in memory and is served from a Redis database at /config/var/lib/redis/dump.rdb; the startup configuration is the file the switch reads at boot, at /config/etc/opt/dell/os10/db_init/startup.xml. Everything you configure in the CLI changes the running configuration. Nothing survives a reload unless it has been written to the startup file.

delete startup-configuration removes that file. The running configuration does not change at the moment you type the command — which is why the sequence ends with a reload, and why the save prompt at the reload is the decision point:

• Save = yes: the switch writes the current running configuration to a new startup file, then reboots into it. The delete achieved nothing.
• Save = no: the switch reboots without recreating the startup file and comes up with factory defaults.

This is the OS10 equivalent of what IOS calls write erase followed by reload. The Redis database is a runtime cache — deleting it on its own does not reset the switch, and deleting the startup file without a reload does not change the running configuration either.

Method 2: manual file deletion from the Linux kernel

For cases where the switch will not boot cleanly, or you deliberately want to clear the Redis database as well, Dell's KB documents deleting the config files from the Linux shell:

root@Core01:~# rm -rf /config/etc/opt/dell/os10/db_init/startup.xml
root@Core01:~# rm -vf /config/var/lib/redis/dump.rdb
root@Core01:~# ls -l /config/var/lib/redis/

This is the OS10 equivalent of the OS9 command restore factory-defaults stack-unit all clear-all, and it is destructive: all configuration, including VLT and management addressing, is removed. Console access is mandatory afterwards, because SSH and the management address are gone.

Reaching that shell requires either a console login as linuxadmin or an SSH session to the Linux side of the switch, and the OS10 CLI runs on top of that Linux system — so this is not a path to improvise on a production switch over a shaky remote link. Use it when the CLI cannot help you: a startup file that crashes the configuration loader, a boot that never reaches the login prompt, or a switch you are deliberately stripping for a new role and whose Redis state you want gone as well.

What to Capture Before You Reset

OS10# show running-configuration | no-more
OS10# show running-configuration vlt
OS10# show vlan
OS10# show interface port-channel summary
OS10# show version
OS10# copy config://startup.xml config://backup-$(date +%F).xml

Keep the VLT domain, discovery interfaces and management route in the backup - those are the fields people most often forget when rebuilding a switch that will be re-racked into another role.

Capturing to the switch's own filesystem is a convenience, not a backup: a switch that goes back to the rack in a different role takes its files with it, and a switch that fails to boot takes them to the grave. Copy the running configuration off the device as well, using the transport your management network allows, and give the file a name that records the switch, the date and the reason:

OS10# copy running-configuration scp://admin@10.0.0.50/backups/Core01-2026-09-14-pre-reset.txt
OS10# copy running-configuration ftp://admin@10.0.0.50/backups/Core01-pre-reset.txt
OS10# dir config://
OS10# show file config://backup-2026-09-14.xml

Add four things to the same notes document, because they are not in the configuration dump: which ports were patched to what, the VLAN-to-subnet mapping, the licence file state, and any local-only credentials. The patching record is the one that costs the most time after a reset, because the running configuration tells you which interfaces exist but not which rack unit is at the other end of each of them.

Verifying the Reset

OS10# show running-configuration vlt
OS10# show interface port-channel summary
OS10# show vlan
OS10# show running-configuration spanning-tree

Expect empty output for VLT and port channels, and only VLAN 1 in show vlan. Because the management interface also reverts, plan a console session for the rebuild rather than a remote one.

A factory-fresh switch is easy to recognise if you know the markers. The hostname is the platform default, the management interface has no address (or takes DHCP where the platform supports it), there are no local user accounts beyond the defaults, and the running configuration is short enough to read in one screen. If any of the pre-reset interfaces, VLANs or VLT settings are still present, the reset did not take — check whether the startup file was recreated before the reboot, which is exactly what happens if the save prompt was answered with yes.

After the Reset: Rebuilding the Switch

The reset ends the removal work; the rebuild is the larger part of the window. Minimum viable configuration to get the switch back under management, in the order that keeps you from needing the console twice:

OS10# configure terminal
OS10(config)# hostname Core01
OS10(config)# interface mgmt 1/1/1
OS10(config-if-mgmt-1/1/1)# no shutdown
OS10(config-if-mgmt-1/1/1)# ip address 10.0.0.100/24
OS10(config-if-mgmt-1/1/1)# exit
OS10(config)# management route 0.0.0.0/0 10.0.0.1
OS10(config)# username admin password <new-password> role sysadmin
OS10(config)# end
OS10# write memory

Then re-apply the design, in this order: VLANs, access and trunk ports, port channels, spanning tree policy, VLT domain and peer link, routing (BGP/OSPF) with its authentication, and finally the services — SNMP, syslog, NTP, TACACS/RADIUS. Management addressing comes first because everything after it can then be done over SSH instead of from a crash cart. If the switch is being re-racked into a different role, resist the temptation to copy the old configuration wholesale: restore selectively, one section per testable step, and keep the backup as a reference rather than as a script.

Two platform behaviours are worth knowing before you start. Depending on the release and platform, the switch may try to run its provisioning mechanism after a reset because the configuration is empty — confirm what the switch is doing before assuming the console is idle, and see OS10 zero-touch deployment if the switch is meant to be provisioned that way. And the management path itself is a design decision, not an afterthought: the options are covered in OS10 out-of-band management interface and VRF configuration and OS10 default gateway and management route configuration.

When the Reset Does Not Stick

Three situations produce a switch that "reset itself back":

• The save prompt was answered yes. The running configuration was rewritten as startup immediately before the reboot. Delete the startup configuration again and answer no.
• Zero-touch provisioning rebuilt the configuration. On a switch that reaches a provisioning server, the empty configuration is an invitation to be re-provisioned. Disable or redirect that mechanism before the reset, and verify the running configuration after the first boot rather than assuming the switch is idle.
• A startup file was restored from the switch's own disk. If you copied startup.xml to another name and the boot environment still points at it — or if someone replayed a copied configuration file — the switch boots into the old state. Check dir config:// after the first boot.

Reset Commands Compared Across Vendors

Coming from another platform, the translation table below saves a search. Note that none of them are strictly equivalent: some clear only the startup configuration, others also clear keys and licences.

The habit that transfers between all of them: reset the startup configuration, reboot without saving, and confirm before you configure anything that the device really is at defaults.

Decommissioning Safely: Credentials, Keys and Licences

When the switch is leaving your ownership rather than being re-purposed, a configuration reset is not enough on its own. Work through this list:

• Change every shared secret you can reach. A reset removes the local copy, but TACACS/RADIUS keys, SNMP communities, NTP authentication keys and routing protocol passwords have all been visible in the configuration you just deleted — assume they are compromised and rotate them.
• Treat the configuration dump as sensitive. Delete your backups when the retention period ends; they contain the same secrets.
• Confirm the licence state. If a licence file was installed, check whether it is still present after the reset, and record what the receiving party needs to re-apply.
• Verify with the vendor's data-sanitisation guidance if the device must be provably clean rather than merely at defaults. For a switch, that can mean a full reinstall rather than a configuration reset — the path documented in Dell OS10 firmware upgrade: ONIE vs in-place image install.

Common Pitfalls

• Answering the reload save prompt with yes. The single most common cause of "the reset did not work".
• Resetting without a console. The management address and SSH access go with the configuration; a remote-only window turns a 20-minute task into a site visit.
• Forgetting the management route. An interface address without management route leaves the switch unreachable from any other subnet — the local subnet works, everything else does not.
• Rebuilding from a single monolithic paste. Errors in a large paste are hard to attribute; rebuild in sections and verify each one.
• Leaving the default admin credentials in place. Change them in the same session that restores management access, not later.
• Assuming the Redis database must be deleted. On a switch that boots normally, the CLI method is sufficient; the manual deletion is for recovery, not routine work.
• Not recording the patching and VLAN plan before the reset. The configuration file does not contain the physical topology, and rebuilding it from memory costs more than writing it down.

Choosing Between the Two Methods

• Re-purposing a working switch for a new role: delete startup-configuration plus reload. Two commands, no console-only lockout risk if you also re-apply management first.
• Recovering a switch with a broken startup file or a wedge boot: delete startup.xml and dump.rdb from Linux, then reboot to defaults.

Related reading: Dell OS10 factory reset via the Linux kernel method, OS10 VLT troubleshooting with show vlt commands and OS10 out-of-band management interface and VRF configuration. Also useful when the reset is part of a hardware change: OS10 factory reset methods and management setup and OS10 factory reset and password recovery step by step.

原文链接：Dell Technologies Info Hub: Reset Dell SmartFabric OS10 switches to factory defaults