we don't make ISOs of them so each person who tried 40 had to rebase right?
we 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
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.
