↩ 021. Natively mirrored but still functional & correct /boot/efi ↩

Mon, 15 Dec 2025 00:02:14 +0100

Recently, a friend shared with me the following observation of a novel system (compacted for NutriScore KPIs):

[root@localhost ~]# lsblk
NAME      MAJ:MIN   SIZE TYPE  MOUNTPOINT
sda         8:0   447.1G disk
└─sda3      8:3   414.1G part
  └─md125   9:125  1024M raid1 /boot/efi
sdb         8:16  447.1G disk
└─sdb3      8:17  414.1G part
  └─md125   9:125  1024M raid1 /boot/efi

Yowza! but how? Must the ESP not be a vfat with the ESP parttype? This is obviously better than SOP of "rsync job copying between replicas of the ESP" (or "don't replicate the ESP at all"). Is there a special RAID1 mode that does a transparent replica? or does the firmware have drivers for this? The following epistemic elucidates:

[root@localhost ~]# fdisk -l /dev/sd?
WARNING: fdisk GPT support is currently new, and therefore in a

Disk /dev/sda: 480.1 GiB, 480103981056 bytes, 937703088 sectors
Disklabel type: gpt
#         Start          End  Size  Type              Name
 3    935604224    937701375    1G  Linux RAID

Disk /dev/sdb: 480.1 GiB, 480103981056 bytes, 937703088 sectors
#         Start          End  Size  Type              Name
 3    935604224    937701375    1G  Linux RAID

No ESP tag… does this system boot via EFI at all? And how the hell is GPT support new?

[root@localhost ~]# efibootmgr -v
Boot0007* CentOS        HD(3,GPT)/File(\EFI\Centos\shimx64.efi)..BO
Boot0008* CentOS        HD(3,GPT)/File(\EFI\Centos\shimx64.efi)..BO
[root@localhost ~]# file -s /dev/sd?3
/dev/sda3: x86 boot sector, mkdosfs boot message display, code offset 0x58, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors 2097024 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 2044, serial number 0x05e6429e, label: " "
/dev/sda3: x86 boot sector, mkdosfs boot message display, code offset 0x58, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors 2097024 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 2044, serial number 0x05e6429e, label: " "

Yes, and it is in fact Just a vfat. And it is in fact the very same vfat so our eyes do not deceive us…

[14:44] Cicada:

ooooh ok I got it

[14:44] Cicada:

centos is using mdadm with metadata version 1.0 (at the end of the partition)

[14:52] nabijaczleweli:

i will be describing this technique and! making millions

# Immortal technique

With a GPT partlabel, per UEFI Forum, Inc., Unified Extensible Firmware Interface (UEFI) Specification, Release 2.11, Nov 21, 2024, 13. Protocols – Media Access, 13.3. File System Format, 13.3.2. Partition Discovery (p. 464) ,

UEFI does not impose a restriction on the number or location of System Partitions[, which] are discovered […] by examining the partition GUID and verifying that the contents of the partition conform to the FAT file system […]. Further, UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes […].

so this is all rather above board, so long as we get a partition with a FAT in it. Which this clearly does, and any space at the end of the partition with the FAT is free game.

We additionally observe that the size of the ESP is considered negligible, and that the contents of the ESP are a simple function of the rootfs, so the replicas are convenience copies for booting a system in soft-degraded conditions, and have no bearing on the redundancy of the rootfs. For the performance characteristics we can consider the ESP write-only and write-never.

Modern Linux provides two and a half layers of abstraction related to doing this (much of (the basis for) this information is stored in the zeitgeist; this also serves to reify it):

