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

feat:[close #159] Systemd mount units #158

Merged
merged 1 commit into from
Dec 13, 2023

Conversation

taukakao
Copy link
Member

@taukakao taukakao commented Dec 9, 2023

Using systemd mount units instead of a mount script together with a systemd service has a couple of benefits:

  • slightly faster boot since some mounts can be run in parallel
  • it's a more standard way of doing things
  • it's easier to manage more complex dependencies between mount points

The dependency between mounts with this implementation looks like this:
systemd_diagram

The reason we can't do this all in fstab is because you can't easily tell systemd to mount for example /home from /var/home after /var is mounted.

The question is: If we already use systemd mount units, it might be cleaner to put everything into mount units and not just the bind and overlay mounts. (The behavior would be identical since systemd just generates the mount units anyway from fstab)

Additionally, currently, the system will still try to boot even if a mount point fails, should this be changed so that systemd has to boot into recovery if a mount fails?

Also, if you want to test this, you can currently use this build: https://github.com/taukakao/ABRoot/releases/tag/systemdmount

Things that still need to be done:

  • decide if we should move everything from fstab to mount units (no, not worth it)
  • decide if the boot should fail on one failed mount point (no, the system can display an error in the future if it failed)
  • remove workflow changes
  • rebase and squash
  • also reflect these changes in the installer

@taukakao taukakao requested a review from matbme December 9, 2023 22:30
@matbme
Copy link
Member

matbme commented Dec 11, 2023

decide if the boot should fail on one failed mount point

In the future, we can create an "error" user that gets overwritten by the /etc mount. If the mount fails and the user still exists, we can have a custom shell showing an error.

core/system.go Outdated Show resolved Hide resolved
@mirkobrombin mirkobrombin changed the title Systemd mount units feat:[close #159] Systemd mount units Dec 11, 2023
@mirkobrombin
Copy link
Member

Ping #159 (for tracking purposes)

@matbme
Copy link
Member

matbme commented Dec 11, 2023

Implementation looks good to me, but it will also require a change in vanilla-installer to use Systemd mount units. I'll work on that as soon as I can and we can then merge both PRs at the same time

@mirkobrombin
Copy link
Member

Implementation looks good to me, but it will also require a change in vanilla-installer to use Systemd mount units. I'll work on that as soon as I can and we can then merge both PRs at the same time

Can you make an issue for that which locks this?

@taukakao
Copy link
Member Author

In the future, we can create an "error" user

That sounds like a good idea 👍

I'll work on that as soon as I can

I can probably also do the installer part. I only wanted to wait if this is even wanted, which it seems to be.

@taukakao taukakao force-pushed the systemd-mount-units branch from d4eeb5f to 77be31a Compare December 11, 2023 17:09
@taukakao taukakao marked this pull request as ready for review December 11, 2023 17:10
This is cleaner than using a mount script and running this as a service.
@taukakao
Copy link
Member Author

This is now ready together with Vanilla-OS/vanilla-installer#311

@matbme matbme merged commit 891f94a into Vanilla-OS:main Dec 13, 2023
2 checks passed
@taukakao taukakao deleted the systemd-mount-units branch April 13, 2024 02:43
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.

4 participants