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 | fpaste should do the trickJyes, 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 statusfpaste?Jwhile 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
--sysinfo, problem is that I don't know how to combine the sysinfo and the rpm-ostree statusJcan 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
J
JThis is nice, scientific evidence of @nickname 's awesomeness.
Gnot currently no
Ggo for it
Jor just displaying on the terminal is fine
Jif the sysinfo is too excessive maybe a simpler combo from existing tools might do the trick
Jno rush, was just thinking about it as this happened to me today
Jyeah I learned a bunch too
FGitHub
systemctl reboot --firmware-setup doesn't support this.
That command calls: org.freedesktop.login1.Manager SetRebootToFirmwareSetup, which is the DBUS interface of systemd-logind.
That command calls: org.freedesktop.login1.Manager SetRebootToFirmwareSetup, which is the DBUS interface of systemd-logind.
R@jstone You may want to check your F40 builds now. I was receiving the same tar error as you, but today they seem to be working.
JThanks for the heads up
JStill seems to be failing though https://github.com/joshua-stone/rose-os/actions/runs/8532577191/job/23614998501?pr=18
GitHub
ublue-os with fewer downstream modifications. Contribute to joshua-stone/rose-os development by creating an account on GitHub.
N@M2 do you have some free time sometime today to review your PR? I'm trying to reconcile how I can get it added to the testing branch to actually test your code.
MI could hop into a voice chat around 4pm EST
Nunfortunately I am booked from 2PM - 4PM CST. Is 1PM CST possible? over lunch?
MI'm busy 12:45 PM - 2 PM EST. Are you available later today? 4 PM CST I think is 5 PM EST and I could do a call then
NI can do 4PM CST.
MOkay, I'll hop on around then
NI have a meeting that bumps up right against that time, but hopefully shouldn't go over.
NI'll let you know if it does.
