not sure, but at least part of it has to do with a rebase?
not sure, but at least part of it has to do with a rebase?
J
Byeah, i did updates, not rebases
Jso we've had this in our images forever
Bmaybe that's helpful?
Bthe bug report doesn't give a lot to go on
Joh no, sorry, bootc is on our images
Jnot bootupd
Bi think bootc pulls in bootupd
JI have bootupdctl on my machine
Msame here
BJok so maybe what he means is "we need to add bootupd to the stock fedora 39 images" as in for silverblue/kinoite?
Byes, i do think that is Timothee's suggestion... in which case, our early adoption may be saving us
KI think so
KAnd then the get it
ESorry, working through something that's high priority. If no one has gotten to this, I should have some time tonight
Jlooks like we may be good?
MFor bluefin tags. Looks like we lost adding the tags to the bash array.
https://github.com/ublue-os/bluefin/actions/runs/8605061498/job/23580493765#step:8:20
https://github.com/ublue-os/bluefin/actions/runs/8605061498/job/23580493765#step:8:20
Bi added comment here https://github.com/ublue-os/main/issues/551#issuecomment-2043697788
JI'm digging through the issues linked here:
JBper this user report, i don't think a rebase was required, as this user hit the issue with a silverblue 39 update https://github.com/fedora-silverblue/issue-tracker/issues/543#issuecomment-2041433222
Jyeah and how many people have been rebasing onto 40 since we enabled them?
Jwe don't make ISOs of them so each person who tried 40 had to rebase right?
Bcorrect
Mbketlsen rebased
Jhuh, so maybe we dodged a bullet?
Bthat's the gist of my comment on the tracking issue... not sure if Timothee would have feedback but i bet he's slammed with all this on top of normal stuff so i don't want to bug him about it
Jor are currently in progress of dodging the bullet, heh.
Bi'd like to better understand how having bootupd installed would have "magically" saved us... it's not clear to me yet since i'm not aware of us directly requesting it to do anything
Jonly error that matches here
J"Fedora Atomic systems (rpm-ostree based systems) do not update the BIOS / EFI bootloaders files by default on updates as this operation may fail and leave the system in an un-bootable state.
The bootupd project has been created to fix this issue, creating a user/administrator triggered process to update the bootloader."
The bootupd project has been created to fix this issue, creating a user/administrator triggered process to update the bootloader."
Bon bazzite there's a different issue from stock atomic or even ublue, given the fully custom signed kernel, i don't think bazzite really relies on the shim given they don't use the fedora signed kernel
Jyeah I'm just pointing out that we haven't had any reports yet
JSo I'm thinking we keep an eye open and let the situation develop
MIt has a socket and service that is running by default?
Bsure, but if rpm-ostree wasn't directed to use it and bootupctl wasn't being used, how would it be activated?
MFair. I honestly don't understand how grub updates are supposed to work here if rpm-ostree isn't doing them either
BI'm open to maybe it did save us, I'm just ignorant of how. 
J
Gfpaste
Gcat foo | fpasteyes, that's what the issue says
Gah
GI see now
JI mean it as a convenience wrapper, auto put the rpm-ostree status and whatever else we need
Jso like, they run one command, paste it in, then we don't have to be like "please stop cutting out the most important lines" in discord, lol
