The scope of powerwash is not well defined in the issue imo. https://github.com/ublue-os/main/issues

The scope of powerwash is not well defined in the issue imo.
https://github.com/ublue-os/main/issues/95

As can be noticed by latest comments.

It's either a full proper reset like Androids or it's just reset of some configs.

I prefer to go all in, as partial config reset is already possible to some extent.

GitHub

Investigate a state reset feature · Issue #95 · ublue-os/main

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

fiftydinarOP•4/20/24, 8:17 AM

But I'm looking forward to see that presentation, it's gonna be spicy heh

Ffiftydinar I like that yafti can be configurable from being a informational pop-up, selecti...

NerdsRun•4/20/24, 8:35 AM

I am storing state in gsettings make this type of functionality possible. Though, unless the python bindings get some love it might be a good idea to talk about rust... I would have went this direction if I knew how bad they have gotten ahead of time

KKyle Gospo ^ this one may need a revert, I suspect it's breaking discord specifically, can'...

Von.dev•4/20/24, 9:06 AM

File location for flatpak:

~/.var/app/com.discordapp.Discord/config/discord/settings.json

~/.var/app/com.discordapp.Discord/config/discord/settings.json

  {

    "IS_MAXIMIZED": false,

    "IS_MINIMIZED": false,

    "MIN_WIDTH": 0,  //this line is important

    "MIN_HEIGHT": 0,  // this line is also important

    "WINDOW_BOUNDS": {

    "x": 500,

    "y": 23,

    "width": 940,

    "height": 877

    }

    }

  {

    "IS_MAXIMIZED": false,

    "IS_MINIMIZED": false,

    "MIN_WIDTH": 0,  //this line is important

    "MIN_HEIGHT": 0,  // this line is also important

    "WINDOW_BOUNDS": {

    "x": 500,

    "y": 23,

    "width": 940,

    "height": 877

    }

    }

Ffiftydinar The scope of powerwash is not well defined in the issue imo. https://github.com/...

HikariKnight•4/20/24, 11:09 AM

kinda implemented this at work but i did it by just having a service remake the users homefolder at boot if it didnt exist, although our environment is a lot more predictable and

/etc

/etc

is entierly controlled by me the admin

KKyle Gospo Click to see attachment

Kid•4/20/24, 1:53 PM

Thats a Monster!
Hey Kyle, how are your temps on your 6900 XT Noctua Mod under full load? :D

Ffiftydinar The scope of powerwash is not well defined in the issue imo. https://github.com/...

j0rge•4/20/24, 3:54 PM

yeah someone needs to drive concensus

j0rge•4/20/24, 3:54 PM

I agree it's important but I have other things on my plate, maybe someone else can drive

Ffiftydinar The scope of powerwash is not well defined in the issue imo. https://github.com/...

EyeCantCU•4/20/24, 4:23 PM

I'm thinking two features here, but let's start with one:

just powerwashjust powerwash and just rinsejust rinse

Powerwash would mimic the behavior of ChromeOS and rinse would just reset any dangling configuration in the home directory

Personally, I'm significantly more interested in a powerwsshpowerwssh so let's begin there:

We can wipe the contents of /home without ramification. All necessary configs will just be pulled from /etc. so that handles resetting home
In an ideal world, we could just wipe /etc and /usr/etc would pick up the pieces, but that's far from the case. We need to determine what, following s fresh installation, is changed (and whether or not it's automated), pin those files, reset /etc, and restore the pinned files

Will think on this a bit more today while I wrap up Wolfi/CLI stuff

As for rinserinse, I think most conflicting configs when rebasing are out of .config.config. I've found removing that folder inconsequential but we should definitely explore that further at some point as I know KDE has skewed configs too. I think the dotfiles that get wiped should be explicitly set because we likely wouldn't want to clear out someone's Steam library for instance

Bigpod•4/20/24, 4:28 PM

i wish if we could powerwash/factory reset without being able to boot into OS

Bigpod•4/20/24, 4:28 PM

kinda like windows can

Bigpod•4/20/24, 4:29 PM

well in theory you could just remov whole /etc and replace it with one from image

EyeCantCU•4/20/24, 4:31 PM

I still think a generic Ublue image with restoration utilities could be helpful. Either install it on a flash drive or a separate partition, boot into it, run just powerwashjust powerwash, decrypt the drive, and it does it's thing... but that's going way out of scope for an initial feature

EEyeCantCU I still think a generic Ublue image with restoration utilities could be helpful....

dreamyuki•4/20/24, 4:31 PM

uRestore

EEyeCantCU I still think a generic Ublue image with restoration utilities could be helpful....

Bigpod•4/20/24, 4:32 PM

and it woild be hard to achieve currently at least with seperate partition

Ddreamyuki uRestore

EyeCantCU•4/20/24, 4:34 PM

Would definitely have to be uFixit

dreamyuki•4/20/24, 4:35 PM

uFixit yourself

j0rge•4/20/24, 4:36 PM

https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base

GitLab

bootc-org / fedora-bootc / Fedora Bootc Base · GitLab

GitLab.com

j0rge•4/20/24, 4:36 PM

colin sent me this

j0rge•4/20/24, 4:37 PM

if someone has time to go dig in and see what you can find that'd be awesome, context:

j0rge•4/20/24, 4:37 PM

BTW on the build system side...I did a spike on this: https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base
it significantly reduces the "rpm-ostree/ostree stuff" for the "base image from scratch" flow and is way more "container native". It's just a rough draft so far, I haven't tried using it "in anger" like to build a desktop with or anything, but I'm much happer with this as a landing spot than what we have with the existing rpm-ostree YAML bits.

GitLab

bootc-org / fedora-bootc / Fedora Bootc Base · GitLab

