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