@Arcitec before I ran the uBlue ISO install the laptop had vanilla Silverblue. I haven't set any man

@Arcitec before I ran the uBlue ISO install the laptop had vanilla Silverblue. I haven't set any manual commands, I just ran the installer. Apart from fixing my ancient bios errors, it's all automated

Rragectl @Arcitec before I ran the uBlue ISO install the laptop had vanilla Silverblue. I...

Arcitec•5/14/23, 2:06 AM

Yea it just surprises me greatly because the ublue repos and ublue isogenerator don't contain the words or anywhere.

ragectlOP•5/14/23, 2:07 AM

did you try a search for modeset?

Rragectl did you try a search for modeset?

Arcitec•5/14/23, 2:08 AM

Bingo:

Arcitec•5/14/23, 2:08 AM

It's part of the Fedora kickstart installer script used by the NVIDIA ISO!

Arcitec•5/14/23, 2:08 AM

So this is the one and only scenario where the command doesn't have to be executed manually.

ragectlOP•5/14/23, 2:10 AM

https://github.com/ublue-os/nvidia/blob/main/justfile

GitHub

nvidia/justfile at main · ublue-os/nvidia

Fedora variants with built-in Nvidia drivers. Contribute to ublue-os/nvidia development by creating an account on GitHub.

ragectlOP•5/14/23, 2:11 AM

set-kargs:
rpm-ostree kargs \
--append=rd.driver.blacklist=nouveau \
--append=modprobe.blacklist=nouveau \
--append=nvidia-drm.modeset=1

Arcitec•5/14/23, 2:11 AM

Yeah that's a different file, that's for the command which runs the command I mentioned, it's a manual thing you do after install.

Arcitec•5/14/23, 2:11 AM

The file responsible for the ISO settings is here:

https://github.com/ublue-os/isogenerator/blob/main/installer/kickstart/ublue-os-nvidia.ks#L7

Arcitec•5/14/23, 2:12 AM

I don't know how permanent that is. It tells Kickstart to install Fedora with that as its current boot arguments. Will it persist after future kernel upgrades, when the grub config is re-generated from a new ostree commit? That remains to be seen.

Arcitec•5/14/23, 2:13 AM

You have to realize that there's so much trouble with getting kernel args into OSTree distros. It's not as simple as editing /etc/grub stuff.

ragectlOP•5/14/23, 2:14 AM

that's the point of having the /etc/default/grub file with those settings because that's what Grubby etc in Fedora should be using to get kernel args

Rragectl that's the point of having the /etc/default/grub file with those settings becaus...

Arcitec•5/14/23, 2:14 AM

But it won't. See: https://github.com/coreos/rpm-ostree/issues/3738

Arcitec•5/14/23, 2:14 AM

OSTree is a totally different way to boot a distro. It's what makes it immutable but also difficult in some ways.

AArcitec I don't know how permanent that is. It tells Kickstart to install Fedora with th...

akdev•5/14/23, 2:15 AM

https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/appendixes/Kickstart_Syntax_Reference/#sect-kickstart-commands-bootloader

Fedora Docs

[f36] Kickstart Syntax Reference

Learn more about Fedora Linux, the Fedora Project & the Fedora Community.

ragectlOP•5/14/23, 2:16 AM

Silverblue is meant to do a three way merge of files under /etc so it should

Aakdev https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/appendixes/Kicksta...

Arcitec•5/14/23, 2:16 AM

Yep thanks, had a quick look but it doesn't say whether it's permanent after ostree updates.

Arcitec•5/14/23, 2:16 AM

That;s the docs for kickstart itself, which regular Fedora uses too.

akdev•5/14/23, 2:17 AM

ostree doesn't even manage the bootloader

akdev•5/14/23, 2:17 AM

Aakdev ostree doesn't even manage the bootloader

Arcitec•5/14/23, 2:17 AM

It does in some way, because of the need for to add boot arguments.

Arcitec•5/14/23, 2:18 AM

If we could just edit /etc/default/grub it would not be in every guide ever to: "run kargs manually!".

Arcitec•5/14/23, 2:19 AM

Remember 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 via the RPM setup scripts in the NVIDIA driver. Yet they STILL tell people to manually run .

akdev•5/14/23, 2:20 AM

That's rpm-ostree not ostree

akdev•5/14/23, 2:20 AM

the bootloader afaik it's not part of the ostree commit

Arcitec•5/14/23, 2:21 AM

Oh yeah true, so the limitation might only exist in the rpm-ostree package layering mechanism,

ragectlOP•5/14/23, 2:22 AM

