@bsherman @Arcitec README ready to go? I PRed the markdown syntax fix just now
@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: anywhere in isogenerator code (local git checkout grep) and only one not-related occurance in 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
imgurlPAimageurl=ghcr.io/{{ GITHUB_REPOSITORY_OWNER }}/{{ flavor_menu.label }}:{{ RELEASE }}PBut 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=Bso 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.cfg sample kinoite linelinux /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:38Band from
pre-install.shostreecontainer --url="${URL}" --no-signature-verificationBI really starting the think the user in the bugreport has an old copy of ISO
Bbecause this bug DID exist in past but was fixed, right?
Ayeah it did
Amm we could ask them for an md5 hash of the iso
Bi'll do a test install
Jit installs but subsequent Discover (the kde app) crashes if it's on -image
Jhttps://github.com/ublue-os/main/issues/132 is what we have rn
GitHub
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 only fired up the VM today but in and out with calls for a while
Amm in that case I think isogenerator is out of the woods
Jyeah I have only chosen it on boot, installed it, and I did the status
Bwhoa. WTF
AYou were able to reproduce?