You are not logged in.
I recently installed Arch Linux with this guide. This setup relies on automounting with systemd-gpt-auto-generator, and lacks an /etc/fstab file (which is what I want.)
During the setup I created a directory, /efi, to be the directory the ESP is mounted on, and deleted the old /boot directory. I then setup systemd-boot with
bootctl install --esp-path=/efi
and edited /etc/mkinitcpio.d/linux.preset to generate UKI's in the default directory in that configuration file, which has /efi as part of the path.
However, upon reboot I see that /efi is completely empty, and /boot has returned, and that my ESP has been mounted on /boot instead of /efi. This isn't what I want, and means that I can't run
mkinitcpio -P
without having to unmount and remount the ESP on the right directory.
I see that boot.mount and boot.automount are systemd units using systemctl, and stopping boot.automount unmounts /boot. I have to create new efi.mount and efi.automount units, enable them, and mask (as I can't disable) both boot.mount and boot.automount to get it to function the way I want.
But this leads to /efi not being accessable to other users besides root, and using chmod as root on /efi doesn't seem to actually change the permissions of the directory, and using lsattr as root also doesn't yield any results. (EDIT: this issue was resolved.)
Is there a better solution to this? I am confused as to why boot.mount and boot.automount were created in the first place. This forum post describes the opposite problem, but it made sense to me as /efi has superseded /boot as an ESP mount dir.
Last edited by speedorama (2025-05-02 12:51:36)
Offline
The second to last sentence makes not much sense to me as that will be the case already anyway? The ESP is VFAT it doesn't have file level permissions, the permissions are defined once, during mount on mounting. Generally there should be no reason why you'd want to write there with anything else other than root processes, why would you want "other" users to write there?
As to why boot and not efi were the default units for gpt-autogenerator I can't really answer as I don't use those.
Online
The second to last sentence makes not much sense to me as that will be the case already anyway? The ESP is VFAT it doesn't have file level permissions, the permissions are defined once, during mount on mounting. Generally there should be no reason why you'd want to write there with anything else other than root processes, why would you want "other" users to write there?
I understand that writing to the ESP is something that should be reserved for root processes, hence why I said "accessible," not "writable." I understand "accessible" may have some ambiguity, so I will clarify that I wasn't referring to write permissions.
What I mean is that trying to change directories to /efi or read any file on it, as any other user besides root, is denied, as in, something like this:
$ cd /efi
cd: permission denied: /efi
I know this wasn't the case for my old Arch installation, so I assumed this was not the default nor intended behavior. If I am wrong on this, then I'd be happy to edit my original post to reflect that.
EDIT: This issue was caused by mounting options in efi.mount. Please disregard it.
Last edited by speedorama (2025-05-02 12:52:02)
Offline
The EFI system partition is not mounted world readable to protect the random seed file (i.e. /loader/random-seed).
Your ESP is most likely getting mounted to /boot instead of /efi because your /boot directory is empty. Unmount everything from /boot and place something there. E.g.:
# touch /boot/.donotmounthere
Offline
Your ESP is most likely getting mounted to /boot instead of /efi because your /boot directory is empty. Unmount everything from /boot and place something there. E.g.:
# touch /boot/.donotmounthere
While this does work, it also necessitates the existence of /boot. Before this, I had no /boot directory, only an /efi directory. I'd hoped that systemd-gpt-auto-generator wouldn't require such a workaround (that, or masking the /boot mounting units). If that's as far as I can get, though, then I'll mark the thread as solved.
Offline