<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 1, 2015 at 7:47 PM, Simon McVittie <span dir="ltr"><<a href="mailto:simon.mcvittie@collabora.co.uk" target="_blank">simon.mcvittie@collabora.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/09/15 17:21, Goffredo Baroncelli wrote:<br>
> I discovered that bootctl assume as default mount point for the ESP<br>
> partition the /boot directory. Instead it seems to me that the most part<br>
> of distributions prefers /boot/efi.<br>
<br>
For some context, the reasoning for /boot/efi is:<br>
<br>
In some distributions (presumably including the (Fedora-based?) ones<br>
where this feature was developed), /boot is traditionally treated as<br>
mutable and unpackaged, like /var; so the packages include the kernel in<br>
/usr or /lib or something, and copy it into /boot. The cost of this is<br>
one extra copy of the kernel on-disk, which used to be a significant<br>
amount of space, although on modern disks it doesn't really matter.<br>
<br>
In other distributions (like Debian and its derivatives), the OS<br>
packages for kernels traditionally include /boot/vmlinux-whatever and<br>
/boot/config-whatever as packaged files; the corresponding initramfs is<br>
generated at install time and placed alongside them. In these<br>
distributions, there is no second copy of the kernel in /usr or /lib.<br>
This saves some space, although, again, the amount of space saved is<br>
negligible on current hardware.<br>
<br>
On BIOS systems, either way was fine, because /boot was either part of<br>
the root filesystem, or a separate small ext2 partition near the<br>
beginning of the drive (to work around BIOS disk-addressability<br>
limitations) for use by lilo or grub or whatever. Similarly, on non-x86,<br>
the bootloader would traditionally either load the kernel from a<br>
non-filesystem like a raw flash partition, or from the root filesystem<br>
or a separate /boot partition; either would be fine.<br>
<br>
However, it starts to matter with the move to EFI (on x86 and<br>
elsewhere), or on non-EFI systems where the bootloader also reads a FAT<br>
partition (such as the Raspberry Pi). If the OS packages for kernels<br>
include files in /boot, then having a non-Unix filesystem for /boot<br>
becomes a problem, because the package manager (e.g. dpkg) can't use the<br>
same hardlink-based atomic-overwrite that it would use for robustness on<br>
a proper Unix filesystem. The ESP is FAT, which is not a full Unix<br>
filesystem, so you can't do that sort of thing. That's why Debian and<br>
its derivatives mount the ESP at /boot/efi instead of /boot, and why<br>
<<a href="http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/" rel="noreferrer" target="_blank">http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/</a>> mounts the<br>
ESP-equivalent at /boot/firmware.<br>
<br>
AIUI, /boot/efi also makes it a bit easier to have the ESP remain<br>
unmounted or read-only when not in active use, which is good for its own<br>
robustness; a system crash corrupting an unmounted partition is less<br>
likely than corrupting a mounted filesystem.<br></blockquote><div><br></div><div>Though, why would a partition get corrupted, if it wasn't being written to /during/ the crash?...</div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>></div></div>
</div></div>