/EFI partition x-systemd.automount in FSTAB

I have tried to put this option:
x-systemd.automount
for the EFI partition in the FSTAB
and it improved the boot up time, since the partition now should be mounted only when is needed, and not at boot, if I have well understood :slight_smile:
has anyone tried x-systemd.automount?
should it work?

I use it for any mount which has a chance to be offline such as a network mount or an external drive. For that purpose they work great.

Are you sure it improved boot up time? I am not sure why a systemd-automount would do that. I would have to look at the documentation to be sure but I think they still get mounted at boot. However, if they fail to mount they won’t cause startup to fail.

Also, didn’t you say in another topic you are using systemd-boot? If so, it needs that partition to boot since that is where the kernel is.

In theory, for an internal partition which isn’t constantly accessed, using a systemd-automount should be slightly slower since it has to mount the partition whenever it is accessed after the timeout occurs.

1 Like

https://wiki.archlinux.org/title/Improving_performance/Boot_process#Filesystem_mounts

here I’ve got the idea:
Other filesystems, like /home or EFI system partition, can be mounted with custom mount units. Adding noauto,x-systemd.automount to mount options will buffer all access to that partition, and will fsck and mount it on first access, reducing the number of filesystems it must fsck/mount during the boot process.

OK, if you added noauto as well, that will stop it from being mounted. However, the ESP shouldn’t be getting fsck’d anyway. So you are literally saving yourself a onetime mount in exchange for waiting for it be mounted every single time you need it.

It is one of those things where you can do it, but should you?

Also, did you test to see if you are actually making your system faster? That partition is probably getting mounted anyway since your kernel is there. You may only be saving yourself a remount operation which is very fast.

1 Like

I don’t know :slight_smile:
anyway I’ve not added noauto, just defaults,x-systemd.automount

at boot, result of systemd-analyze critical-chain:
with x-systemd.automount
graphical.target @910ms

without
graphical.target @1.310s

do not know if it’s worth it, maybe someone else has already tried

IMHO, your experience/results is a better judge than theory :stuck_out_tongue_winking_eye:
About noauto, here is what man says, and probably missed from the relevant wiki maintainers/editors :zipper_mouth_face: :

Note that if x-systemd.automount (see above) is used, neither auto nor noauto have any effect. The matching automount unit will be added as a dependency to the appropriate target.

AFAIK, each fstab entry is automatically converted to a systemd.mount unit. With any (allowable) options, you may steer it to your liking.

AFAIK, since it is mounted once, it will stay mounted, until something happens. :person_shrugging:

The next relevant flag is nofail, generally used for external drives, but using it for @ESP sounds exaggerating.

Nevertheless, what works is what is best! :slightly_smiling_face: :person_shrugging:

2 Likes

x-systemd.automount seems to work when I install a new kernel
I’ve installed the LTS kernel and the /boot partition was correctly mounted when needed

yes, I did not know, it’s very interesting for a network mount

1 Like