Run `cat /proc/cmdline` and look for those flags to be sure
Run
cat /proc/cmdline and look for those flags to be sure
Rthere are some other exe files inside the installer, but how would I use those in Linux?
AWith a FreeDOS USB boot stick, boot into the DOS environment and run the exe.
Rthis contains the same args as the /etc/default/grub and /boot/grub2/grub.cfg file
AThat must mean that when the modules are bundled instead of layered, they become part of the actual boot args, unlike when they are manually layered with
rpm-ostree installrpm-ostree kargsNo... that theory makes no sense. Because if you install regular Silverblue and rebase to the
nvidiakargs command...AIt seems like the Nvidia ISO is an exception to this rule.
RAhh FreeDOS I don't think I've ever used it. Might give it a go later
AIt's pretty painless, unless the
.exe@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
AYea it just surprises me greatly because the ublue repos and ublue isogenerator don't contain the words
kargs or cmdline anywhere.Rdid you try a search for modeset?
ABingo:
AIt's part of the Fedora kickstart installer script used by the NVIDIA ISO!
ASo this is the one and only scenario where the command doesn't have to be executed manually. 
RGitHub
Fedora variants with built-in Nvidia drivers. Contribute to ublue-os/nvidia development by creating an account on GitHub.
Rset-kargs:
rpm-ostree kargs \
--append=rd.driver.blacklist=nouveau \
--append=modprobe.blacklist=nouveau \
--append=nvidia-drm.modeset=1
AYeah that's a different file, that's for the
just set-kargs command which runs the command I mentioned, it's a manual thing you do after install.AThe file responsible for the ISO settings is here:
https://github.com/ublue-os/isogenerator/blob/main/installer/kickstart/ublue-os-nvidia.ks#L7
https://github.com/ublue-os/isogenerator/blob/main/installer/kickstart/ublue-os-nvidia.ks#L7
AI 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.
AYou 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.
Rthat'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
AAOSTree is a totally different way to boot a distro. It's what makes it immutable but also difficult in some ways.
AFedora Docs
Learn more about Fedora Linux, the Fedora Project & the Fedora Community.
RSilverblue is meant to do a three way merge of files under /etc so it should
AYep thanks, had a quick look but it doesn't say whether it's permanent after ostree updates.
AThat;s the docs for kickstart itself, which regular Fedora uses too.
Aostree doesn't even manage the bootloader
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/ to prevent confusing merges with user-edits vs operating system edits. Anything you edit in /etc/ becomes seen by the REAL ostreeOh I think I've figured it out... rpm-ostree places
/etc/ files from layered RPMs in /usr/etc/ and then systemd attempts to merge them into /etc/ 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.ASo 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 https://fedoramagazine.org/manual-action-required-to-update-fedora-silverblue-kinoite-and-iot-version-36/
AYeah I remember that bug. Either way it's all 
/etc/ 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. 
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/ 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. AI think of it mostly as you explained because I don't count on that three way merge to work reliably