Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228855 > unrolled thread

Redundancy for EFI System Partition: what do people do in 2020?

Back to article view | Back to linux.debian.user

Contents

  Redundancy for EFI System Partition: what do people do in 2020? Andy Smith <andy@strugglers.net> - 2020-11-21 17:50 +0100
    Re: Redundancy for EFI System Partition: what do people do in 2020? Sven Hartge <sven@svenhartge.de> - 2020-11-21 19:30 +0100
    Re: Redundancy for EFI System Partition: what do people do in 2020? Steve McIntyre <steve@einval.com> - 2020-11-21 19:30 +0100
      Re: Redundancy for EFI System Partition: what do people do in 2020? Julian Andres Klode <jak@debian.org> - 2020-11-21 20:00 +0100
    Re: Redundancy for EFI System Partition: what do people do in 2020? David Christensen <dpchrist@holgerdanske.com> - 2020-11-21 20:20 +0100

#228855 — Redundancy for EFI System Partition: what do people do in 2020?

Hello,

More of my adventures in EFI land.

Machines that boot by EFI need an EFI System Partition. I'm used
to using software RAID everywhere and providing redundancy for
everything. It seems that the designers of EFI didn't think about
that one.

    https://www.tinkerfairy.net/efi-raid.txt
    https://www.claudiokuenzler.com/blog/696/uefi-efi-boot-does-not-like-software-raid-system-partition-grub-error-17
    https://unix.stackexchange.com/questions/265368/why-is-uefi-firmware-unable-to-access-a-software-raid-1-boot-efi-partition

So, those of you who boot by EFI and use software RAID, how do you
choose to provide redundancy for your ESP any why did you make that
choice?

I understand the main choices are:

a) Don't provide redundancy.

   There's only one ESP. If the device it's on dies you can recreate
   it with a live environment such as the rescue mode of the
   installer.

b) Put the ESP in a v1.0 mdraid level 1.

   As the RAID metadata is at the end, it appears to the firmware
   like a normal filesystem for read purposes. Updating it from
   within the OS writes to both copies as it's a RAID-1.

   Has the risk that if the firmware writes to it (which apparently
   it sometimes does), it will corrupt the RAID.

c) Manually sync the ESP to another partition which can be used if
   the first device dies.

   An identical partition can be created on the second device and an
   arrangement made to copy the real ESP to the secondary partition
   every time grub-install would be run.

   You would have to be sure that this is as automated and foolproof
   as possible, to avoid being lulled into a false sense of security
   and then have a problem at the worst time.

d) Something else?

Cheers,
Andy

[toc] | [next] | [standalone]

#228858

Andy Smith <andy@strugglers.net> wrote:

> c) Manually sync the ESP to another partition which can be used if
>    the first device dies.

>    An identical partition can be created on the second device and an
>    arrangement made to copy the real ESP to the secondary partition
>    every time grub-install would be run.

>    You would have to be sure that this is as automated and foolproof
>    as possible, to avoid being lulled into a false sense of security
>    and then have a problem at the worst time.

I choose c) for the systems here, including the syncing into our normal
package upgrade scripts, making sure that /boot/efi and /boot/efi2 are
in sync after every package update.

Code looks like this:

if [ -d /boot/efi/EFI/debian/ -a -d /boot/efi2/EFI/debian/ ]; then
 echo 'Multiple UEFI ESP found'
 if ! diff -rq /boot/efi/EFI/debian/ /boot/efi2/EFI/debian/; then
   echo 'ESP differ, need to rsync'
   rsync -rv /boot/efi/EFI/debian/ /boot/efi2/EFI/debian/
 fi
fi

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#228859

[ Adding CC to the debian-efi list too... ]

Hey Andy!

Andy Smith wrote:
>
>More of my adventures in EFI land.
>
>Machines that boot by EFI need an EFI System Partition. I'm used
>to using software RAID everywhere and providing redundancy for
>everything. It seems that the designers of EFI didn't think about
>that one.
>
>    https://www.tinkerfairy.net/efi-raid.txt
>    https://www.claudiokuenzler.com/blog/696/uefi-efi-boot-does-not-like-software-raid-system-partition-grub-error-17
>   
>https://unix.stackexchange.com/questions/265368/why-is-uefi-firmware-unable-to-access-a-software-raid-1-boot-efi-partition
>
>So, those of you who boot by EFI and use software RAID, how do you
>choose to provide redundancy for your ESP any why did you make that
>choice?
>
>I understand the main choices are:
>
>a) Don't provide redundancy.
>
>   There's only one ESP. If the device it's on dies you can recreate
>   it with a live environment such as the rescue mode of the
>   installer.