• device-mapper, which is the kernel API; when ZFS is not available and I used the other abstraction layers for redundancy, I'd never had to use dmsetup(8) – low level logical volume management; the ontology is likewise masked,
• LVM2, which seems to be the only recommended public-facing RAID &c. toolchain and which defines a Volume Group/Physical Device/Logical Volume ontology; being co-located with device-mapper implies to me that it is indeed the printf(3) to device-mapper's write(2),
• an LVM1 had supposedly existed at some point (it's mentioned by name in bookworm lvm2 (2.03.16-2)'s lvm(8)), but has since stopped previously existing (trixie lvm2 (2.03.31-2)'s lvm(8) no longer mentions it, and rebrands from LVM2 tools to LVM tools); LVM2 was first uploaded to Debian on 2002-02-20, and LVM1 (src:lvm10) was removed on 2006-10-22 after already severely bitrotting because

  lvm10 doesn't work with 2.6 kernels and is unsupported upstream.
  […]
  lvm2 works with 2.4 kernels, and is compatible with lvm10 metadata formats. and (importantly) is well supported upstream

  but already in 2001 people variably called it lvm and lvm10 to a contemporaneously confusing extent, and
• "MD", which the kernel documentation calls "MD" or "MD RAID" everywhere except its dedicated page where it calls it "RAID Arrays". because of how ass the name is I've seen many users metonymise this to mdadm(8), which already hedges when it self-describes as manage MD devices aka Linux Software RAID. I'm not sure what the M or the D are actually supposed to be. this is something you advertise usually. but not here! the first time Documentation/md.txt appeared was in Linux 2.1.85 (1998-02-04) (to expound on "lilo and loadlin options"(!) for booting off MD):

  Tools that manage md devices can be found at sweet-smoke.ufr-info-p7.ibp.fr in public/Linux/md035.tar.gz.

  Marc ZYNGIER <zyngier@ufr-info-p7.ibp.fr>

  ---

  You can boot (if you selected boot support in the configuration) with your md device with the following kernel command line:

  and looking at include/linux/md.h from the time shows

  md.h : Multiple Devices driver for Linux

  Multiple fucking Devices. no wonder! also it's metadisk sometimes;
  This is a kernel API that provides more device-mapper-style functionality. You used to use mdadm(8) directly but this is passé and cringe now and you're supposed to be using LVM2, which still uses this same driver but differently (via dm-raid(?)) and that's okay. I think it's because the original MD design was ass to autodetect and LVM2 solves this?

Out of a few greps through kernel Documentation/, only searching through admin-guide/device-mapper/ for "mirror" yielded two useful results:

• dm-raid in raid1 (RAID1 mirroring) mode and
• dm-mirror which is only mentioned indirectly and doesn't have its own file.

The sampled system above uses un-device-mapper-wrapped MD raid1 (thus, /dev/md??? and "Linux RAID").

For the purposes of this exercise, we will consider disks /dev/sd[abc] configured thusly:

# fdisk -l /dev/sda
Disk /dev/sda: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Disklabel type: gpt

Device      Start       End   Sectors Size Type
/dev/sda1    2048   2099199   2097152   1G EFI System
/dev/sda2 2099200 209713151 207613952  99G Linux LVM

With contents of whatever was previously in /boot/efi in ~/oldbootefi. This configuration can be easily obtained in the debian-installer partitioner.

# dmsetup

Making mirrors is undocumented. Notoriously undocumented, in fact. I don't even know how the Gentoo Wiki authors reverse-engineered the format because to me drivers/md/dm-{raid1,log}.c don't look like they have a parser at all. (Yes, the mirror provider is in dm-raid1.c.) However, I replicate Gentoo Wiki's analysis of the table format. So, after substituting our config:

start length

0 2097152 mirror

in-memory write log 1 argument 1k

core 1 2

3 devices

3

device offset d o d o

/dev/sda1 0 /dev/sdb1 0 /dev/sdc1 0

1 feature

1 handle_errors

root@tarta:~# dmsetup create -v $(uname -n)-ESP --table '0 2097152 mirror  core 1 2  3  /dev/sda1 0  /dev/sdb1 0  /dev/sdc1 0  1 handle_errors'
root@tarta:~# dmsetup ls --tree
tarta--LVM-tarta--root (253:0)
tarta-ESP (253:1)
 ├─ (8:33)
 ├─ (8:17)
 └─ (8:1)
root@tarta:~# dmsetup table
tarta--LVM-tarta--root: …
tarta-ESP: 0 2097152 mirror core 1 2 3 8:1 0 8:17 0 8:33 0 1 handle_errors
root@tarta:~# lsblk
NAME                       MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                          8:0    0  100G  0 disk
├─sda1                       8:1    0    1G  0 part
│ └─tarta-ESP                8:1    0    1G  0 dm
└─sda2                       8:2    0   99G  0 part
  └─tarta--LVM-tarta--root   8:0    0  248G  0 lvm  /
sdb                          8:16   0  100G  0 disk
├─sdb1                       8:17   0    1G  0 part
│ └─tarta-ESP                8:1    0    1G  0 dm
└─sdb2                       8:18   0   99G  0 part
  └─tarta--LVM-tarta--root   8:0    0  248G  0 lvm  /
sdc                          8:32   0  100G  0 disk
├─sdc1                       8:33   0    1G  0 part
│ └─tarta-ESP                8:1    0    1G  0 dm
└─sdc2                       8:34   0   99G  0 part
  └─tarta--LVM-tarta--root   8:0    0  248G  0 lvm  /
root@tarta:~# wc -c /dev/sd?1 /dev/mapper/tarta-ESP
1073741824 /dev/sda1
1073741824 /dev/sdb1
1073741824 /dev/sdc1
1073741824 /dev/mapper/tarta-ESP
root@tarta:~# file -sL /dev/sd?1 /dev/mapper/tarta-ESP
/dev/sda1:             DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 16, hidden sectors 2048, sectors 2097144 (volumes > 32 MB), FAT (32 bit), sectors/FAT 2048, serial number 0xfe3a9157, unlabeled
/dev/sdb1:             [the same]
/dev/sdc1:             [the same]
/dev/mapper/tarta-ESP: [the same]

Of note here:

• device-mapper is accounted in 512-byte blocks, even if the device's block size were 4k.
• I do not reproduce the Gentoo Wiki's minimum write log size (it says the minimum is the page size — $(( $(getconf PAGE_SIZE) / 512 )) — but the only restrixion is power of two that isn't 1; this was changed in 2009 from "multiple of the page size") we pick the minimum value since the ESP is write-never.
• If /dev/sda1 already had an ESP, it'll get synced to the others (the first device is canonical on sync).
• The mirror is the same size as the mirrored partitions. There is no metadata anywhere so this is ephemeral. This is interesting and informative for future (and the most annoying way to spell tee < /dev/sda1 > /dev/sdb1 /dev/sdc1 known to man), but not persistent and thus not useful.

