ZFS-Plattenspiegel und EFI-EF02-Bootpartition

[Peter Blancke]

Guten Tag,

hier unter Archlinux habe ich einen Rechner mit bisher EINER
Festplatte wie folgt:

sda
+---sda1 EF00 EFI System Partition
+---sda2 BF01 Solaris ...

Auf sda2 läuft ein kompletter ZPOOL (also Rootpartition und alle
Daten. Gebootet wird das ganze mit dem Bootmanager von Systemd
(bootctl) unter EFI. Klappt einwandfrei.

Jetzt erweitere ich als Schutz gegen Plattenausfall das System um
eine zweite baugleiche Platte /dev/sdb und baue den ZPOOL zu einem
Spiegel um. Klappt alles einwandfrei.

/dev/sda1 habe ich händisch nach /dev/sdb1 kopiert und kann von
beiden Platten aus booten. Das funktioniert alles einwandfrei.

Werden Kernel oder initramfs aktualisiert, kopiere ich nachher per
Hand den einen Bootsektor wieder auf den zweiten. Klappt ebenso.

Aber das letzte soll "bequemer" geschehen, indem das händische
Kopieren entfallen soll, auch, weil man es vergessen kann.

Bisher hängt /dev/sda1 wie gewohnt unter /boot.

Als einzige Lösung fällt mir bisher ein, ein kleines LVM für den
Verbund sda1 und sdb1 als /dev/md0 zu bauen und dann /dev/md0 unter
/boot zu mounten.

Wird das mit Boot-Systemd klappen? Wird der die EF00-Partition unter
/dev/sda1 bzw. /dev/sdb1 noch als solche erkennen und booten oder
kommt ihm da LVM ins Gehege?

Oder welcher andere Weg wäre gangbar? Ich möchte NICHT auf Grub
umsteigen, auch wenn es da mit einem LVM klappt.

Danke für Denkanstöße!

Gruß,

Peter Blancke

[Friedemann Stoyan]

Post by Peter Blancke
Danke für Denkanstöße!

Ich mache das so: Beide EFI Partitions sind gemountet:

fstab:
UUID=1E1B-080F /boot vfat nofail,discard,umask=0027 0 2
UUID=35C8-314F /boot1 vfat nofail,discard,umask=0027 0 2

Dann habe ich mir eine kleine systemd-Unit geschrieben:

# /etc/systemd/system/esp-sync.service
[Unit]
Description=Sync ESP Partition
ConditionFileIsExecutable=/usr/bin/rsync
ConditionPathIsMountPoint=/boot
ConditionPathIsMountPoint=/boot1
After=systemd-boot-update.service

[Service]
Type=oneshot
ExecStart=/usr/bin/rsync --verbose --recursive --times /boot/ /boot1/

[Install]
WantedBy=systemd-boot-update.service


Und eine Pacman-Hook:
# /etc/pacman.d/hooks/update-second-esp.hook
[Trigger]
Type = Package
Operation = Install
Operation = Upgrade
Target = linux
Target = amd-ucode
Target = intel-ucode

[Action]
Description = Updating secondary ESP
When = PostTransaction
Exec = /usr/bin/systemctl start esp-sync.service


Damit wird die zweite ESP automatisch geupdated.

mfg Friedemann

[Peter Blancke]

Post by Friedemann Stoyan
After=systemd-boot-update.service
[Service]
Type=oneshot
ExecStart=/usr/bin/rsync --verbose --recursive --times /boot/ /boot1/
[Install]
WantedBy=systemd-boot-update.service

systemd-boot-update.service... Den muß ich erst einmal richtig
verstehen. Schlägt der immer zu? Nur beim Booten? Nur beim
Herunterfahren?

Post by Friedemann Stoyan
# /etc/pacman.d/hooks/update-second-esp.hook
[Trigger]

Aber die Idee mit den Hooks bei Pacman, die greife ich mal auf und
test das.

Danke.

Gruß,

Peter Blancke

[Peter Blancke]

Am 2024-12-07, Friedemann Stoyan <***@ip6-mail.de> schrieb:

Danke erst einmal, Friedemann, für Deine Denkanstöße.

Ich habe das jetzt mal alles durchgearbeitet und noch ein wenig
angepaßt.

Bei mir sind jetzt beide EFI-Boot-Partitionen ebenfalls dauerhaft
gemounted, wiewohl man den Mount der zweiten Partition auch in das
Script hineinpacken könnte.

Sollte eine Platte ausfallen, dürfte übrigens der Bootvorgang auch
am Mount-Versuch kleben bleiben und es muß ohnehin händisch
eingegriffen werden.
Die habe ich in einer Zeile geändert, um ggf. Altlasten gleich zu
entsorgen.

Post by Friedemann Stoyan
ExecStart=/usr/bin/rsync --verbose --recursive --times /boot/ /boot1/

ExecStart=/usr/bin/rsync --verbose --recursive --delete --times /boot/ /boot1/

Das "verbose" führt übrigens zu KEINER Ausgabe auf der Konsole,
sondern zur entsprechenden Ausgabe in den Logfiles von systemd.

Post by Friedemann Stoyan
Operation = Install
Operation = Upgrade

Erweitert um

Operation = Remove

Das dürfte allerdings wohl selten vorkommen.

Post by Friedemann Stoyan
Damit wird die zweite ESP automatisch geupdated.

Das hat alles geklappt. Bis hierher greifen die Skripte allerdings
nicht beim Aufruf von mkinitcpio.

Damit die Skripte auch bei einem "mkinitcpio -P" greifen, habe ich
einen weiteren Hook mit Rechten 0755 eingerichtet:

,----[ /etc/initcpio/post/esp-update ]
| #!/bin/bash
| echo Update ESP...
| /usr/bin/systemctl start esp-sync.service
`----

Vielen Dank für die passenden Denkanstöße!

Gruß,

Peter Blancke

[Christian Garbs]

Mahlzeit!

Post by Peter Blancke
Als einzige Lösung fällt mir bisher ein, ein kleines LVM für den
Verbund sda1 und sdb1 als /dev/md0 zu bauen und dann /dev/md0 unter
/boot zu mounten.

Wieso LVM? Du kannst doch /dev/sda1 und /dev/sdb1 einfach ein ein
RAID packen (/dev/md0 als RAID 1) - ganz ohne LVM.

Ob systemd-boot RAID unterstützt, konnte ich auf die Schnelle nicht
herausfinden, hier werkelt überall noch grub.

Denk auf jeden Fall dran, dass Du nicht nur die Boot-Partition
mirrorst, sondern auch von Zeit zu Zeit den Bootmanager auf _beiden_
Platten aktualisierst (der wohnt ja vermutlich im MBR).

Gruß
Christian

[Peter Blancke]

Post by Christian Garbs

Post by Peter Blancke
Als einzige Lösung fällt mir bisher ein, ein kleines LVM für den
Verbund sda1 und sdb1 als /dev/md0 zu bauen und dann /dev/md0
unter /boot zu mounten.

Wieso LVM?

Hoppla... Ja, ich meinte latürnich nicht LVM, sondern ein Raid1.

Post by Christian Garbs
Ob systemd-boot RAID unterstützt, konnte ich auf die Schnelle
nicht herausfinden,

Ich müßte die beiden FAT-Partitionen zusammenbauen und sie dann
gemeinsam im RAID1-Verbind unter /dev/md0 mit den Bootdaten
beschicken. Da könnte "bootctrl install" bereits meckern, aber ich
weiß es nicht!

Und dann muß ich darauf hoffen, daß systemd-boot darauf reinfällt
und von einer der beiden FAT-Partition /dev/sda1 bzw. /dev/sdb1
korrekt startet.

Ich beschicke ja unter /dev/md0 zwei Partitionen /dev/sda1 und
/dev/sdb1. systemd-boot bootet dann aber nicht von /dev/md0, sondern
von /dev/sda1. Das wäre der einfachste Weg, wenn's klappen würde.

Ich werd's untersuchen.

Post by Christian Garbs
Denk auf jeden Fall dran, dass Du nicht nur die Boot-Partition
mirrorst, sondern auch von Zeit zu Zeit den Bootmanager auf _beiden_
Platten aktualisierst (der wohnt ja vermutlich im MBR).

Unter EFI? Ich meinte wohl eher nicht.

Danke.

Gruß,

Peter Blancke

[Peter Blancke]

Post by Peter Blancke
Ich müßte die beiden FAT-Partitionen zusammenbauen und sie dann
gemeinsam im RAID1-Verbind unter /dev/md0 mit den Bootdaten
beschicken. Da könnte "bootctrl install" bereits meckern, aber ich
weiß es nicht!

So, das habe ich ausprobiert und das funktioniert NICHT. bootctrl
beschwert sich zu Recht, daß /dev/md0 kein EFI mehr ist. Und somit
scheitert dieses Vorhaben.

Bleibt also doch nur, bei Änderung von /boot (sda1) die Änderungen
auf sdb1 zu synchronisieren. Auslösepunkte: Neuer Kernel, neue
initramfs.

Mal sehen, wie ich das automatisiere. Ich greife die schon benannte
Idee mit einem Hook in pacman auf.

Gruß,

Peter Blancke

[Friedemann Stoyan]

Post by Peter Blancke
Bleibt also doch nur, bei Änderung von /boot (sda1) die Änderungen
auf sdb1 zu synchronisieren. Auslösepunkte: Neuer Kernel, neue
initramfs.

…und Update des Bootloaders selbst. In diesem Fall ruft der systemd den
Service: "systemd-boot-update.service" auf. Dann will man ja auch, dass der
neue Bootloader auch auf der anderen Platte ist. Deswegen die Verknüpfung mit
dieser Unit.

mfg Friedemann

[Marc Haber]

Post by Peter Blancke

Post by Peter Blancke
Ich müßte die beiden FAT-Partitionen zusammenbauen und sie dann
gemeinsam im RAID1-Verbind unter /dev/md0 mit den Bootdaten
beschicken. Da könnte "bootctrl install" bereits meckern, aber ich
weiß es nicht!

So, das habe ich ausprobiert und das funktioniert NICHT. bootctrl
beschwert sich zu Recht, daß /dev/md0 kein EFI mehr ist. Und somit
scheitert dieses Vorhaben.
Bleibt also doch nur, bei Änderung von /boot (sda1) die Änderungen
auf sdb1 zu synchronisieren. Auslösepunkte: Neuer Kernel, neue
initramfs.

Früher habe ich das mit einem allnächtlichen dd + fsck -y auf dem Ziel
gelöst und habe mich dabei schmutzig gefühlt. Heute spare ich mir
meistens den Riss und hab dann halt Handarbeit wenn die erste Platte
verstorben ist. Viele Rechner booten eh nicht von der zweiten Platte
wenn die erste zwar kaputt ist aber noch erkannt wird.

Eigentlich müsste man missionskritischen Systemen ihren kernel plus
das initramfs über das Netz zuwerfen; Netzwerkboot lässt sich leichter
redundant umsetzen als lokaler Boot. Und wenn das redundante Netzwerk
gestört ist dann ist es auch egal ob der Server läuft oder nicht.

Grüße
Marc

[Christian Garbs]

Mahlzeit!

Post by Peter Blancke

Post by Peter Blancke
Ich müßte die beiden FAT-Partitionen zusammenbauen und sie dann
gemeinsam im RAID1-Verbind unter /dev/md0 mit den Bootdaten
beschicken. Da könnte "bootctrl install" bereits meckern, aber ich
weiß es nicht!

So, das habe ich ausprobiert und das funktioniert NICHT. bootctrl
beschwert sich zu Recht, daß /dev/md0 kein EFI mehr ist. Und somit
scheitert dieses Vorhaben.

Was passiert, wenn Du alles gleichzeitig mountest?

- /dev/md0 rw nach /boot/efi
- /dev/sda1 ro nach /mnt/irgendwas/efi_sda1
- /dev/sdb1 ro nach /mnt/irgendwas/efi_sdb1

Damit sollte das Aktualisieren des Bootloaders (also das Kopieren von
Dateien nach /dev/md0) "ganz normal" funktionieren.

Vielleicht kannst Du in der Konstellation bootctrl 2x aufrufen,
jeweils mit --esp-path=/mnt/irgendwas/efi_{sda1,sdb1}

Aber ich habe bootctrl noch nie benutzt (auch efibootmgr nur ein paar
Mal) und weiß nicht, wie das alles in die Automatiken integriert ist,
ich kenne da nur Debian.


Oder ganz anders: In der Manpage zu bootctl(1), die ich gerade online
überfliege, steht folgendes:

| ENVIRONMENT
|
| If $SYSTEMD_RELAX_ESP_CHECKS=1 is set the validation checks for
| the ESP are relaxed, and the path specified with --esp-path= may
| refer to any kind of file system on any kind of partition.
|
| Similarly, $SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 turns off some
| validation checks for the Extended Boot Loader partition.

Das klingt doch passend.


Gruß
Christian

[Peter Blancke]

Post by Christian Garbs
Was passiert, wenn Du alles gleichzeitig mountest?

Zu spät. System wird nicht mehr angefaßt. Denn jetzt läuft's so, wie
beschrieben.

Dennoch: Danke!

Post by Christian Garbs
Vielleicht kannst Du in der Konstellation bootctrl 2x aufrufen,
jeweils mit --esp-path=/mnt/irgendwas/efi_{sda1,sdb1}

Genau eben diese Handarbeit galt's ja zu vermeiden.

Post by Christian Garbs
In der Manpage zu bootctl(1),

Aber die werde ich mir dennoch nochmals genau vornehmen.

Gruß,

Peter Blancke