J3) add instructions for the big failure part where they undo stuff in the bios
Bwe bascially have the instructions with screenshots in the ISO installer part of website, i think, so that's helpful
Jok
JI'll start with those three items
Bthis is probably good to have in general for nvidia users FAQ
"what if my secure boot nvidia machine boots to black screen?"
"what if my secure boot nvidia machine boots to black screen?"
Bthanks! i really gotta unplug 
Di have weird issue after rebasing to kinoite-main:latest from kinoite-nvidia:latest
D
Dit still have justfile from kinoite-nvidia
BYes the new ublue-os-just RPM provides
nvidia.just on all images, but the profile shell script only includes it if you are running ublue nvidia derivative imagesJyeah when just gets includes in a stable release we'll be able to just include one in the other and that will let us have unified stuff but also the ability to customize and then it'd be really well organized compared to what we have today
JGitHub
Fedora variants with built-in Nvidia drivers. Contribute to ublue-os/nvidia development by creating an account on GitHub.
J@bsherman @Arcitec README ready to go? I PRed the markdown syntax fix just now
JGitHub
What happened? When using the iso to install ublue a rpm-ostree-backend error occurs mentioning invalid reference for OCI container ostree format. Relevant log output $ plasma-discover rpm-ostree-b...
JI can't even find a usage of
ostree-unverified-image anywhere in the org (new github code search rocks btw), so I'm wondering how this can be cropping up
Ahuh easiest way to confirm would to be mount to iso and search there
Ayou can use github.dev to search in the codebase itself, I've found github code search to not be good with partial searches
Aostree-unverified-registry:quay.io/exampleos/custom:latest - this will pull from a remote registry, and no signature will be required. In practice, this is just a shorthand for ostree-unverified-image:docker://quay.io/exampleos/custom:latest.
Bnew akmods key testing results in https://github.com/ublue-os/nvidia/issues/100
Jfound it, it's the iso
Jif you if install from the iso and pick kinoite you get ostree-unverified-image and not registry
Bdid you find where? i'm looking now
Jthat was my next question, where do I look?
Byeah, i'm confused, too
but it uses the
and i don't see
mainbut it uses the
isogeneratorand i don't see
docker:mainshould we try respinning a release?
Bfirst, when you say you found it, you mean, you did a test install and reproduced?
AThis would be in the grub.cfg in isogenerator
AWhere do you see the mistake?
AIs it in the grub command line?
Jhow do I find that?
Jthe system boots and can't update basically
AType "e" to edit
AWhile you have the problematic boot entry selected
AWait the system boots or the installer doesn't work?
B
PI'm assuming most relevantly https://github.com/ublue-os/isogenerator/blob/main/installer/overlay/x86_64/EFI/BOOT/grub.cfg#L51
Bbut it's all templates, so
Ain that file we pass
imgurlimageurl=ghcr.io/{{ GITHUB_REPOSITORY_OWNER }}/{{ flavor_menu.label }}:{{ RELEASE }}But I'd assume it's the kickstart/anaconda/whatever that's actually setting the full thing with ostree-unverified-xxx
Byep, it's not our templating or boot menu
Ayeah we just pass that to
ostreecontainer --url=so maybe a new build COULD help? if ostreecontainer stuff has an upstream update 
Bi want to reproduce the problem though, before making changes
Ais the problem we are having while installing or does it show after installing?
Acould someone verify the following:
1. download current iso
2.
3. check the generated grub.cfg, BOOT.conf files
4. check generated pre-install.sh script
1. download current iso
2.
mount -o loop $theiso3. check the generated grub.cfg, BOOT.conf files
4. check generated pre-install.sh script
Byep
Bfrom
grub.cfglinux /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-E-dvd-x86_64-38 nomodeset rd.live.check quiet inst.ks=hd:LABEL=Fedora-E-dvd-x86_64-38:/kickstart/ublue-os-nvidia.ks imageurl=ghcr.io/ublue-os/kinoite-nvidia:38