the command lists the same kernel arguments. So I suspect they are just using this as a method to update the cfg file that is symlinked to /boot/loader/grub.cfg

Arcitec•5/14/23, 2:23 AM

Yeah I think so too now. They might have made rpm-ostree incapable of editing existing files in to prevent confusing merges with user-edits vs operating system edits. Anything you edit in becomes seen by the REAL as "user edited". I guess they wanted to avoid that.

Arcitec•5/14/23, 2:24 AM

Oh I think I've figured it out... rpm-ostree places files from layered RPMs in and then systemd attempts to merge them into automatically, if possible. This is possible if the file is new or if the edit is trivial. But I am guessing kernel args are non-trivial and won't auto-merge, hence the need for manually editing the grub config.

Arcitec•5/14/23, 2:25 AM

So tl;dr: Your boot args are in your etc file permanently and will stay there. is most likely just a tool for quickly editing the etc file.

ragectlOP•5/14/23, 2:26 AM

This older Fedora article indicates they are using https://fedoramagazine.org/manual-action-required-to-update-fedora-silverblue-kinoite-and-iot-version-36/

Fedora MagazineTimothée Ravier

Manual action required to update Fedora Silverblue, Kinoite and IoT...

Manual action required to update Fedora36 Silverblue, Kinoite and IoT

Rragectl This older Fedora article indicates they are using `/etc/kernel/cmdline` https...

Arcitec•5/14/23, 2:27 AM

Yeah I remember that bug. Either way it's all related which explains why some things can't be automatically merged without intervention. But your system as it is now has already had those args applied and should be permanently ready now.

AArcitec Oh I think I've figured it out... rpm-ostree places `/etc/` files from layered R...

pythoner6•5/14/23, 2:29 AM

My 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

pythoner6•5/14/23, 2:31 AM

(where "modified in any way" means "doesn't match what's in the old /usr/etc)

akdev•5/14/23, 2:31 AM

It'll apply a diff if it can

akdev•5/14/23, 2:31 AM

Or at least it's supposed to, I haven't checked

pythoner6•5/14/23, 2:32 AM

Huh, that's not how I had seen it described.

Ppythoner6 My understanding was that the etc merge works like this: if you have modified th...

Arcitec•5/14/23, 2:32 AM

It 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.

Ppythoner6 Huh, that's not how I had seen it described.

akdev•5/14/23, 2:33 AM

It'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

Why OSTree requires “/usr/etc”

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…

Arcitec•5/14/23, 2:33 AM

One cool thing is that since are the "ground truth templates", you can always run an ostree config diff to see what files you have changes in or files that you;'ve kept that don't exist upstream.

akdev•5/14/23, 2:33 AM

I think of it mostly as you explained because I don't count on that three way merge to work reliably

Aakdev It's honestly harder to explain the actual behaviour and not worth going into de...

pythoner6•5/14/23, 2:33 AM

Yes 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

akdev•5/14/23, 2:34 AM

Mm you're right

Ppythoner6 Yes that's what I was saying > It doesn’t attempt to understand the contents of ...

Arcitec•5/14/23, 2:34 AM

I read elsewhere that it's running a patch/diff, similar to this: Generate a patch between your and the new deployment's and then apply those patches to your and just ignore the ones that failed to apply.

akdev•5/14/23, 2:35 AM

Not sure why he calls it a 3-way merge though if it is not merging anything

Arcitec•5/14/23, 2:35 AM

Yeah that blog is a mess of mixed up terms.

Arcitec•5/14/23, 2:36 AM

Official docs are here and they mention the thing I just said: https://ostreedev.github.io/ostree/deployment/

pythoner6•5/14/23, 2:37 AM

https://github.com/ostreedev/ostree/blob/16cb47489e582da9c139fee20acdac7079867843/docs/atomic-upgrades.md?plain=1#L76

GitHub

ostree/atomic-upgrades.md at 16cb47489e582da9c139fee20acdac70798678...

Operating system and container binary deployment and upgrades - ostree/atomic-upgrades.md at 16cb47489e582da9c139fee20acdac7079867843 · ostreedev/ostree

Ppythoner6 https://github.com/ostreedev/ostree/blob/16cb47489e582da9c139fee20acdac707986784...

Arcitec•5/14/23, 2:37 AM

But 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.

pythoner6•5/14/23, 2:37 AM

How it works is:
Files in the currently booted deployment's which were modified from the default (of the same deployment) are retained.
Files in the currently booted deployment's which were not modified from the default (of the same deployment) are upgraded to the new defaults from the new deployment's .