# mdadm

Per mdadm(8):

Currently, Linux supports […] RAID0 (striping), RAID1 (mirroring), RAID4, […].

-e, --metadata=
Declare the style of RAID metadata (superblock) to be used. The default is 1.2 […].

Options are:

0, 0.90
[…] This format limits arrays to 28 component devices […]. It is also possible for there to be confusion about whether the superblock applies to a whole device or just the last partition, if that partition starts on a 64K boundary.

1, 1.0, 1.1, 1.2 default
[…] This has fewer restrictions. […] [A] recovery operation can be checkpointed and restarted. The different sub-versions store the superblock at different locations on the device, either at the end (for 1.0), at the start (for 1.1) or 4K from the start (for 1.2). "1" is equivalent to "1.2" […].

[…]

so..:

root@tarta:~# dmsetup remove tarta-ESP
root@tarta:~# mdadm -C tarta-ESP -l mirror -e 0 -n 3 /dev/sd?1
To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? y
mdadm: partition table exists on /dev/sda1
mdadm: partition table exists on /dev/sdb1
mdadm: partition table exists on /dev/sdc1
Continue creating array [y/N]? y
mdadm: array /dev/md/tarta-ESP started.
root@tarta:~# dmsetup ls
tarta--LVM-tarta--root  (253:0)
root@tarta:~# date > /dev/md/tarta-ESP
root@tarta:~# cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sdc1[2] sdb1[1] sda1[0]
      1048512 blocks [3/3] [UUU]
      bitmap: 1/1 pages [4KB], 65536KB chunk

