Well this is how it is and will be. The thing is these should be invisible to the user, just like in a chromebook kind of. It doesn’t really matter when the user reboots but when he does he gets the newest updates.
Some people of course reboot immediately when update is available and deployed. Some don’t.
But using hibernation is another thing and thats the users decision, but at the same time has to understand all the downfalls that come from it as it is totally unsupported in upstream fedora.
Without informing me at all, a year could go by, or two, without rebooting. I wouldn’t consider that safe. Since I don’t know, as a user of Bluefin I expect the updates are happening somehow.
Bluefin is proud to be suited for laptops. That’s a complete opposite approach versus Fedora.. so you can’t really use the same excuse that Fedora uses, can you?
Additionally, the 96% that Bluefin focused on, don’t know this about Fedora..
What excuse? There is no official support on hibernation on fedora and as our images are based on that it swims downwards. Doesn’t really matter if it’s a laptop or not.
And yes if you don’t reboot for a year you are totally unsafe. But then the issue is somewhere else than in the software.
dumb newbie question, but, how does the upgrade from 41 to 42 happen?
From admin guide it seems a simple power cycle is all that’s needed, but according to ‘About my system’ from top left cog icon I’m still on “Bluefin (Version: 41.20250504.2 / FROM Fedora Silverblue 41)” and I’ve restarted serveral times since this thread started.
I ran ujust rebase-helper to ensure I was on stable and not GTS.
Rebase Target is ghcr.io/ublue-os/bluefin-dx:stable
Confirm Rebase
error: Old and new refs are equal: ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:stable
ujust update tells me there are ~1.5 GB of things needed, so it looks like the automatic part didn’t work on my machine.
When is the update trigger time? Does it not fire if the computer is being actively used? (e.g. try not disrupt the user). This is a laptop so when it’s not being used it’s suspended or turned off in order to conserve battery power.
On Bluefin it looks like it’s 4:00am +10 min. It will also run shortly after booting, if the system was off at 4:00am.
The config file isn’t sudo writable, so not sure if it can be overridden. It might be possible to create another systemctl timer that runs at, say, 10:00am, or whenever your device is normally on.
uupd is smarter about this, takes CPU, battery and load into account. ublue-update did this too but we’re temporarily on our old service units so it’s more hamfisted than usual.
The team is pretty much all in on ISO work right now but LTS and bazzite testing are on uupd. It’s basically ready but needs some testing and care to bring to GTS and stable. gerblesh has been rocking this it’s just taken the back seat to integrate due to us working on the installation experience.
This is the next thing I want to prioritize for Bluefin, the works all done it just needs to be wired together.
We just refreshed these today so you likely have an older ISO. However don’t worry about it, when you do your first upgrade you’ll be right where you’re supposed to be.
Would that be 04:00 UTC or local time? …actually I don’t care. For myself knowing to periodically run ujust update is fine.
However Re: Bluefin’s aim to be “designed for people who do not want to care about their computer.”, if it’s a requirement for the machine to be running and network connected at 4am for updates to happen, that’s a problem.