Dell OS10 Factory Reset via Linux Kernel: Step-by-Step Guide

2026年8月31日 LOG admin

Dell OS10 (SmartFabric OS10) does not offer a single restore factory-defaults command like OS9 — resetting a PowerSwitch back to factory default has to be done manually from the underlying Linux kernel. This step-by-step guide, based on Dell's official KB article 000212446, walks through the complete procedure on an S4148F-ON: save your configuration first, drop into the OS10 bash shell, delete the startup configuration and Redis database files, then reboot and verify that the switch comes back as a clean, default OS10 device.

Before You Start: Critical Warnings

After the reset you cannot log in remotely via SSH or Telnet because all configurations — including management addresses — are removed. The entire operation must be performed from the local console port. Make sure you have physical console access before beginning.

Three further warnings are worth stating plainly, because they turn a routine maintenance task into an on-site emergency:

Licences and certificates are lost. Any install-time licence files, custom certificates and trust anchors live on the same filesystem. Export them before you start.
The management IP disappears. If the switch is your only in-band path to the rack, you are now dependent on the console server. Verify the console server works before you touch the switch.
Redundancy collapses. If the switch is one half of a VLT pair, resetting it takes down the peer link and halves your bandwidth. Confirm the peer and the attached servers can survive on a single member before you begin.

Finally, decide in advance how you will restore. A factory-default switch boots with no VLANs, no VLT domain, no routing and the default hostname OS10. If you intend to return the unit to its original role, you need a plan to re-apply addresses, VLANs, uplinks and VLT settings from the console.

Step 1: Check and Save the Original Configuration

Take a backup of the running configuration, plus the settings you will need to recreate:

Core01# show running-configuration | no-more
Core01# show running-configuration vlt
Core01# show vlan
Core01# show version
Core01# show boot

Note the VLT domain settings, VLANs and the active/standby image versions — you will need them if you plan to restore the switch to its previous role.

Copy the configuration off the box rather than trusting your scrollback. OS10 can push files over SCP or TFTP, which is far more reliable than capturing terminal output:

Core01# copy running-configuration scp://admin@10.0.0.50/config/Core01-running.cfg
Core01# copy running-configuration tftp://10.0.0.50/Core01-running.cfg

Also capture the interface inventory so you can rebuild port descriptions and port-channel membership later:

Core01# show interface status | no-more
Core01# show port-channel summary
Core01# show lldp neighbors | no-more
Core01# show mac address-table count

The LLDP output in particular gives you a machine-readable record of what was patched where — the single most useful document when rebuilding a switch from scratch under time pressure.

Step 2: Enter the OS10 Linux Kernel

Core01# system bash
admin@OS10:/home/admin$ sudo -i
[sudo] password for admin: <admin password>
root@Core01:~#

The system bash command drops you from the OS10 CLI into the underlying Linux shell. From there sudo -i elevates to a root login shell. Note the prompt change: the CLI prompt is Core01#, the Linux prompt shows the hostname with a path, and the root prompt is root@Core01:~#. Being deliberate about which shell you are in prevents the single most damaging mistake in this procedure — running rm against the wrong path.

If you are already root and simply want to confirm your environment, check what you are working with:

root@Core01:~# uname -a
root@Core01:~# cat /etc/os-release
root@Core01:~# id

Step 3: Locate the Configuration Files

root@Core01:~# ls -ls /config/etc/opt/dell/os10/db_init/
72 -rw-r--r-- 1 root root 71053 Apr 17 03:59 startup.xml
root@Core01:~# ls -ls /config/var/lib/redis/
1328 -rw-rw---- 1 redis redis 1356346 Apr 17 03:59 dump.rdb

startup.xml is the startup configuration file; dump.rdb is the Redis database that holds the running state.

Two more locations are worth inspecting before you delete anything, because a partial reset that leaves stale state behind is worse than no reset at all:

root@Core01:~# ls -ls /config/etc/opt/dell/os10/
root@Core01:~# ls -ls /config/var/lib/redis/ 2>/dev/null
root@Core01:~# find /config -name "startup.xml" -o -name "dump.rdb" 2>/dev/null

If your release keeps additional state such as redis.conf overrides or per-feature XML fragments under db_init, note them but leave them alone unless Dell's KB for your exact version says otherwise. The safe rule is: delete exactly the two files the procedure names, and nothing else.