GitLab.com

Jj0rge https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base

dreamyuki•4/20/24, 4:40 PM

https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base#adding-arbitrary-content-making-arbitrary-changes
this is interesting, so DNF is being used instead of rpm-ostree?

GitLab

bootc-org / fedora-bootc / Fedora Bootc Base · GitLab

GitLab.com

Robert•4/20/24, 4:41 PM

DNF being used in the "builder" container, which is regular Fedora
This is then packaged as an OCI archive somehow and copied to the scratch image

Jj0rge > BTW on the build system side...I did a spike on this: https://gitlab.com/bootc...

Bigpod•4/20/24, 4:45 PM

i can look into this but yea as far as i know he want to achieve the end in which you deploy oci image without any ostree bits at all

Bigpod•4/20/24, 4:45 PM

what im sitll waiting for is bootupd to be able to do any distro

Bigpod•4/20/24, 4:47 PM

i really want to be able to make some other distros not just fedora

EyeCantCU•4/20/24, 4:48 PM

The build rationale is really comprehensive: https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base/-/blob/main/README-build-rationale.md?ref_type=heads

GitLab

README-build-rationale.md · main · bootc-org / fedora-bootc / Fedor...

GitLab.com

EEyeCantCU I'm thinking two features here, but let's start with one: `just powerwash` and ...

fiftydinarOP•4/20/24, 4:49 PM

Resetting gsetting is also useful & something I do in my image

Bigpod•4/20/24, 4:50 PM

looking at the containerfile its quite genious and works based on fedora:40 image not some special rpm-ostree image

EyeCantCU•4/20/24, 4:55 PM

Looking at the build scripts and it's brilliant

EyeCantCU•4/20/24, 5:03 PM

This reminds me of how we handle -base-base packages in Wolfi

https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base/-/blob/main/bootc-full/bootc-full.spec?ref_type=heads

GitLab

bootc-full/bootc-full.spec · main · bootc-org / fedora-bootc / Fedo...

GitLab.com

EyeCantCU•4/20/24, 5:04 PM

(but obviously not as clean, but it can't be given they have to work with specs)

EyeCantCU•4/20/24, 5:09 PM

They also have inconsistent pulls from Quay

https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base/-/blob/main/plans/main.fmf?ref_type=heads#L30

Jj0rge > BTW on the build system side...I did a spike on this: https://gitlab.com/bootc...

bsherman•4/20/24, 5:23 PM

forget "significantly reduces" this nearly completely removes rpm-ostree from our consciousnesses regarding image builds!

pretty impressive!

and without using rpm-ostree, it's no wonder that bootc wipes out local package layers installed by rpm-ostree, it's just not part of the paradigm

j0rge•4/20/24, 5:25 PM

yeah

Bbsherman forget "significantly reduces" this nearly completely removes rpm-ostree from ou...

fiftydinarOP•4/20/24, 5:25 PM

how would the local user uninstall the "dnf" package from this experimental image?

j0rge•4/20/24, 5:25 PM

ugh git submodules, don't like that

Ffiftydinar how would the local user uninstall the "dnf" package from this experimental imag...

bsherman•4/20/24, 5:26 PM

the local user would not.

the entire design is to build images ... you want to customize? you build a new image with the changes

j0rge•4/20/24, 5:27 PM

yeah this is the full move to The Final Shape, you're not bringing all that stuff forward, pure cloud native.

EEyeCantCU This reminds me of how we handle `-base` packages in Wolfi 🙂 - https://gitlab.c...

bsherman•4/20/24, 5:27 PM

i actually think the reuse of spec here is pretty nice... it's well definied... rhel/fedora are very much RPM-centric, so resuing that to compose the whole OS image is cool

EyeCantCU•4/20/24, 5:28 PM

No problems there at all!

EyeCantCU•4/20/24, 5:28 PM

I think it's great

j0rge•4/20/24, 5:28 PM

yeah it lets you skip a step

j0rge•4/20/24, 5:28 PM

like imagine if we're just putting the specs in here

Jj0rge ugh git submodules, don't like that

bsherman•4/20/24, 5:29 PM

i don't read that as "git submodules are required" for custom images... just a possible way if you want to rebuild the world

j0rge•4/20/24, 5:29 PM

file issues and leave feedback, the more we give feedback the less work for us in the future.

Bbsherman i don't read that as "git submodules are required" for custom images... just a p...

j0rge•4/20/24, 5:29 PM

yeah I know I was just in the mood to maybe try it now I'm like, ugh every time I run into those things it ruins an afternoon for me

j0rge•4/20/24, 5:29 PM

then I realized ya'll will do a better job playing with it than me

Robert•4/20/24, 5:29 PM

Pretty sure this pattern isn't meant for us. This is how Fedora is hoping to build their silverbluesilverblue, kinoitekinoite etc images which we then consume in the same way we are now

it significantly reduces the "rpm-ostree/ostree stuff" for the "base image from scratch" flow and is way more "container native".
...
I'm much happer with this as a landing spot than what we have with the existing rpm-ostree YAML bits.

bsherman•4/20/24, 5:30 PM

biggest concern i see, this will be a major paradigm shift for existing Fedora Silverblue users... mostly due to the lack of local layering...
so, politically in Fedora, maybe that's a problem..

but for us, it would be awesome...

I'd love to take a bootc Fedora Silverblue/Kinoite as our foundation for our images... MUCH cleaner

j0rge•4/20/24, 5:30 PM

yeah but also that work is taking forever and basically stalled, I wonder if we can combine this with other work

The scope of powerwash is not well defined in the issue imo. https://github.com/ublue-os/main/issues

Similar Threads

Similar Threads

Similar Threads