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 main
Jshould 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:38Band from
pre-install.shostreecontainer --url="${URL}" --no-signature-verificationI 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?
Bthis is my machine... why do i have both URL patterns?
AI think this is rpm-ostree internally
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.
AThose two things should be equivalent?
Byeah, so we think Discover just can't handle the "longhand" format?
ABut I'm not sure what changed to make it show the full version
AMaybe some rpm-ostree update changed the way things are displayed
PI think this is supposed to be ok
ostree-unverified-image:docker://ghcr.io/bsherman/silverblue-nvidia-custom:latest
Bit certainly works for
i've got a couple machines showing
but one still running on
rpm-ostreei've got a couple machines showing
image:docker://38.20230514.0but one still running on
38.20230509.0registry:ghcr.ioAt least digging through https://github.com/ostreedev/ostree-rs-ext/blob/main/lib/src/container/mod.rs, It looks like
ostree-unverified-image:docker://ostree-unverified-image:registry:ostree-unverified-registry:Yeah, at least as far as direct ostree handling I think that's fine? Maybe Discover isn't handling something correctly here?
