3 ms·

Here’s the part that explains it from the GitHub page (https://github.com/pop-os/cosmic-epoch https://github.com/pop-os/cosmic-epoch): Read-Only Filesystem:

Here’s the part that explains it from the GitHub page (https://github.com/pop-os/cosmic-epoch https://github.com/pop-os/cosmic-epoch): Read-Only Filesystem: If you're not on an immutable distro you may notice that /usr/ and /opt/ are read-only. this is caused by systemd-sysext being enabled, when you are done testing you can disable systemd-sysext (sudo systemctl disable --now systemd-sysext) It is thus no proper method for long term deployment. It makes sense to me but it definitely caught me off-guard.

pxc 3y ago
I'd never heard of systemd-sysext, as I've not really spent any time with imperative immutable distros. From the man page: > systemd-sysext activates/deactivates system extension images. System extension images may – dynamically at runtime — extend the /usr/ and /opt/ directory hierarchies with additional files. This is particularly useful on immutable system images where a /usr/ and/or /opt/ hierarchy residing on a read-only file system shall be extended temporarily at runtime without making any persistent modifications. > [...] > The primary use case for system images are immutable environments where debugging and development tools shall optionally be made available, but not included in the immutable base OS image itself (e.g. strace(1) and gdb(1) shall be an optionally installable addition in order to make debugging/development easier). System extension images should not be misunderstood as a generic software packaging framework, as no dependency scheme is available: system extensions should carry all files they need themselves, except for those already shipped in the underlying host system image. > [...] > Another use case for the system extension concept is temporarily overriding OS supplied resources with newer ones, for example to install a locally compiled development version of some low-level component over the immutable OS image without doing a full OS rebuild or modifying the nominally immutable image. [...] This case works regardless if the underlying host /usr/ is managed as immutable disk image or is a traditional package manager controlled (i.e. writable) tree. https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html https://www.freedesktop.org/software/systemd/man/latest/syst... So I guess this method is being presented to testers to give them a more controlled way to test.
yjftsjthsd-h 3y ago
That just nudges the question one step out; why does systemd-sysext make /usr and /opt read-only? AFAICT it's just some tooling over an overlay filesystem, which I'm pretty sure works with rw filesystems?
- pxc 3y ago
  Overlaying an rw filesystem can mean that some changes to the underlying rw filesystem have no effect, which many users might find to be pretty surprising behavior. Maybe it's to force users to think about what they're doing more, in case they install or update a package that the overlay overrides.

pxc 3y ago

I'd never heard of systemd-sysext, as I've not really spent any time with imperative immutable distros. From the man page: > systemd-sysext activates/deactivates system extension images. System extension images may – dynamically at runtime — extend the /usr/ and /opt/ directory hierarchies with additional files. This is particularly useful on immutable system images where a /usr/ and/or /opt/ hierarchy residing on a read-only file system shall be extended temporarily at runtime without making any persistent modifications. > [...] > The primary use case for system images are immutable environments where debugging and development tools shall optionally be made available, but not included in the immutable base OS image itself (e.g. strace(1) and gdb(1) shall be an optionally installable addition in order to make debugging/development easier). System extension images should not be misunderstood as a generic software packaging framework, as no dependency scheme is available: system extensions should carry all files they need themselves, except for those already shipped in the underlying host system image. > [...] > Another use case for the system extension concept is temporarily overriding OS supplied resources with newer ones, for example to install a locally compiled development version of some low-level component over the immutable OS image without doing a full OS rebuild or modifying the nominally immutable image. [...] This case works regardless if the underlying host /usr/ is managed as immutable disk image or is a traditional package manager controlled (i.e. writable) tree. https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html https://www.freedesktop.org/software/systemd/man/latest/syst... So I guess this method is being presented to testers to give them a more controlled way to test.

yjftsjthsd-h 3y ago

That just nudges the question one step out; why does systemd-sysext make /usr and /opt read-only? AFAICT it's just some tooling over an overlay filesystem, which I'm pretty sure works with rw filesystems?

pxc 3y ago
Overlaying an rw filesystem can mean that some changes to the underlying rw filesystem have no effect, which many users might find to be pretty surprising behavior. Maybe it's to force users to think about what they're doing more, in case they install or update a package that the overlay overrides.