Has anyone reported any issues on upgrade first?
Has anyone reported any issues on upgrade first?
Jwe may need to pin a kernel
MSo, latest and gts didn't get tagged today
Mfor bluefin
MThe images that built today didn't get tagged with them so we'll need to review that. But this does gives us some breathing room to come up with a plan for updating the bootloader
Jah does that explain @marc's issue?
MIt would explain why there was no update today. I'm unsure why he thought there has been no update for weeks
Mmisread. He was saying no update from the image labeled the 6th
Mbut yes, that would explain why he didn't get today's update
Mour version tag often is a day off from the creation date
M20240408 matches though
Bmy custom image of silverblue updated to 6.8.4 and i saw no issues on multiple machines... (Dell XPS 15 9520, Dell XPS 15 7590, Thinkpad T480, HP Elitebook 845 14 G9)
maybe i'm missing something. i don't use bootupctl, though it is installed since we include bootc in main?
maybe i'm missing something. i don't use bootupctl, though it is installed since we include bootc in main?
Jnot 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
