Wiping root file system is not the same as a "factory reset"

[ajeddeloh]

Issue Report

Bug

Container Linux Version

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1590.0.0+2017-11-27-1556
VERSION_ID=1590.0.0
BUILD_ID=2017-11-27-1556
PRETTY_NAME="Container Linux by CoreOS 1590.0.0+2017-11-27-1556 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Environment

Any

Expected Behavior

The root filesystem we ship in the image should be the same as the one that is populated by tmpfiles. From our documentation on our disk layout:

Due to the unique disk layout of Container Linux, an rm -rf / is an un-supported but valid operation to do a "factory reset". The machine should boot and operate normally afterwards.

Actual Behavior

The root filesystem contains extra files and some differences as well. The differences are all in the /etc/g?{shadow,passwd}-? files, except /etc/audit/audit.rules which is generated by other files.

Reproduction Steps

1. run the coreos.filesystem test from this PR

Other Information

Here is a list of all the files that are not created (at least on my current build, current alpha/beta/stable may differ slightly).

We should audit this list and determine if it is safe to ship an empty root.

[lucab]

I took the unrelated PR at coreos/docs#1213 to slightly relax the terminology. I still prefer the term "factory reset" for clarity, so I suggest to reintroduce it (if possible) once the investigation here is over.

[bgilbert]

Thank you for reporting this issue. Unfortunately, we don't think we'll end up addressing it in Container Linux.

We're now working on Fedora CoreOS, the successor to Container Linux, and we expect most major development to occur there instead. Meanwhile, Container Linux will be fully maintained into 2020 but won't see many new features. We appreciate your taking the time to report this issue and we're sorry that we won't be able to address it.