On 02/04/2014 09:57 AM, David Brown wrote: > On 04/02/14 09:32, Francis Moreau wrote: >> On 02/02/2014 11:30 PM, Chris Murphy wrote: >>> >>> On Feb 2, 2014, at 2:34 PM, Francis Moreau <francis.moro@xxxxxxxxx> >>> wrote: >>>> >>>> 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. >> >>> >>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
