Factory Reset for Configuration Settings
This note is to propose a new Factory Reset implementation to clear out configuration settings and restore them to default. The following applies for both static and ubi filesystem layouts.
The current Software implementation of the Factory Reset clears the whole read-write filesystem[1].
The reset can be problematic for example if it's issued when the host is on, since the inventory gets deleted and the fan controller has no knowledge if the system has working fans, leading to shutting off the host. This can be unexpected if the user just wants to reset the configuration data, like user passwords or LDAP settings.
The /etc dir is intended to contain the configuration files[2], so we can implement the configuration reset by clearing out the data in /etc and putting back the defaults. The /etc dir is an overlay, so this can be accomplished by clearing the overlay's upper dir.
Proposal:
* Move any configuration file that is currently created in /var to /etc, like the Time Owner and Reboot Policy (most are currently under the Settings interface).
* Have the init script which mounts the overlay, clear the etc upper dir before mounting if a u-boot environment variable is set.
* Implement a new Reset method under the path /xyz/openbmc_project/settings/ or configuration/ or settings/configuration/ or other.
[2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html
Quoted 5 lines · Adriana Kobylak
This note is to propose a new Factory Reset implementation to clear out configuration settings and restore them to default. The following applies for both static and ubi filesystem layouts.
The current Software implementation of the Factory Reset clears the whole read-write filesystem[1].
The reset can be problematic for example if it's issued when the host is on, since the inventory gets deleted and the fan controller has no knowledge if the system has working fans, leading to shutting off the host. This can be unexpected if the user just wants to reset the configuration data, like user passwords or LDAP settings.
This seems like a very system-specific sort of thing. I can imagine some systems not having any trouble with this, while others might need interaction from the host to behave correctly.
Quoted 6 lines
The /etc dir is intended to contain the configuration files[2], so we can implement the configuration reset by clearing out the data in /etc and putting back the defaults. The /etc dir is an overlay, so this can be accomplished by clearing the overlay's upper dir.
Proposal:
* Move any configuration file that is currently created in /var to /etc, like the Time Owner and Reboot Policy (most are currently under the Settings interface).
* Have the init script which mounts the overlay, clear the etc upper dir before mounting if a u-boot environment variable is set.
* Implement a new Reset method under the path /xyz/openbmc_project/settings/ or configuration/ or settings/configuration/ or other.
Our BMCs support multiple levels of 'factory reset' with each level removing more and more user data. In addition to my point above, it might be a data-driven reset. /usr/share/system-reset/level-1 contains information to perform a level-1 reset, .../level-2 contains a level-2 reset, etc. Where each system may have a different number of levels of resets and each system may have a different list of resets that is could do. Clearly the nuclear option is to just reformat the NV partition and start from ground zero, but what level that is may depend on the system.
The reset manager or settings manager (wherever this lives) can determine the number of levels of reset from the config files and then on the next reboot, the init script can consume the config files to perform the correct operation.
These files can then be stored in platform layers and installed on the appropriate targets.
--Vernon