Taking a copy of both files onto external storage before deleting them costs nothing and gives you a documented rollback point:

root@Core01:~# cp /config/etc/opt/dell/os10/db_init/startup.xml /tmp/startup.xml.bak
root@Core01:~# cp /config/var/lib/redis/dump.rdb /tmp/dump.rdb.bak
root@Core01:~# md5sum /tmp/startup.xml.bak /tmp/dump.rdb.bak

Step 4: Delete the Configuration Files

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

WARNING: this permanently deletes the startup configuration and all running state of the switch.

Confirm the deletions before rebooting. A typo in a path is silent and leaves you with a switch that looks reset but is not:

root@Core01:~# ls -la /config/etc/opt/dell/os10/db_init/
root@Core01:~# ls -la /config/var/lib/redis/

The -v flag on the second command is useful precisely because it prints the name of every file it removes; if the output is empty, nothing was deleted and you need to re-check the path.

Step 5: Synchronize and Reboot

root@Core01:~# sync
root@Core01:~# reboot -f

The sync flushes dirty filesystem buffers to persistent storage before the forced reboot. Skipping it risks the deletion not being durable, particularly on a switch that has been up for a long time with heavy logging. The -f flag on reboot skips the orderly shutdown sequence, which is what you want here: an orderly shutdown would let OS10 services write the running state back out, potentially recreating the very database you just deleted.

You can also reboot from the OS10 CLI once you exit the shell, and it is the safer habit for a change-managed window because it produces a log entry in the CLI session:

OS10# reload

Step 6: Verify the Result

After reboot the hostname returns to the default OS10, all VLT and VLAN settings are gone, and the switch behaves like a brand-new unit. If you saved the backup from Step 1, you can now reconfigure the switch for its new role.

Work through a short verification checklist rather than assuming success:

OS10# show version
OS10# show running-configuration interface
OS10# show vlan
OS10# show vlt brief
OS10# show interface managementethernet 1/1/1

Expect the management interface to have no address, the VLAN table to contain only the default VLAN, and show vlt to report that no VLT domain is configured. If any of those still show old data, the reset did not take — re-enter the kernel and confirm the files are actually gone.

Then rebuild the minimum baseline from the console: management address, default route, hostname, and SNMP or syslog so the switch is observable again. Only after that is in place should you restore VLANs, port channels and VLT, because without management access you are rebuilding blind.

Alternative Reset Methods and When to Use Them

The Linux kernel method is the heavy hammer. Other OS10 reset paths exist and are usually preferable when they apply:

delete startup-configuration — keeps the running system intact until the next reload and is far gentler. Use it when the switch is healthy and you only want to clear saved config.
Console file deletion with an interactive reload — essentially the same result as this procedure but performed through the OS10 CLI rather than the bash shell, with more prompts and fewer sharp edges.
Password recovery variants — if the goal is regaining access rather than returning to out-of-box state, a targeted recovery is less destructive.

Choose the kernel-level method when the configuration is corrupt, when OS10 will not come up cleanly, when you are repurposing hardware and need a genuinely pristine state, or when other mechanisms fail outright. In every other case, prefer the lighter option.

Troubleshooting the Reset

A handful of problems recur in the field:

The switch boots but still has the old hostname. The running state was recreated before the reboot completed. Repeat the deletion, run sync, and reboot again — do not rely on a soft reload.
Console shows nothing after the reboot. Serial settings matter on OS10: 115200 baud, 8 data bits, no parity, 1 stop bit, no flow control. The default terminal speed changed between OS9 and OS10, and a misconfigured terminal emulator looks identical to a dead switch.
OS10 fails to boot into a usable state. Check show boot once you regain CLI access and confirm the active image is intact. A corrupt image is a separate recovery path involving ONIE.
You deleted the wrong file. Stop, restore from the /tmp copy or the SCP backup, sync, and reboot. Deliberate recovery is far cheaper than improvising.

Doing This Safely at Scale

If you manage dozens of OS10 switches, treat this procedure as a documented runbook rather than tribal knowledge. Record the exact image version next to the exact file paths, because db_init layout can differ between releases. Capture the pre-reset backups automatically into your configuration backup system so a wiped switch is always recoverable, and gate the work behind a change window with console access confirmed by two engineers. The procedure itself takes minutes; the preparation is what keeps it safe.