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.

2 Answers 2


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
        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:

  1. The built-in default $prefix is /EFI/debian, which is a directory which should exist on the ESP.
  2. The embedded configuration tells GRUB to follow the memdisk-based configuration first. The default root filesystem for GRUB will be the ESP.
  3. Since $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.
  4. /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.
  5. There should be a /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.

  • Thank you so much! It seems this was caused by me when I decided to change the name my distro (manually editing some system files like "/etc/lsb-release" and "/etc/osb-release") from Debian to Kdebian. Apparently, it's causing some confusion during re-installation of grub, and in order to get rid of this minor cosmetic error, I should either (1) probably edit one or two more system files, or (2) change the subdir name from kdebian to debian, and also manually change that efi boot entry accordingly, or (3) go back to the original distro name, Debian...
    – Sadi
    Aug 11, 2023 at 9:21
  • It seems this also explains why KDE neon installation results in two EFI subdirs: neon and ubuntu, and maybe I should also create a second subdir named "debian" like that. I would expect KDE neon developers to find a better workaround. If they they couldn't, I shouldn't dare to try with my elementary skills of computing instead of following their lead. ;-)
    – Sadi
    Aug 11, 2023 at 9:27
  • It depends on if you have Secure Boot enabled or not, and if you do, how far you wish to go: using the 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 ;-).
    – telcoM
    Aug 11, 2023 at 9:34
  • Thanks, I've taken the easiest way as KDE neon developers, and it worked. :-) Perhaps I should also add this as a "secondary answer" for adventurer noobs like me changing the distro name in this way.
    – Sadi
    Aug 11, 2023 at 10:01

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)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .