Revert disko boot partition rename - it broke the live deploy

Renaming the Nix attribute from ESP to bootfs changed the GPT partition
label disko expects fileSystems."/boot" to reference, but the physical
partition on the already-installed disk still carries the original
disk-main-ESP label from initial install - renaming an attribute here
doesn't relabel it. On deploy this hung boot.mount/local-fs.target waiting
for a device that doesn't exist, which cascaded into blocking every
service queued behind sysinit.target (AdGuard, the new ACME cert, Actual)
and ultimately required a restore from an older snapshot to recover.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

1 files changed, 11 insertions, 3 deletions

diff --git a/hosts/eurovm/disko.nix b/hosts/eurovm/disko.nix
index 5176340..bf0ca8c 100644
--- a/hosts/eurovm/disko.nix
+++ b/hosts/eurovm/disko.nix
@@ -21,9 +21,17 @@
           };
 
           # 512 MiB /boot - keeps kernels/initrds out of root for clarity.
-          # Not a real EFI System Partition (ext4, not FAT32/type EF00) -
-          # this is a BIOS-boot setup, GRUB just needs a plain filesystem here.
-          bootfs = {
+          # Named ESP for historical reasons (matches the GPT partition label
+          # already baked into the live disk from initial install) even
+          # though it's not really an EFI System Partition (ext4, not
+          # FAT32/type EF00) - this is a BIOS-boot setup, GRUB just needs a
+          # plain filesystem here. Do NOT rename this attribute: disko
+          # derives the actual GPT partition label from it, and renaming it
+          # here does not relabel the already-installed physical partition -
+          # fileSystems."/boot" would then point at a by-partlabel device
+          # that doesn't exist, hanging boot.mount/local-fs.target on
+          # activation (this exact mistake took the server down once).
+          ESP = {
             size = "512M";
             type = "8300";
             content = {