I have installed Debian Testing with KDE Plasma DE, and I think this happened after a while, when I had a Grub problem which I fixed using a live USB, chrooting and re-installing grub.
There's no booting problem other than these two error messages that appear on black screen immediately before the grub menu:
error: no such device: /.disk/info error: no such device: /.disk/mini-info I wonder if this indicates a problem that should be taken care of, and how to fix it.
In Debian 12 (and newer, apparently), when installed on a Secure Boot-enabled UEFI system, the /boot/grub/grubx64.efi includes a memdisk image (approximately 2.4M in size) which contains an Unicode font and a mini grub.cfg file, with the following contents:
if [ -z "$prefix" -o ! -e "$prefix" ]; then if ! search --file --set=root /.disk/info; then search --file --set=root /.disk/mini-info set prefix=($root)/boot/grub if [ -e $prefix/x86_64-efi/grub.cfg ]; then source $prefix/x86_64-efi/grub.cfg elif [ -e $prefix/grub.cfg ]; then source $prefix/grub.cfg else source $cmdpath/grub.cfg It also includes an embedded configuration file which says simply:
normal (memdisk)/grub.cfg The built-in default value for $prefix is set to /EFI/debian.
So, when grubx64.efi begins executing, it will first use the configuration file within the memdisk image.
First, that configuration file checks if $prefix is undefined or there is no matching file or directory on the ESP partition. If so, it will set GRUB's initial $root to whatever partition/filesystem that contains either /.disk/info or /.disk/mini-info, and sets $prefix to point to /boot/grub on that filesystem.
I guess these files would exist on Debian installation media, and this is how Debian can have just one signed reproducible binary build cover all their needs for Secure Boot-compliant bootloader.
It seems to me that with a permanently installed OS, it should work like this:
$prefix is /EFI/debian, which is a directory which should exist on the ESP.$prefix is set and the directory exists on the ESP, the first if ... then condition will not be true, and the search commands should be skipped./EFI/debian/x86_64-efi/grub.cfg does not exist on the ESP (it would exist on the Debian installation media), so the second if ... then condition will not be true either./EFI/debian/grub.cfg on the ESP (/boot/efi/EFI/debian/grub.cfg when the OS is running normally) telling where the real GRUB configuration is located. So the elif condition will be true and GRUB will read the file. If you have a dedicated /boot partition, it could contain something like this:search.fs_uuid 12345678-90ab-cdef-0123-456789abcdef root set prefix=($root)'/grub' configfile $prefix/grub.cfg This would select your /boot filesystem by UUID for GRUB's root filesystem (= the filesystem all subsequent paths accessed by GRUB refer to), and then use it to read the actual GRUB configuration in /boot/grub/grub.cfg.
If your /boot is in a different location, like on an encrypted volume, or just a regular directory on your root filesystem, then the contents of your /boot/efi/EFI/debian/grub.cfg would be different to suit your circumstances.
In your case, something goes wrong in the first if ... then condition within the memdisk configuration: maybe your active grubx64.efi is not located in the ESP's /EFI/debian directory (/boot/efi/EFI/debian/ when accessing it from a booted-up OS)? Or maybe your firmware interprets pathnames case-sensitively and the actual character case of the directory names is different?
Anyway, it ends up searching for /.disk/info and /.disk/mini-info which should exist on installation media only, and those failing searches cause the error messages you're seeing.
Since GRUB is working otherwise, the messages could most likely be harmless and only a minor cosmetic annoyance. But if you wish to get rid of them, you should use efibootmgr -v to review the boot paths in the UEFI boot variables and all the pathnames referenced by GRUB on the way to your real GRUB configuration file (as explained above), and correct any discrepancies as you find them.
debian subdirectory is probably the easiest way, creating a customized grubx64.efi signed with a previously-enrolled MOK would probably be the middle ground, and taking over the control of your firmware Secure Boot keys and signing everything with your own custom keys might be the hardcore way (extra points if there is no user interface for manipulating the firmware keys ;-). Apparently, this problem came about as a result of a “semi-finished” work of changing the distro name from Debian to Kdebian by manually editing a couple of system files. And, thanks to the Accepted Answer above, I could fix it by creating a subdirectory named debian under EFI (in addition to the kdebian subdirectory), containing a grub.cfg file with the following contents only:
search.fs_uuid 6d4c4d33-240f-4577-9282-c3862db81a30 root hd0,gpt3 set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg (Values 6d4c4d33-240f-4577-9282-c3862db81a30 and hd0,gpt3 subject to change according to each system)