And obviously it's the only option when you're on a single-disk system
like a laptop.

>b) Put the ESP in a v1.0 mdraid level 1.
>
>   As the RAID metadata is at the end, it appears to the firmware
>   like a normal filesystem for read purposes. Updating it from
>   within the OS writes to both copies as it's a RAID-1.
>
>   Has the risk that if the firmware writes to it (which apparently
>   it sometimes does), it will corrupt the RAID.

ACK. That's my worry here. Also, currently grub-install gets upset
when you try to install to a "disk" that the underlying firmware
doesn't understand and so can't add a boot record (as I think is
mentioned in your links above). So you have to install to the
removable media fallback path too.

I've gone that way on the machine I'm typing this on for *now*. It's
on my TODO list to hack on grub-install to do something better here
(i.e. recogonise the RAID, work out which disks are involved, and then
add boot records for each) but I'm struggling with time to do that
atm. *So* many projects, so little time. :-(

>c) Manually sync the ESP to another partition which can be used if
>   the first device dies.
>
>   An identical partition can be created on the second device and an
>   arrangement made to copy the real ESP to the secondary partition
>   every time grub-install would be run.
>
>   You would have to be sure that this is as automated and foolproof
>   as possible, to avoid being lulled into a false sense of security
>   and then have a problem at the worst time.

Yup, that's the other option that might make sense. It's not
wonderful, but could likely be scripted easily enough. I've been doing
this manually (i.e. badly!) from time to time on the house server.

>d) Something else?

Another option if you're feeling keen/brave would be to write an EFI
driver for Linux SW RAID. I'd expect the EDK2 folks would be very
happy if somebody wanted to do that...

I had a conversation a few years back with some guys at one large PC
vendor who were apparently considering adding firmware support like
this. Then things went quiet and I can only assume it's not
coming from them...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

[toc] | [prev] | [next] | [standalone]

#228862

On Sat, Nov 21, 2020 at 05:44:30PM +0000, Steve McIntyre wrote:
> [ Adding CC to the debian-efi list too... ]
> 
> Hey Andy!
> 
> Andy Smith wrote:
> >
> >More of my adventures in EFI land.
> >
> >Machines that boot by EFI need an EFI System Partition. I'm used
> >to using software RAID everywhere and providing redundancy for
> >everything. It seems that the designers of EFI didn't think about
> >that one.
> >
> >    https://www.tinkerfairy.net/efi-raid.txt
> >    https://www.claudiokuenzler.com/blog/696/uefi-efi-boot-does-not-like-software-raid-system-partition-grub-error-17
> >   
> >https://unix.stackexchange.com/questions/265368/why-is-uefi-firmware-unable-to-access-a-software-raid-1-boot-efi-partition
> >
> >So, those of you who boot by EFI and use software RAID, how do you
> >choose to provide redundancy for your ESP any why did you make that
> >choice?
> >

In Ubuntu, we added support to grub for installing to multiple ESP,
using a wrapper around grub-install that does the same debconf stuff
as we do for grub-pc; called grub-multi-install.

We have not yet had time to forward this, and I'm not sure if the
solution is acceptable for Debian, but it's certainly my hope that
we can reduce this and the rest of the delta we have downstream.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

[toc] | [prev] | [next] | [standalone]

#228863

On 2020-11-21 08:40, Andy Smith wrote:

> I'm used
> to using software RAID everywhere and providing redundancy for
> everything.

> how do you
> choose to provide redundancy for your ESP any why did you make that
> choice?

I MBR and single 2.5" SSD's for system drives.


For desktops and servers, I mount them in trayless racks.  My older 
laptops have externally accessible drive bays.


I keep my system images small enough to fit onto "16 GB" devices and 
take an image once a month to protect against operator error, bad 
updates/ upgrades, malware, device failure, etc..


I use ZFS for boot and root where available (OOTB on FreeBSD, Debian 
requires too much work) and install with "copies=2" to protect against 
localized storage errors, etc..


David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web