A bit of background
Since you see named boot entries like
Windows Boot Manager and
debian, you clearly have a system with UEFI firmware, booting the named OSs in UEFI native mode. Since one of the named boot entries refers to Windows, it also suggests that your disk uses GPT partitioning style, as Microsoft has tied the choice of partitioning style and firmware type together by design: Windows only supports the combinations of legacy BIOS + MBR, or UEFI + GPT: unlike with Linux, you cannot mix the two sets.
Most UEFI systems still have the capability to run a BIOS Compatibility Support Module (CSM), although it may have been disabled by default as per Microsoft Windows 8.1 certification requirements.
In BIOS compatibility mode, you basically just select the disk you want to boot from, with no labels possible other than the disk vendor/model name. The code in the Master Boot Record (MBR) of the disk will then dictate what happens next: a classic Windows MBR will look for a primary partition with a boot flag enabled. The BIOS version of GRUB will just ignore the partition boot flags and follow its configuration.
In UEFI mode, to fully identify a boot target, you ideally should be specifying both a partition and a boot filename on that partition. The UEFI firmware has a built-in capability to read files from partitions formatted with FAT-type filesystems (usually not including exFAT). In GPT partitioning, there is a designated partition type called "EFI System Partition" or ESP for short, which is expected to contain the bootloaders of any and all operating systems installed on the disk that contains the ESP.
It is possible to have multiple ESPs on the same disk, but I would not recommend that, because firmware-level boot selection user interfaces won't always support that. Since your system's boot menu does not indicate partition numbers, I suspect it might have some trouble presenting multiple ESPs per disk - or at the very least, you would have even more trouble telling the boot entries apart.
In UEFI boot style, an installed OS is expected to define a UEFI NVRAM boot variable: this creates a named boot entry, which will then point to a specific boot file on a specific ESP partition.
If there are no boot variables defined for some UEFI-bootable media, the UEFI firmware can look for a removable media/fallback boot file: in 64-bit x86 hardware, it will be
<ESP mountpoint>/EFI/BOOT/BOOTx64.efi, although the FAT filesystem type is supposed to be case insensitive.
The bottom two boot entries (other than Enter Setup) might actually mean either "try booting the removable media/fallback boot file on the first ESP on this disk in UEFI mode", or "try booting from this disk in legacy BIOS mode". Unfortunately the boot menu interface offers no clues which of the two it might be.
efibootmgr -v output indicates the UEFI device path associated with them is
BBS(HD,,0x0)..BO, where BBS refers to BIOS Boot Specification, which pre-dates UEFI, so these two entries would seem to be for booting in legacy BIOS mode.
The two entries for
debian are revealed by
efibootmgr -v to be "Debian with Secure Boot support enabled" (
\EFI\DEBIAN\SHIMX64.EFI as the boot file), and "Debian without Secure Boot support" (
Boot0007, skipping the shim and going straight to
Based on the shortness of the PARTUUID string on your second disk, your Windows disk appears to be MBR-partitioned, which with Windows means booting in BIOS style. That suggests the "Windows Boot Manager" entry in the boot menu is probably a non-functional remnant of an earlier installation: if (and only if) that is true, you can remove it in Linux by noting that it is in boot variable
Boot0006 and then using
efibootmgr to remove it:
sudo efibootmgr -b 0006 -B
BootCurrent: 0000 indicates that you have successfully started Debian using the Secure Boot-compatible method (the
Boot0000 line). I would urge you to keep using that for future-proofing your system. You can delete the non-Secure Boot entry for Debian (
sudo efibootmgr -b 0007 -B
Unfortunately, as long as your Windows disk is still MBR-partitioned and so your Windows must boot in legacy BIOS style, removing the two boot entries mentioned above is probably the best you can get. Since the firmware cannot know all the possible bootable and non-bootable MBR boot code contents, it may not be able to identify for certain whether or not the MBR of the Samsung disk is actually bootable in BIOS style or not, so it will show the menu entry for it anyway to err on the safe side.
Disabling the legacy BIOS compatibility mode would remove the bottom two boot options, but as long as your Windows is on a MBR-partitioned disk, you won't be able to do that (unless Windows 11 has silently added support for the UEFI + MBR-partitioned disk combination).
To ensure that your Debian will be easily bootable even if your firmware settings are totally lost (as might happen with BIOS updates, depending on system vendor), you might want to install a second copy of Debian's bootloader in the removable media path:
sudo grub-install --uefi-secure-boot --force-extra-removable /dev/nvme0n1
This might either add some sort of "UEFI" note to the "Samsung SSD" boot entry, or perhaps add another menu entry altogether: without trying it is impossible to know for sure, as firmware implementations vary.