A
AIt does in some way, because of the need for
rpm-ostree kargsIf we could just edit /etc/default/grub it would not be in every guide ever to: "run kargs manually!".
ARemember RPM Fusion? They have Silverblue NVIDIA driver instructions which includes telling people to layer the NVIDIA driver image, which in turn causes those flags to be added to
/etc/default/grubrpm-ostree kargsThat's rpm-ostree not ostree
Athe bootloader afaik it's not part of the ostree commit
AOh yeah true, so the limitation might only exist in the rpm-ostree package layering mechanism,
Rthe
rpm-ostree kargsYeah I think so too now. They might have made rpm-ostree incapable of editing existing files in
/etc//etc/ostreeOh I think I've figured it out... rpm-ostree places
/etc//usr/etc//etc/So tl;dr: Your boot args are in your etc file permanently and will stay there.
rpm-ostree kargsThis older Fedora article indicates they are using
/etc/kernel/cmdline
AYeah I remember that bug. Either way it's all 
/etc/
PMy understanding was that the etc merge works like this: if you have modified the file in any way, the file is left alone and you don't get the update. If you haven't modified it it'll be updated to what's in the new /usr/etc
P(where "modified in any way" means "doesn't match what's in the old /usr/etc)
AIt'll apply a diff if it can
AOr at least it's supposed to, I haven't checked
PHuh, that's not how I had seen it described.
AIt applies a 3-way merge which solves simple conflicts automatically. But if there's a mismatch it leaves your file alone and you have to run a command to merge manually.
AIt's honestly harder to explain the actual behaviour and not worth going into details most of the time imo but here it is https://blog.verbum.org/2014/01/24/why-ostree-requires-usretc/
Colin WaltersColin Walters
While I often lump “dpkg/rpm” together since they’re very similar architecturally, their implementation of configuration file management is a small but nontrivial difference. This…
AOne cool thing is that since 
/usr/etc/I think of it mostly as you explained because I don't count on that three way merge to work reliably
PYes that's what I was saying
It doesn’t attempt to understand the contents of files – if you have modified a config file in any way, that wins
AMm you're right
AI read elsewhere that it's running a patch/diff, similar to this: Generate a patch between your
/usr/etc//usr/etc//etc/Not sure why he calls it a 3-way merge though if it is not merging anything
AYeah that blog is a mess of mixed up terms.
AOfficial docs are here and they mention the thing I just said: https://ostreedev.github.io/ostree/deployment/
PGitHub
Operating system and container binary deployment and upgrades - ostree/atomic-upgrades.md at 16cb47489e582da9c139fee20acdac7079867843 · ostreedev/ostree
ABut read this from the OSTree website:
When OSTree creates a deployment, it performs a 3-way merge using the old default configuration, the active system’s /etc, and the new default configuration. In the final filesystem tree for a deployment then, /etc is a regular writable directory.
PHow it works is:
- Files in the currently booted deployment's
which were modified from the default/etc(of the same deployment) are retained./usr/etc- Files in the currently booted deployment's
which were not modified from the default/etc(of the same deployment) are upgraded to the new defaults from the new deployment's/usr/etc./usr/etc
AWhy does their own website contradict the part you just quoted?
PI don't think it's a contradiction do much as ambiguous use of the term "merge"
AYeah it could just be poorly explained. Grr.
PIndividual files aren't being merged, but the entire /etc tree is being merged in a very coarse grained way
AOh yeah that makes sense. What a poor way to phrase that on their site. I've always thought it did a 3-way merge per-file, not directory-wise.
AI've never even thought of directory comparisons as "3-way merging".
PYeah it's definitely not the best way to explain it without a bit more detail
AYeah, thanks for finding that, it's very useful to know. That changes how I'll maintain my system. I will run the "config diff" more often to resolve actual changes.
PIt's probably just a case of the people writing the docs being familiar enough with how it works that the explanation seems obvious enough - even though it's a bit unclear without the extra detail to someone not as familiar.
AYeah it's a common curse when trying to document a complex system that you're very familiar with.
PYeah my plan is to try to avoid touching things in /etc at all where possible
Ait'd be cool to have a script that does this and notifies
AYep, one thing I always do is edit the wireplumber config to add a script that disables audio device sleeping, to avoid that silent "popping" whenever audio begins playing again. I am doing it via some big edits.
I've been meaning to look for a way to install that in a more granular way that doesn't need maintenance constantly whenever wireplumber changes config.
I've been meaning to look for a way to install that in a more granular way that doesn't need maintenance constantly whenever wireplumber changes config.
AYeah good idea, some kinda GUI that runs as autostart on login and pops up if there's changes. dreams
dreamsPYeah I think having some kind of automated check that can keep tabs on the diff to prevent drift would be interesting
Ayou don't really need a gui, just run the command if there are changes send a dbus notification
PA bit complicated because there's a bunch of things that are probably going to be changed just by installing though, like /etc/passwd
AGreat idea
AI wish anaconda put this stuff in /usr/etc before commiting the deployment to disk...