Hacker News Reader

Comment by shortformblog | Hacker News Reader

A warning for anyone who tests the Cosmic Desktop on their distro: It’s possible (if very much in a pre-alpha state), but it makes your file system read-only, which can be a bit of a surprise if you’re not aware it’s coming.

It’s easily reversible, fortunately, but it really threw me for a loop when I wasn’t able to update my Tumbleweed packages. Heh.

View on HN

This is not true, and I do not know what gave you that impression. What you're describing is a side effect of using systemd-sysext, but I do not know why you would be using that.

o.0 how is that the business of a desktop environment?

Here’s the part that explains it from the GitHub page (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.

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/syst...

So I guess this method is being presented to testers to give them a more controlled way to test.

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?

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.

Reply on news.ycombinator.com