On 2020-08-15 08:43, seroton10@gmail.com wrote:

Hi,

When installing openSUSE (any flavour), the installer offers a choice between the "server" and "transactional server" roles, among others.

If I choose to install using the "server" role, is there a (supported) procedure by which I can later convert it into a "transactional server"? (Assume using btrfs for /, and having snapshots.)

I tried to do this conversion on a test system running openSUSE Leap 15.2 as follows:

* run "zypper install patterns-base-transactional_base" * edit /etc/fstab to make root read-only * reboot

This appears to work: The system self-updates, and reboots when needed; /etc has been turned into an overlay filesystem; and zypper up tells me to use the transactional-update tool.

However, one of the packages installed during the conversion is "read- only-root-fs", and its description contains a rather stern warning:

Files, scripts and directories to run the system with a read-only root filesystem with /etc writeable via overlayfs.

This package should never be installed in an already running system! It should only be selected by a system role for a read-only root filesystem with transactional updates. The package will create / modify entries for mounting /etc and /var. Those entries are used by dracut to mount the overlay file systems during the early boot phase.

After reading this, I ask myself, was it just dumb luck that the test system wasn't destroyed during the conversion? What can/does go wrong if read-only-root-fs is installed in an already running system, against the advice given?

Any clarification on this would be much appreciated.

I think it was mostly dumb luck. There are some pretty invasive changes to your system done by that package eg. https://github.com/openSUSE/read-only-root-fs/blob/master/usr/sbin/setup-fst... There are also additional layers of configuration done by the system role you have probably neglected, such as marking the read-only property on the btrfs / subvolume (the fstab is too easily overriden to be the only way to mark your root read-only). The server system role also has a significantly different partitioning configuration from the transactional server one. Server requires 5GB or 17.5GB if btrfs with snapshots. Snapshots will be auto disabled if system does not have a large enough partition. Transactional Server requires 20GB. btrfs w. Snapshots are mandatory Transactional Server has /boot/writable subvolume for Ignition, regular Server does not. I think you got rather lucky to have a working system after your experiments :) Congratulations -- Richard Brown Linux Distribution Engineer - Future Technology Team SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Ignaz, and Richard, On Fri, 2020-08-21 at 09:48 +0200, Ignaz Forster wrote:

Hi Olav,

Am 15.08.20 um 08:43 Uhr schrieb seroton10@gmail.com:

...

Hi,

When installing openSUSE (any flavour), the installer offers a choice between the "server" and "transactional server" roles, among others.

If I choose to install using the "server" role, is there a (supported) procedure by which I can later convert it into a "transactional server"? (Assume using btrfs for /, and having snapshots.)

No, this is unsupported - see Richards mail for the differences between the roles.

...

[cut] Any clarification on this would be much appreciated.

I was also quite surprised to see this approach working - I would have expected that at least the /etc overlays would be falling apart.

So I just checked the read-only-root-fs spec file. The necessary directories will be created there even on an existing system, so you may indeed have created a working setup ;-)

HOWEVER: The warning is imho completely legitimate. Installing this package will not magically convert an existing read-write system into a read-only system, but will require manual interaction. In fact you missed one important step: The root subvolume should also be set read-only (i.e. not only setting the read-only flag in fstab but by calling `btrfs property set / ro true`). You may have to mount the root file system rw again for this operation to succeed, or call it directly on the snapshot directory in /.snapshots/xxx/snapshot).

I never got back to thank you guys for your responses, but I'd like to add that to the record now. For your information: After applying the btrfs read-only property manually, as suggested, I just left the machine (a Raspberry Pi 3) running. It is still running just fine, after having been powered on non-stop for 6 months. By "just fine" I mean I can do SSH login to it, and nothing seems to be exploding - not disk usage, not the overlay hierarchy, etc. I would also like to add that I think it would be a very cool feature to be able to enable transactional updates on an openSUSE system that was not installed with the transactional server role. Providing that a certain set of minimum requirements are met, of course. Even if such a retrofitted system is not identical to a real transactional server, and maybe doesn't support all its features, from my experience it still seems like a very useful thing to be able to do. IMHO. Again, thank you for your feedback. Regards, Olav

On Sun, 2021-02-28 at 09:41 +0100, Syds Bearda wrote:

On Sat, Feb 27, 2021, at 23:23, Olav Reinert wrote:

...

For your information: After applying the btrfs read-only property manually, as suggested, I just left the machine (a Raspberry Pi 3) running. It is still running just fine, after having been powered on non-stop for 6 months. By "just fine" I mean I can do SSH login to it, and nothing seems to be exploding - not disk usage, not the overlay hierarchy, etc.

One of the nice things of MicroOS and transactional-update is the automatic upgrades. Where the server reboots by itself and performs the upgrade. Which should be a few days a week. Having an uptime of 6 months makes me think something is not working right.

I didn't say anything about uptime, only that the machine has been powered on and running for 6 months.

A mutable OS like TW or Leap can be upgraded usually without a reboot. An immutable OS like MicroOS can only upgrade with a reboot, as the /root is read only.

In fact, uptime on this RasPi3 is rarely more than a few days because it is self-upgrading and rebooting regularly, as evidenced by /var/log/transactional-update.log, among other things. Regards, Olav

Am 2021-02-27 um 23:23 schrieb Olav Reinert:

[...] I would also like to add that I think it would be a very cool feature to be able to enable transactional updates on an openSUSE system that was not installed with the transactional server role. Providing that a certain set of minimum requirements are met, of course. Even if such a retrofitted system is not identical to a real transactional server, and maybe doesn't support all its features, from my experience it still seems like a very useful thing to be able to do. IMHO.

That's already possible by simply running the transactional-update features while being careful to not change the running system with zypper :) For example we use that - for fun and out of interest - on one of the machines within the openqa.opensuse.org infrastructure. Most machines there have a read-only root filesystem except for one but applying the updates and rebooting to activate the updated system is done in the same way on all machines.