I am putting together a new Debian system with a few peculiarities:
I am not using the standard installer, but doing it by hand using debootstrap. Reason: my underlying disks (1 SSD and 2 large hard disks) have certain requirements not covered in any of the standard installers. I have bcache for one of the HDs (backing partition) mapped on to one of the partitions on the SSD (cache). On top of that, I have multiple luks encrypted partitions (including an encrypted /boot), and then multiple LVMs. This choice is specific to certain applications I am going to use the machine for. After a lot of trial and error, and consulting numerous online resources, I have got this installed the way I want, and I can mount partitions, and chroot into the system. I have set up a user, and packages I need etc.
The problem I have run into is EFI and grub. The system doesn't boot (No bootable devices found, even before getting to the grub screen - so the problem is with EFI). Yes, I used efi=runtime kernel option in the live USB boot, confirmed that /sys/firmware/efi/efivars was non empty, and efibootmgr reports that the EFI entry for the system exists. I did mount /sys/firmware/efi/efivars prior to chroot, update -u -k all, grub-install /dev/sda and update-grub. Just to be safe, I deleted all the EFI entries (except the live USB) prior to grub-install. I have secure boot disabled in the BIOS. There used to be an old working Linux installation on this machine, so I know that the BIOS doesn't have any anti-Linux quirks.
I have been extra careful with UUIDs, which led me to notice something strange:
The UUID generated inside chroot by the above commands in /boot/efi/debian.. grub.cfg doesn't correspond to any of the many UUIDs present on the system (yes, I have checked and rechecked). Certainly not to /dev/sdc1 which is the block device housing the encrypted /boot, and certainly not to the luks container that is mapped to /boot. /boot/efi is the only unencrypted partition in my setup.
I have thought of manually editing grub.cfg in EFI, but held back just in case this is expected behavior.
A few more pieces of possibly relevant information. This system has /boot/efi on /dev/sda1 (unencrypted), and /dev/mapper/EncryptedBootPartition on /dev/sdd1 (/dev/sdb is taken up by an external USB disk (no, it is not used for the install), while /dev/sdc1 is the backing partition, with cache on /dev/sda2). The /boot partition is outside any of the LVM groups, so there is no LVM involvement for /boot. Given that there is an external USB disk present, I am using UUIDs for everything in /etc/fstab and /etc/crypttab. The last thing doesn't matter for this problem anyways since I am unable to get past EFI.
There used to be an old Linux installation on one of the disks, but all the disks have been through an ATA secure clean and multiple reformats during this setup, so I can't imagine how an old stale UUID would get into this new system.
Why would grub-install generate a bogus UUID? What should I do to fix this? I would prefer a scriptable solution because once this setup is proven to result in a working system, I plan to distribute the long bash script I have written to accomplish all of the above.
boot/efi/debian.. grub.cfg... what is the actual path here? because on my debian systems it's/boot/efi/EFI/debian/grub.cfg- and the UUID in there corresponds to the UUID of my root partition ....grub-install /dev/sdais definitely not the right command to install a EFI variant of grub though. I'm not sure why it even executed when you were (apparently) booted in UEFI mode (maybe you need something likegrub2-installin Debian?). Assuming you've chrooted into the installation, what you should run is something like:grub-install --efi-directory /boot/efi(no/dev/sdX; UEFI booting is file-based). You may want to add--target x86_64-efias a safe guard.grub-install dummy(dummy can be used as dummy placeholder for when EFI is detected, which should be the case, but I'm sure Tom Yan's command is better) from the chroot can use it. Same for efibootmgr: from the chroot. Also are you sure /boot/efi/debian is correct? Shouldn't that be in the end /boot/efi/EFI/debian (with efi the fat32 mountpoint and EFI a directory within)? See also the --removable option which can help in this wiki: wiki.archlinux.org/title/GRUB#Installation_2--boot-directory,--efi-directorydoes not have an implicit default value. Also speaking of the efivars mounting, I hope that you didn't forget the "prefix" when you specified the mountpoint. (Or, was it not mounted out of the box in the live environment?)