Investigate a state reset feature

[castrojo]

We should look at a functional equivalent of a ChromeOS "powerwash": https://support.google.com/chromebook/answer/183084?hl=en

[bsherman]

I was looking around and saw this: ostreedev/ostree#1793 (comment)

There's also this: ostreedev/ostree#2081

Between the two of them it seems like we could probalby do some kind of ostree deploy --no-merge to reset /etc and rm -fr /var/* maybe?

Some stuff to consider .

[bsherman]

Other links about "factory reset"

fedora-silverblue/issue-tracker#337

coreos/fedora-coreos-tracker#399

[dnkmmr69420]

I would love to see this. There should also be an option where it resets everything except what is in /var/home

[dnkmmr69420]

I was looking around and saw this: ostreedev/ostree#1793 (comment)

There's also this: ostreedev/ostree#2081

Between the two of them it seems like we could probalby do some kind of ostree deploy --no-merge to reset /etc and rm -fr /var/* maybe?

Some stuff to consider .

there is no ostree deploy command

[castrojo]

Oh I think I know how to make this a killer feature.

When people rebase inbetween images their home directories have been leading to weird stuff.

Making a new user would solve this problem right off the bat. We can say ujust powerwash but maybe have an option to blow away all the dot directories but move the ownership of the home directory to the new user so they have all their data.

Then people could rebase cleanly because the real fix is for apps to behave better but that isn't changing any time soon. People can still rebase manually if they'd prefer to yolo it.

[bsherman]

This is a good point @castrojo . The actually ChromeOS power wash feature does delete users and data granted not much is stored on those machines.

[castrojo]

Yeah we should still keep the "blow it all away" option for the donation use case -- this one would cover the "distrohoppers".

[b-]

I agree. I don’t think it’s much of a “powerwash” unless it really resets to factory settings. The idea (or at least my own use case) is in lieu of formatting and reinstalling.

I apologize that I didn’t do my research before asking this, but the rootfs on a CoreOS machine is built from overlayfs, right? How crazy/complicated would it be to sort of add another layer on top of that? So that simply wiping the uppererer directory/volume would completely wipe things?

[castrojo]

I retitled this, what we're really doing is like a home directory reset.

Powerwash implies full system wipes. Plus we don't want to be like "I powerwashed my Bazzite steam deck before I left it on the plane but all it did was delete my dotfiles and now some rando has my data."

Perhaps as a first cut scope to rebasers? A real powerwash would need to be in upstream Fedora anyway so maybe let's prototype and see what happens?

[RoyalOughtness]

A homedir reset would be part of it, but it would also be good to nuke /etc or somehow detect all deltas between /usr/etc and /etc and undo them.

You could meticulously find and remove all the right dotfiles but still end up with users being confused because they previously set variables in /etc/environment that they forgot about.

The problem is though, it's not as simple as just nuking /etc/ because there are changes that might need to be persistent there, like in /etc/fstab

[m2Giles]

If we want user data to persist, the overlay might be difficult. Since data changes would probably be on the same layer as the config changes. Maybe take advantage of subvolumes and make a subvolume on ~/.config and make snapshot when doing a rebase?

[RoyalOughtness]

it might also be good to have a flag that can do a "dry run" with this feature. That tells you what it's going to change so you can be aware of that before it runs.

[RoyalOughtness]

#!/bin/bash

compare_recursive() {
    local usr_dir="$1"
    local etc_dir="$2"

    for usr_file in "$usr_dir"/*; do
        etc_file="$etc_dir/$(basename "$usr_file")"

        if [ -e "$etc_file" ]; then
            if [ -d "$usr_file" ]; then
                compare_recursive "$usr_file" "$etc_file"
            elif [ -f "$usr_file" ]; then
                # Compare the files using diff, it returns 0 if the files are the same
                if ! diff "$usr_file" "$etc_file" &> /dev/null; then
                    echo "To be reset: $etc_file"
                fi
            fi
        fi
    done
}

compare_recursive "/usr/etc" "/etc"

Here's an quick version of what I'm thinking of for wiping /etc, the hard part will be coming up with some way of excluding certain files.

Nuking /etc/group or /etc/passwd for example could brick a system

[b-]

Nuking /etc/{passwd,group} wouldn't necessarily brick your system if there's a way to trigger a first-boot, pre-login OOBE wizard that creates users. I don't mean like Yafti, but more like Anaconda. GNOME Initial Setup can do this too. Apparently Pop_OS used that for a while.

I think that a really "hard" reset feature would sort of require an initial setup wizard that creates users. Honestly I'd prefer that, anyway.

Sort of just spitballing here now, but in the spirit of CoreOS it might be possible one way or another to support using an ignition file, and launching an initial setup wizard that generates and then deploy one if such a file isn't found.

That's the approach I'd really aim for if I was implementing this feature myself from scratch: make /etc just an overlayfs on top of /usr/etc, check for a provisioning file like Ignition on first boot, and fall back into a sort of OOBE setup wizard that generates that very sort of provisioning file if there isn't one.

(Admittedly I have no idea how much control we have over any of these things without starting to rewrite/reimplement redhat stuff

[RoyalOughtness]

I think there's a missing question here of scope. When we say state reset, what are we actually including in the "state" that gets reset?

For example do we want this functionality to clear out existing user accounts and homedirs and do the equivalent of a factory reset?

Or do we just want to clear out DE-specific configuration in the homedirs and /etc?

The answer to this question is going to determine the implementation as they're vastly different behaviors.

[BuonHobo]

The way I would want this to work is a factory reset, so I don't have to download the ISO, make a bootable USB, and so on... I think that selectively resetting just some things is much more difficult and is probably never gonna satisfy everybody.

I think it makes more sense to go back to the absolute beginning and I agree that after the factory reset there should be a first setup wizard to get you back on track.

In order to make this feature a bit more useful, I suggest adding some kind of "Vault" capability. Basically it's something that allows you to select stuff that you want to bring with you into the next life. It could be as simple as a dedicated folder that's guaranteed not to be deleted. I find it more convenient than moving stuff into an external drive/second partition or redownloading it altogether.

A possible use case is someone deciding to preserve their ~/.var directory or their steam library

[fiftydinar]

The way I would want this to work is a factory reset, so I don't have to download the ISO, make a bootable USB, and so on... I think that selectively resetting just some things is much more difficult and is probably never gonna satisfy everybody.

I think it makes more sense to go back to the absolute beginning and I agree that after the factory reset there should be a first setup wizard to get you back on track.

In order to make this feature a bit more useful, I suggest adding some kind of "Vault" capability. Basically it's something that allows you to select stuff that you want to bring with you into the next life. It could be as simple as a dedicated folder that's guaranteed not to be deleted. I find it more convenient than moving stuff into an external drive/second partition or redownloading it altogether.

A possible use case is someone deciding to preserve their ~/.var directory or their steam library

I agree with full factory-reset option.

Vault idea sounds great, especially since it would be easier for end-users to have a intuitive backup & restore function, without being tech savvy.

[tyvsmith]

If the primary usecase is switching DEs, and there's too much complexity in alignment on a full power-wash, how about decoupling into a specific ujust feature to toggle between DEs and just targeting the config areas that conflict? ie ujust switch-desktop-environment.

[castrojo]

Let's just follow upstream on this for the reset part: containers/bootc#404