unused devices: <none>
root@tarta:~# mdadm --misc -Q /dev/md/tarta-ESP
/dev/md/tarta-ESP: 1023.94MiB raid1 3 devices, 0 spares. Use mdadm --detail for more detail.
root@tarta:~# mdadm --misc -D /dev/md/tarta-ESP
/dev/md/tarta-ESP:
           Version : 0.90
     Creation Time : Sun Dec 14 04:32:43 2025
        Raid Level : raid1
        Array Size : 1048512 (1023.94 MiB 1073.68 MB)
     Used Dev Size : 1048512 (1023.94 MiB 1073.68 MB)
      Raid Devices : 3
     Total Devices : 3
   Preferred Minor : 127
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sun Dec 14 04:36:46 2025
             State : clean
    Active Devices : 3
   Working Devices : 3
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              UUID : 79536706:4f3379fa:da3b0b36:bb6ba96d (local to host tarta)
            Events : 0.20

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       33        2      active sync   /dev/sdc1
root@tarta:~# head -n1 /dev/sd?1 /dev/md/tarta-ESP | paste - - -
==> /dev/sda1 <==       Sun Dec 14 04:36:46 CET 2025
==> /dev/sdb1 <==       Sun Dec 14 04:36:46 CET 2025
==> /dev/sdc1 <==       Sun Dec 14 04:36:46 CET 2025
==> /dev/md/tarta-ESP <==       Sun Dec 14 04:36:46 CET 2025
root@tarta:~# wc -c /dev/sd?1 /dev/md/tarta-ESP
1073741824 /dev/sda1
1073741824 /dev/sdb1
1073741824 /dev/sdc1
1073676288 /dev/md/tarta-ESP

The date ends up at the front of the partitions, the device is 64k shorter…

root@tarta:~# od -Ax -tx1z -j 1073676288 /dev/sda1
3fff0000 fc 4e 2b a9 00 00 00 00 5a 00 00 00 00 00 00 00  >.N+.....Z.......<
3fff0010 00 00 00 00 73 3b bc 1c c9 31 3e 69 01 00 00 00  >....s;...1>i....<
3fff0020 c0 ff 0f 00 03 00 00 00 03 00 00 00 7f 00 00 00  >................<
3fff0030 00 00 00 00 88 6a 56 bb 36 0b 3b da 6d a9 6b bb  >.....jV.6.;.m.k.<
3fff0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
[...]
*
3fff1000 62 69 74 6d 04 00 00 00 73 3b bc 1c 88 6a 56 bb  >bitm....s;...jV.<
3fff1010 36 0b 3b da 6d a9 6b bb 14 00 00 00 00 00 00 00  >6.;.m.k.........<
3fff1020 01 00 00 00 00 00 00 00 80 ff 1f 00 00 00 00 00  >................<
3fff1030 00 00 00 00 00 00 00 04 05 00 00 00 00 00 00 00  >................<
3fff1040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
3fff1100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  >................<
*
40000000

and it says bitm and we enabled the bitmap. That's kino. (Though I'll admit it's unclear to me how you indent writes to an unstructured binary file; but I can't even clown on them because I apparently fixed this half a year ago then forgot instantly.) We do want the bitmap because the counterfactual means re-replicating the whole device when importing a dirty array, and it has no cost that I've measured (maybe it'd eat another block if the device exceeded the bitmap capacity in the superblock?).

The original assessment is correct, then: version 0 metadata does go at the end. But, version 0 stinky version 1 good: number bigger? Sure, but it doesn't really change anything I could measure;

root@tarta:~# mdadm --stop /dev/md/tarta-ESP
mdadm: stopped /dev/md/tarta-ESP
root@tarta:~# mdadm -v -C tarta-ESP -l mirror -n 3 -e 1.0 /dev/sd?1
To optimalize recovery speed, it is recommended to enable write-indent bitmap, do you want to enable it now? [y/N]? y
mdadm: size set to 1048512K
mdadm: array /dev/md/tarta-ESP started.
root@tarta:~# cp /dev/zero /dev/md/tarta-ESP
cp: error writing '/dev/md/tarta-ESP': No space left on device
root@tarta:~# cat /proc/mdstat
md127 : active raid1 sdc1[2] sdb1[1] sda1[0]
      1048512 blocks super 1.0 [3/3] [UUU]
      bitmap: 1/1 pages [4KB], 65536KB chunk
