Hello,
I’m thinking about using Tumbleweed or MicroOS for a home server. Especially the “automated administration & patching” of MicroOS is interesting to me. I wonder if it’s possible to leverage the same mechanism to update Tumbleweed since MicroOS is Tumbleweed based.
Do you seriously expect MicroOS to not require administrator and administration? Any operating system needs someone to configure, manage and watch over it. If anything, MicroOS requires more during initial planning simply because it is more complicated to change after installation.
Which mechanism? This is technical forum, please do not repeat marketing buzz, provide reference to the technical feature you talk about.
@Stefanqn Hi and welcome to the Forum 
I see that rebootmgr is present in Tumbleweed, so if that is the path you want to take, it shouldn’t be an issue setting up along with the likes of packagekit… but system maintenance for me is a manual process…
1 Like
No fancy mechanisms required. I switched all machines I am administrating to Tumbleweed in recent years. They upgrade virtually unattended: Update error - Failed to obtain authentication - #7 by karlmistelberger.
as far as I understood MicroOS updates work with btrfs snapshots and roll back on failure. Yet I’m unaware but interested in how failures are detected, especially in regard to the criteria at service and OS level. If you could point me to some documentation where the marketing buzz is explained, that would be great. rebootmgr sounds to me like a smart way to schedule reboots, but I don’t understand how rollbacks happen.
I’m using other rolling-release distros for my work laptops for 7 years now and I would not recommend them for unattended updates. My Debian-based distros just had a 50% survival rate with dist-upgrades so I’m curious about what tumbleweed distros offer.
@Stefanqn I run Tumbleweed here as my daily system, no rollback/snapper but do use btrfs, no issues with zypper dup for over a year…
Yes. Same as Leap or Tumbleweed. The primary difference is that on Leap/Tumbleweed updates are applied to the running system and backup is created before update and on MicroOS updates are applied to a new clone of the current system and you need to reboot to activate it.
Applying updates to a new boot environment (I still like how Solaris who pioneered this idea called it) ensures that no incompatibility between running and updated components happens.
and roll back on failure
Well … that is a bit stretched (and more marketing buzz). There is a service that runs checks during boot and if this service returns failure, system is rebooted into previous snapshot. So it can detect some issues with updated components, but there are not many plugins, it is really basic checks. And if system fails to boot at all, I am not aware of any mitigation.
While this service is available in Tumbleweed it is not installed and enabled by default, see [FR] Auto rollback option a la microOS · Issue #21 · openSUSE/transactional-update · GitHub
Besides, bootloader is outside of snapshots and so failure of bootloader is really fatal. So do not overestimate “automatic rollback” capability.