On 02/04/2014 09:57 AM, David Brown wrote:

On 04/02/14 09:32, Francis Moreau wrote:

quoted

On 02/02/2014 11:30 PM, Chris Murphy wrote:

quoted

On Feb 2, 2014, at 2:34 PM, Francis Moreau [off-list ref]
wrote:

quoted

That's funny because one of the reasons I want to use UEFI
firmware is to get rid of grub (I don't like it and the way it
has become such a bloated beast): since /boot is vfat and has its
own partition, I prefer use a much simpler bootloader such as
gummyboot.

It might be possible to do what you want with mdadm metadata
version 1.0. Typically bootable raid1 is ext4 on md raid1 using
metadata format 1.0, and an internal bitmap. When the partitions
are not assembled, they each appear as separate ext4 partitions. If
FAT32 on md raid1 with metadata 1.0 still looks like FAT32 as a
separate partition, and the mdadm v1.0 metadata at the end of the
partition doesn't confuse the firmware, what should happen is any
ESP can boot the system. Once the kernel and initramfs are loaded,
mdadm will locate the mdadm metadata on each partition and assemble
them into a single md device, and fstab mounts the md device at
/boot. So prior to boot they are separate ESPs, and after boot it's
a single ESP (mirrored). But I haven't tested this arrangement with
ESPs and UEFI.

I'll test this configuration and see if it works soon.

quoted

The easiest scenario I've found for resilient boot on EFI systems
is, well, not easy. First, I put shim and grub package files onto
each ESP along with the previously posted grub.cfg snippet. Those
grub.cfgs are one time, non-updatable files, that point to
/boot/grub2/grub.cfg (produced with grub2-mkconfig on Fedora) on
Btrfs raid1. That's about as reliable as it gets because the only
dependencies are grub (which understands Btrfs multiple devices)
and dracut baking the btrfs module into initramfs. It gets
essentially fool proof if btrfs is compiled into the kernel. Other
combinations are easier to break. I basically want ESPs that aren't
being modified if at all avoidable because FAT32 breaks easily if
anything is being written to it and there is a crash or power
failure.

I agree that FAT32 can break during power failure, that's the reason
why I'm trying to make it mirrored. But I want to get rid of grub as
much as possible so I would prefer to use the first solution.

Mirroring will not help FAT32 during power failure - you have a good
chance of getting two copies of the same error.  And if your power fail
hits during writes, you also have a good chance of the two disks having
/different/ errors and inconsistencies.  The problem lies in FAT32
having no log, and no barriers or ordering when it makes changes -
updates to the file data, the directory structure, and the FAT table can
happen in different orders, and a power failure can leave one part
updated and the other part with old data.  Raid cannot help with this
problem.

Ok, so basically RAID helps only in case of disk failure, right ?

It seems odd to have chosen FAT32 in the first place then.

The most important way to protect your FAT32 system is simply to avoid
writing to it except when absolutely necessary.  If it is mounted
read-only, and only updated when changing grub or updating the kernel,
then just make sure you don't power-cycle your machine at that time.

Well, the problem is that you never know when power failures happen at
least for me with a small server without any power backup.

The smaller the critical window, the smaller the chances of problems.

If you need to do updates more regularly, then your best bet is to have
independent FAT32 partitions on the two disks.  Make your updates on one
disk, and when it is finished copy the changes onto the other disk.
Then you always have a good copy - if you get a crash while the first
disk is being updated, then when you re-start the computer, use its boot
menu to choose booting from the second disk.

That seems the best thing to do then.

Thanks.