yes, i do think that is Timothee's suggestion... in which case, our early adoption may be saving us
yes, 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
Gso just pipe
rpm-ostree statusfpastewhile digging through the man page for fpaste I found --sysinfo.
Jso like, if we know we can get all the hw info + rpm-ostree status + whatever else we may think is useful then users would only ever have to worry about the one command
Gmm
Jand by default
Joooooooooo
Gplaying around with
--sysinfocan also just do that in a followup. 
Jjust fixing the truncating status would do us a solid
Jplus the nice thing is people can start socializing it now, so as we figure out new things to ask for it can be totally flexible in that way, but the command will remain the same for the users, which will pay off dividends over time
J
Jforum growth is visible now
J
