Best practice for fresh install on UEFI with multiple disks?

[Boyan Penkov]

Hello folks,

New machine, new opportunity to get up to speed with the contemporary
best practices for multiple disks on UEFI.

The behavior I'd like -- and, I suspect, the behavior we'd all like --
is the machine stays bootable and data is preserved if any disk fails.
Specifically, what I'd like to do if a disk fails (or starts warning
me of possible failure) is shut the machine down at my convenience,
replace the disk, have it re-boot, and re-populate the new disk with
data in the background.

For data, BTRFS works well for my use case, has for some time, and has
been tested on disks dying in the last few years. However, this is
the first time I have a chance to deal with this for /boot on EFI
partitions, which can't be put on BTRFS.

So, what are folks doing these days to mirror /efi and /boot?
Googling shows that Ubuntu can boot off RAID directly here, but Debian
cant quite yet without manually rsync'ing directories.

Anybody have a firm solution here?

Cheers!

[Andy Smith]

Hi,

Post by Boyan Penkov
So, what are folks doing these days to mirror /efi and /boot?

[ TL;DR: You already found it - have two separate EFI System
Partitions, sync one to the other manually using e.g. rsync
whenever one changes, add paths to both in your UEFI firmware. ]

I don't think the answer, on Debian, has changed since I asked the
same question in 2020:

https://lists.debian.org/debian-user/2020/11/msg00455.html

[Florent Rougon]

Hi,

Post by Andy Smith
I don't think the answer, on Debian, has changed since I asked the
https://lists.debian.org/debian-user/2020/11/msg00455.html

There is a script at [1] to install as, e.g.,
/etc/grub.d/90_copy_to_boot_efi2, so that it is automatically run every
time grub updates its configuration file. I believe the script is fine,
except I would do

mount /boot/efi2

rather than

mount /boot/efi2 || :

Maybe the intent is for the script not to return a non-zero exit status
when /boot/efi2 can't be mounted, however in this case I certainly don't
want the rsync command to be run.

Regards

[1] https://wiki.debian.org/UEFI#RAID_for_the_EFI_System_Partition

[Tim Woodall]

Post by Florent Rougon
Hi,

Post by Andy Smith
I don't think the answer, on Debian, has changed since I asked the
https://lists.debian.org/debian-user/2020/11/msg00455.html

There is a script at [1] to install as, e.g.,
/etc/grub.d/90_copy_to_boot_efi2, so that it is automatically run every
time grub updates its configuration file. I believe the script is fine,
except I would do
mount /boot/efi2
rather than
Maybe the intent is for the script not to return a non-zero exit status
when /boot/efi2 can't be mounted, however in this case I certainly don't
want the rsync command to be run.

Haven't looked at the script but assuming it's run set -e, then your
suggestion will fail if it's already mounted.

Best would be to check that, and unmount again only if the script
mounted.

Tim.

[Florent Rougon]

Post by Tim Woodall
Haven't looked at the script but assuming it's run set -e, then your
suggestion will fail if it's already mounted.

Why?

[Tim Woodall]

Post by Tim Woodall
Haven't looked at the script but assuming it's run set -e, then your
suggestion will fail if it's already mounted.

Why?

Because the script will abort after the mount fails.

***@dirac:~# cat test.sh
#!/bin/bash

set -e

mount /boot/efi2

echo "do important stuff"

***@dirac:~# ./test.sh
mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
dmesg(1) may have more information after failed mount system call.


Note that do important stuff is never reached.

[Florent Rougon]

Post by Tim Woodall
Because the script will abort after the mount fails.
#!/bin/bash
set -e
mount /boot/efi2
echo "do important stuff"
mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
dmesg(1) may have more information after failed mount system call.
Note that do important stuff is never reached.

That's interesting because my system doesn't behave the same. I had of
course checked, before writing my first message, that 'mount /boot/efi2'
returns exit status 0 even when /boot/efi2 is already mounted. With your
script (called foo.sh here), here is what I get:

# mount | grep efi2
/dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
# /tmp/foo.sh
do important stuff
# mount | grep efi2
/dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
#

Every invocation adds a new, duplicate entry in the output of 'mount'.

This is Debian sid amd64; /usr/bin/mount is from 'mount' package version
2.40.2-8.

Regards

[Tim Woodall]

Post by Florent Rougon

Post by Tim Woodall
Because the script will abort after the mount fails.
#!/bin/bash
set -e
mount /boot/efi2
echo "do important stuff"
mount: /boot/efi2: /dev/sda2 already mounted on /boot/efi2.
dmesg(1) may have more information after failed mount system call.
Note that do important stuff is never reached.

That's interesting because my system doesn't behave the same. I had of
course checked, before writing my first message, that 'mount /boot/efi2'
returns exit status 0 even when /boot/efi2 is already mounted. With your
# mount | grep efi2
/dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
# /tmp/foo.sh
do important stuff
# mount | grep efi2
/dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/sda1 on /boot/efi2 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
#
Every invocation adds a new, duplicate entry in the output of 'mount'.
This is Debian sid amd64; /usr/bin/mount is from 'mount' package version
2.40.2-8.

That's very interesting and looks like it's probably a kernel change.

Tim.