Long time Debian user but this Silverblue looks interesting.
Just spit balling, here. Could the immutable portion of Silverblue be configured to run atop a hypervisor and /var migrated between them so that the user never experiences a “reboot”?
Hmmm … how would that work? Wouldn’t you have the same effective experience of needing to shut everything down to use the new stuff? No hardware reboot, but similar user experience…
Let’s say, for example, we have a minimal hypervisor from which Silverblue runs on. Inside of this hypervisor, we have Silverblue 36 and the user wants to try Silveblue 37 - each on their own .VHD. That installs as an additional VM in the hypervisor and, after the install, /var (being its own VHD) is migrated to point to the VM running 37. 36 is still running and dormant, but without /var.
I’m sorry, I must be being very dense here. Hand-waving getting it all plumbed together… what is the user advantage in this? Faster switch-over?
Yes, and not having to close apps, etc. Sorry, I may be totally off and what I’m speaking of may not be possible. I’m looking at this from a very high level.
I think this would be in principle no different from doing the same with some other distribution.
Probably it would be easier to try this with regular Fedora Workstation first, as there you wouldn’t have to make this all also fit in with the rpm-ostree stuff during boot.
No because it’s still using SystemD. If you rebase from 36 to 37, the new OS image will have a new kernel and systemD version which will require a reboot to load. That’s part of the magic though of atomic upgrades is that you can easily roll back the system to the previous image.
Right, yeah, that’s my thought too — and not just systemd, but glibc, and for that matter all the way up to GNOME. The vm switch would keep you from having to actually go down to the bios-level and back up again, but you’d still have the basic experience of shutting down the system and all your applications and then booting into a new one.
Plus now, sometimes you have to update the underlying hypervisor…
1 Like
Understood. I appreciate the quick feedback. Nice community you have here.
2 Likes
Well, you could use ostree capabilities and switch to the new deploy without a reboot I believe, but I haven’t tried it. I know WS people have discussed using BTRFS capabilities to live switch an upgrade, same idea I guess. And thanks, welcome to 
!
1 Like