[systemd-devel] bootctl: default mount point for the ESP partition.

Mantas Mikulėnas grawity at gmail.com
Tue Sep 1 10:22:36 PDT 2015


On Tue, Sep 1, 2015 at 7:47 PM, Simon McVittie <
simon.mcvittie at 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 <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150901/f2018233/attachment-0001.html>


More information about the systemd-devel mailing list