root@tarta:~# mdadm --misc -Q /dev/md/tarta-ESP
/dev/md/tarta-ESP: 1023.94MiB raid1 3 devices, 0 spares. Use mdadm --detail for more detail.
root@tarta:~# mdadm --misc -D /dev/md/tarta-ESP
[the same except]
           Version : 1.0
root@tarta:~# od -Ax -tx1z -j 1073676288 /dev/sda1
3fffc000 62 69 74 6d 04 00 00 00 33 8c 1d 3b 0a 44 dc db  >bitm....3..;.D..<
3fffc010 1b a6 81 e0 ea 93 6d 88 12 00 00 00 00 00 00 00  >......m.........<
3fffc020 00 00 00 00 00 00 00 00 80 ff 1f 00 00 00 00 00  >................<
3fffc030 00 00 00 00 00 00 00 04 05 00 00 00 00 00 00 00  >................<
3fffc040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
[...]
*
3fffe000 fc 4e 2b a9 01 00 00 00 01 00 00 00 00 00 00 00  >.N+.............<
3fffe010 33 8c 1d 3b 0a 44 dc db 1b a6 81 e0 ea 93 6d 88  >3..;.D........m.<
3fffe020 74 61 72 74 61 3a 74 61 72 74 61 2d 45 53 50 00  >tarta:tarta-ESP.<
3fffe030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
3fffe040 62 32 3e 69 00 00 00 00 01 00 00 00 00 00 00 00  >b2>i............<
3fffe050 80 ff 1f 00 00 00 00 00 00 00 00 00 03 00 00 00  >................<
[...]
*
40000000
root@tarta:~# wc -c /dev/md/tarta-ESP
1073676288 /dev/md/tarta-ESP

except the bitmap and the superblock are backwards.

As advertised, metadata 1.1 and 1.2 put the superblock at 0 and 4k, respectively The seemingly-promising --data-offset argument only moves where the data is allocated, not the superblock.

Thus,

root@tarta:~# mkfs.vfat -n tarta-ESP /dev/md/tarta-ESP
mkfs.fat 4.2 (2021-01-31)
root@tarta:~# sed -i '\;/boot/efi.*vfat;s;^[^[:space:]]*;LABEL=tarta-ESP;' /etc/fstab
root@tarta:~# # If you use a path instead then use /dev/md/tarta:tarta-ESP! It comes back as tarta:tarta-ESP and I haven't the faintest why.
root@tarta:~# mount /boot/efi
root@tarta:~# cp -r oldbootefi/* /boot/efi
root@tarta:~# lsblk
NAME                       MAJ:MIN RM    SIZE RO TYPE  MOUNTPOINTS
sda                          8:0    0    100G  0 disk
├─sda1                       8:1    0      1G  0 part
│ └─md127                    9:127  0 1023.9M  0 raid1 /boot/efi
└─sda2                       8:2    0     99G  0 part
  └─tarta--LVM-tarta--root 252:0    0    248G  0 lvm   /
sdb                          8:16   0    100G  0 disk
├─sdb1                       8:17   0      1G  0 part
│ └─md127                    9:127  0 1023.9M  0 raid1 /boot/efi
└─sdb2                       8:18   0     99G  0 part
  └─tarta--LVM-tarta--root 252:0    0    248G  0 lvm   /
sdc                          8:32   0    100G  0 disk
├─sdc1                       8:33   0      1G  0 part
│ └─md127                    9:127  0 1023.9M  0 raid1 /boot/efi
└─sdc2                       8:34   0     99G  0 part
  └─tarta--LVM-tarta--root 252:0    0    248G  0 lvm   /
root@tarta:~# reboot

and it comes up normally. But what does the EFI think, and does this still pick up changes to one of the ESPs? Breaking into the shell yields:

UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Mapping table
      FS0: Alias(s):HD1b:;BLK2:
          PciRoot(0x0)/Pci(0x3,0x0)/HD(1,GPT,ECF7F5B7-951D-AF46-97B5-B26D2CDE9EE2,0x800,0x200000)
      FS1: Alias(s):HD2b:;BLK5:
          PciRoot(0x0)/Pci(0x4,0x0)/HD(1,GPT,ECF7F5B7-951D-AF46-97B5-B26D2CDE9EE2,0x800,0x200000)
      FS2: Alias(s):HD3b:;BLK8:
          PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,ECF7F5B7-951D-AF46-97B5-B26D2CDE9EE2,0x800,0x200000)

Shell> vol fs0:
Volume tarta-ESP (rw)
1071562752 bytes total disk space
1062363136 bytes available on disk
4096 bytes in each allocation unit
Shell> vol fs1:
Volume tarta-ESP (rw)
1071562752 bytes total disk space
1062363136 bytes available on disk
4096 bytes in each allocation unit
Shell> vol fs2:
Volume tarta-ESP (rw)
1071562752 bytes total disk space
1062363136 bytes available on disk
4096 bytes in each allocation unit

FS0:\> cp FS0:\EFI\BOOT\bootx64.efi fs0:
Copying FS0:\EFI\BOOT\BOOTX64.EFI -> fs0:\BOOTX64.EFI
- [ok]
FS0:\> FS0:\EFI\BOOT\BOOTX64.EFI

  Booting `Debian GNU/Linux'

Loading Linux 6.12.57+deb13-amd64 ...
Loading initial ramdisk ...
Debian GNU/Linux 13 tarta ttyS0

tarta login: root
root@tarta:~# journalctl -b
Dec 14 20:00:59 tarta systemd-fsck[444]: fsck.fat 4.2 (2021-01-31)
Dec 14 20:00:59 tarta systemd-fsck[444]: /dev/md127: 15 files, 2480/261612 clusters
Dec 14 20:00:59 tarta systemd[1]: Finished systemd-fsck@dev-disk-by\x2dlabel-tarta\x2dESP.service - File System Check on /dev/disk/by-label/tarta-ESP.
root@tarta:~# ls /boot/efi
BOOTX64.EFI  EFI

It doesn't mind, and yes it does (in spite of the bitmap thing? unclear what this implies). Removing one of the disks also works.

The conclusion to the mdadm approach is that it works perfectly, except that it's passé and cringe because it's mdadm.

# LVM2

's metadata must have a label in blocks [0,4) (this alone would be surmountable, mkfs.vfat -R 4 gives us space for 2! in fact, FAT can ignore any number of blocks at the start of the device, so long as it gets the first two), then a header around a megabyte in, then user data, in this order.

root@tarta:~# pvcreate --labelsector 2 --dataalignment 512M /dev/vda1
  Physical volume "/dev/vda1" successfully created.
root@tarta:~# vgcreate T /dev/vda1
  Volume group "T" successfully created
root@tarta:~# vgs
  VG        #PV #LV #SN Attr   VSize    VFree
  T           1   0   0 wz--n-  512.00m 512.00m
  tarta-LVM   3   1   0 wz--n- <296.99g  49.00g
root@tarta:~# lvcreate -L512M T
  Logical volume "lvol0" created.
root@tarta:~# tr \\0 A < /dev/zero > /dev/mapper/T-lvol0
tr: write error: No space left on device
root@tarta:~# vgchange -a n T
  0 logical volume(s) in volume group "T" now active
root@tarta:~# od -Ax -tx1z /dev/vda1
000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
000400 4c 41 42 45 4c 4f 4e 45 02 00 00 00 00 00 00 00  >LABELONE........<
000410 c6 6f e8 56 20 00 00 00 4c 56 4d 32 20 30 30 31  >.o.V ...LVM2 001<
[...]
000490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
001000 9d 76 17 c1 20 4c 56 4d 32 20 78 5b 35 41 25 72  >.v.. LVM2 x[5A%r<
[...]
001a10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
20000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41  >AAAAAAAAAAAAAAAA<
*
40000000

root@tarta:~# truncate -s 1G 1G
root@tarta:~# mkfs.vfat --mbr=n -R 2048 1G $((1024*512))
mkfs.fat 4.2 (2021-01-31)
Warning: block count mismatch: found 1048576 but assuming 524288.
root@tarta:~# mount 1G dir
root@tarta:~# tr \\0 B < /dev/zero > dir/B
tr: write error: No space left on device
root@tarta:~# umount dir
root@tarta:~# od -Ax -tx1z 1G
000000 eb 58 90 6d 6b 66 73 2e 66 61 74 00 02 08 00 08  >.X.mkfs.fat.....<
[...]
000400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
000c00 eb 58 90 6d 6b 66 73 2e 66 61 74 00 02 08 00 08  >.X.mkfs.fat.....<
[...]
001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
100000 f8 ff ff 0f ff ff ff 0f f8 ff ff 0f 04 00 00 00  >................<
100010 05 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00  >................<
[...]
1ff800 ff ff ff 0f 00 00 00 00 00 00 00 00 00 00 00 00  >................<
1ff810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
200000 42 20 20 20 20 20 20 20 20 20 20 20 00 74 a6 ab  >B           .t..<
200010 8e 5b 8e 5b 00 00 a8 ab 8e 5b 03 00 00 e0 df 1f  >.[.[.....[......<
200020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
201000 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42  >BBBBBBBBBBBBBBBB<
*
1ffff000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
40000000

root@tarta:~# vgchange -a n T
  0 logical volume(s) in volume group "T" now active
root@tarta:~# dd bs=512 < 1G > /dev/vda1 conv=sparse
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 35.7855 s, 30.0 MB/s
root@tarta:~# vgs
  VG        #PV #LV #SN Attr   VSize    VFree
  T           1   1   0 wz--n-  512.00m     0
  tarta-LVM   3   1   0 wz--n- <296.99g 49.00g
root@tarta:~# vgchange -a y T
  1 logical volume(s) in volume group "T" now active
root@tarta:~# tr -d A < /dev/mapper/T-lvol0 | wc -c
0
root@tarta:~# tr \\0 C < /dev/zero > /dev/mapper/T-lvol0
tr: write error: No space left on device

root@tarta:~# mount /dev/vda1 /mnt
mount: /mnt: unknown filesystem type 'LVM2_member'.
       dmesg(1) may have more information after failed mount system call.
root@tarta:~# mount -r -t vfat /dev/vda1 /mnt
mount: /mnt: fsconfig() failed: /dev/vda1: Can't open blockdev.
       dmesg(1) may have more information after failed mount system call.

root@tarta:~# vgchange -a n T
  0 logical volume(s) in volume group "T" now active
root@tarta:~# mount -r -t vfat /dev/vda1 /mnt
root@tarta:~# ls -l /mnt/
-rwxr-xr-x 1 root root 534765568 Dec 14 22:29 /mnt/B
root@tarta:~# tr -d B < /mnt/B | wc -c
0

root@tarta:~# od -Ax -tx1z /dev/vda1 | tail
200010 8e 5b 8e 5b 00 00 a8 ab 8e 5b 03 00 00 e0 df 1f  >.[.[.....[......<
200020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
201000 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42  >BBBBBBBBBBBBBBBB<
*
1ffff000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
*
20000000 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43  >CCCCCCCCCCCCCCCC<
*
40000000

# Conclusion

There is only one way to do this: with mdadm. This way is kosher, but a little cringe. But to be cringe is to be free.

apt install mdadm

cp -r /boot/efi .
umount /boot/efi

mdadmC() { mdadm -C $(uname -n)-ESP -l mirror -e 1.0 --bitmap=internal -n $# "$@"; }
mdadmC /dev/part1 /dev/part2 ... /dev/partN

mkfs.vfat -n $(uname -n)-ESP /dev/md/$(uname -n)-ESP
sed -i '\;/boot/efi.*vfat;s;^[^[:space:]]*;LABEL='$(uname -n)'-ESP;' /etc/fstab

mount /boot/efi
cp -r efi/ /boot/

Nit-pick? Correction? Improvement? Annoying? Cute? Anything? Mail, post, or open!