Yeah the secure boot is enabled and nvidia modules are loaded. I can see in rpm-ostree that it's on
Yeah the secure boot is enabled and nvidia modules are loaded. I can see in rpm-ostree that it's on the ublue silverblue nvidia image
AThat's really nice news. Sounds like you remembered to run the command to set the kernel boot args too?
ROne question though, my silverblue-nvidia install hasn't prompted me to run any tools like Yafti and the Firefox isn't via Flatpak. Is that something not included in the ISO?
AYeah yafti is a tool for your own downstream images created from the template in the
Main and Nvidia images are very close to upstream silverblue, with some conveniences like RPM fusion, codecs etc installed.
ublue-os/startingpointMain and Nvidia images are very close to upstream silverblue, with some conveniences like RPM fusion, codecs etc installed.
RI haven't run any specific commands for kernel arguements, no
AOh okay you need to do that, ostree has a special security model where kernel boot args can only be set by you, the admin. It's listed here: https://ublue.it/images/nvidia/
R
RI will have a look
Rthat install ISO is three weeks old, so maybe missing some changes?
AThat iso pulls the latest image from the internet during install, so the ISO is meant to only be updated rarely. 
And no the iso doesn't seem to set kargs, I cannot find the word
And no the iso doesn't seem to set kargs, I cannot find the word kargsWell the kernel args have been set in /etc/default/grub and I didn't add them
Rthe rpmfusion modules do usually update those
AAI don't even think that /etc/default/grub's kernel args are used at all on silverblue
Edit: They're not used.
Edit: They're not used.
Rand of course the Acer bios updater for this old laptop requires Windows because it's a .exe file 
AHmm try opening it with 7zip and seeing if you can get the files from inside. It's usually some DOS exe and a firmware blob inside "windows BIOS updaters".
ROK well something is doing something because the /boot/grub2/grub.cfg linked to /boot/loader/grub.cfg has the same kernel options added
ARun
cat /proc/cmdlinethere 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
nvidiakargsIt 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
kargscmdlinedid 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 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 via the RPM setup scripts in the NVIDIA driver. Yet they STILL tell people to manually run
rpm-ostree kargsThat's rpm-ostree not ostree