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.
Regards, Olav
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
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.
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 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).
Cheers, Ignaz
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 Sat, Feb 27, 2021, at 23:23, Olav Reinert wrote:
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.
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.
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.
/Syds
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.
-
Ignaz Forster -
Olav Reinert -
Oliver Kurz -
Richard Brown -
seroton10＠gmail.com
-
Syds Bearda