Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remount: Drop support for auto-tmpfs-on-var; use systemd.volatile=state #856

Closed
wants to merge 1 commit into from

Conversation

cgwalters
Copy link
Member

In current systemd, there is:
systemd-volatile-root
which was introduced by this commit.

I'd like to make further changes to how we handle /var, and I don't
want to reason about the interaction of our "tmpfs var" with too many
other things.

The comment about having "all /var handling in one place" was always inaccurate
given that we rely on systemd for mounting. And in general, I don't want to
duplicate too many things systemd does - it does them well, documents them, etc.

As far as I know, it was basically just Owen who was using this for the GNOME
hardware testing effort, and I'm sure he could easily switch over to
systemd.volatile=state.

In current systemd, there is:
[systemd-volatile-root](https://www.freedesktop.org/software/systemd/man/systemd-volatile-root.service.html)
which was introduced by [this commit](systemd/systemd@91214a3).

I'd like to make further changes to how we handle `/var`, and I don't
want to reason about the interaction of our "tmpfs var" with too many
other things.

The comment about having "all /var handling in one place" was always inaccurate
given that we rely on systemd for mounting. And in general, I don't want to
duplicate too many things systemd does - it does them well, documents them, etc.

As far as I know, it was basically just Owen who was using this for the GNOME
hardware testing effort, and I'm sure he could easily switch over to
`systemd.volatile=state`.
@cgwalters
Copy link
Member Author

I pinged @owtaylor for review.

@owtaylor
Copy link
Contributor

It certainly looks like systemd.volatile=state would have the same effect. It's hard for me to remember enough about what I was doing to be sure that systemd.volatile=state, but since it's not a current usage, that certainly shouldn't block anything! As far as I'm concerned you can go ahead.

(of course, someone else could be implicitly relying on this - without realizing it - so it's not something I'd push to a stable release without letting people have time to test.)

@cgwalters
Copy link
Member Author

@rh-atomic-bot delegate=owtaylor

Yeah, someone could be using it - but if they are, it's not like they're going to do an OS update and suddenly things break, because the model is inherently not using inplace updates. They're going to be generating new images and booting those, and finding out things are broken. Hopefully they'll come here.

For Fedora Atomic Host we did have a project at one point to do a "PXE to live" variant which would make use of this potentially, but it isn't active right now since our primary use cases are stateful-ish systems.

So my plan indeed is to get this in the next release, and if someone complains and for some reason has an ancient systemd we can revisit.

@rh-atomic-bot
Copy link

✌️ @owtaylor can now approve this pull request

@owtaylor
Copy link
Contributor

Sounds good.

@cgwalters
Copy link
Member Author

@owtaylor
Copy link
Contributor

@rh-atomic-bot r+

@rh-atomic-bot
Copy link

📌 Commit c127838 has been approved by owtaylor

@cgwalters
Copy link
Member Author

@rh-atomic-bot retry

@cgwalters
Copy link
Member Author

@rh-atomic-bot r=owtaylor c127838

@rh-atomic-bot
Copy link

⌛ Testing commit c127838 with merge 05d0ee5...

@rh-atomic-bot
Copy link

☀️ Test successful - status-atomicjenkins
Approved by: owtaylor
Pushing 05d0ee5 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants