Seeking Advice on Setting Up AlmaLinux on Bare Metal Cloud with RAID1 + LUKS + UEFI Boot

Support
1

I’m working on a bare-metal cloud (PhoenixNAP) Ram OS setup with the following goals:

  • Using two NVMe drives configured in RAID1 for redundancy.
  • Encrypting the RAID array using LUKS.
  • Installing AlmaLinux 9 (cloud generic image) as the root OS.
  • Booting via UEFI with a fully functional GRUB setup that supports unlocking the encrypted root at boot.

Here’s an overview of the approach we’ve taken:

  1. Partition both NVMe drives with a 200MB EFI partition and a Linux RAID partition.
  2. Create a RAID1 array on the Linux RAID partitions.
  3. Encrypt the RAID array with LUKS.
  4. Format and mount the encrypted volume as the root filesystem.
  5. Download the AlmaLinux generic cloud qcow2 image, mount it via qemu-nbd, and extract the root filesystem onto the encrypted volume.
  6. Chroot into the new system to:
  • Configure /etc/fstab with the encrypted root and EFI partition.
  • Install and configure GRUB with GRUB_ENABLE_CRYPTODISK=y and preload the necessary modules (cryptodisk, luks, mdraid1x).
  • Create a UEFI boot entry with efibootmgr pointing to the GRUB EFI binary.
  1. Ensure boot order prioritizes the new AlmaLinux EFI boot entry.
  2. Reboot and expect a LUKS passphrase prompt on boot.

We ran into some challenges:

  • The EFI boot entry wasn’t created before reboot, causing the server to fall back to PXE boot.
  • GRUB config didn’t initially include cryptodisk.mod, so it couldn’t unlock LUKS during boot.
  • No rescue environment is available on this bare-metal cloud provider, so fixes must be done pre-reboot.
  • Does not have the ability to mount virtual devices so we’re setting everything up from Ram OS (Ubuntu)
  • After completing the AlmaLinux installation on an encrypted RAID1 setup with UEFI boot, the server’s firmware (BIOS/UEFI) does not detect or boot from the NVMe drives as expected. Instead, it falls back to network (PXE) boot
  • The UEFI boot menu shows the physical NVMe drive (e.g., “UEFI Hard Disk”) but does not list the expected boot entry for AlmaLinux (e.g., “almalinux” or the GRUB EFI loader). This indicates that the UEFI boot entry pointing to the GRUB EFI binary is missing or not registered.

Because of this, the system cannot load the bootloader from the disk, preventing it from prompting for the LUKS passphrase and booting the OS.

I’m posting here to see if anyone has:

  • Tips to simplify or improve this workflow.
  • Suggestions on ensuring the EFI boot entry creation is robust and persistent.
  • Recommendations for troubleshooting UEFI boot issues on encrypted RAID setups.
  • Any known pitfalls with AlmaLinux 9 on bare-metal cloud with LUKS + RAID1 + UEFI.

Thanks in advance for your insights!