[systemd-devel] How to factory reset?

[Chris Murphy]

On Wed, Mar 11, 2015 at 1:56 PM, Kay Sievers <kay at vrfy.org> wrote:

> Systemd by default mounts it with autofs, it will not be mounted until
> it is accessed, which does not happen during normal operation. We
> currently miss autofs timeout handling, which would umount /boot again
> when it is no longer used. That would make stuff pretty robust, I
> expect.
> It's just that distros have their rather broken concept of putting it
> into fstab, and even cascading mounts with splitting /boot and the
> ESP.

That's an improvement, sure.

But the very idea of ESPs that need any post-install modification in
the first place is what introduces this fragility in the first place.
Windows never makes ESP modifications post-install, and OS X only does
it to stage firmware update payloads.

The paradigm that wants to place things often being changed: kernel,
initramfs, bootloader scripts, is what causes the need to sync
multiple ESPs in the first place. And proprietary raid is not a
general purpose way of getting around this.

A more general purpose solution for UEFI would be EFI drivers for
various filesystems including md, LVM, and Btrfs, so that there's
quasi-native firmware support for them. And then there's no reason to
ever touch the ESP again nor depend on firmware raid to effectively
replicate the kernel and initramfs.

>
>> The FAT kernel maintainer says it's a bad idea, pretty much any crash
>> or panic while the ESP is mounted, even ro, can cause FAT corruption
>> and there's nothing to be done about it (well, fsck it at every boot
>> might help some, which also some distros don't ever do).
>
> Right, the Linux FAT driver, or maybe just the way Linux handles the
> writeback to disk, is absolutely fragile. Corrupted FAT file systems
> are the norm and not the exception. We must mount it unconditionally,
> it will just break after a while.

Apple and Microsoft essentially trust it zero, and don't persistently
mount it. So I don't know the cause but I filed a bug a while ago and
it's basically expected behavior.
https://bugzilla.kernel.org/show_bug.cgi?id=92721


-- 
Chris Murphy