Hello! I have the following setup: I have one Windows 11 partition, one Arch partition and one Manjaro partition on an NVME-slotted SSD, and then some other systems on two older non-NVME drives, as well as a boot and a swap partition. The Manjaro partition is the one I installed the latest and is the one from which the bootloader is installed and configured. When I first installed it, Manjaro recognized both the Arch and the Windows 11 partition, then yesterday I converted the Arch partition from ext4 to btrfs, which seemed to work flawlessly, but when I re-did grub-mkconfig on Manjaro, it wasn’t able to find the Arch system and gave me a strange bug that made me think perhaps the reason for this was that Manjaro wasn’t on btrfs itself. So I converted the Manjaro partition to btrfs as well, which however seemed to break something. Since the Manjaro partition was intended mainly as a reserve system in case Arch breaks and didn’t contain any important data, I just reinstalled it after formatting its partition to btrfs. However, during the installation, os-prober was able to find the older systems I had on other drives and itself, but neither the Arch system nor the Windows 11 one. So I re-installed Manjaro again, this time again on an ext4-system, however, the same occurred. Any ideas for what might cause this? I should note that I am able to boot both into the Arch and the Windows 11 system if I install and configure Grub from Arch through chrooting (but os-prober on Arch doesn’t even find the older systems) or go from the UEFI directly to the Windows bootloader. Any idea what might cause this and how I can avoid it?
Your topic is a wall of words - it feels like listening to a person which talks fast without pauses or breaks - completely gibberish.
The only thing I get is your headline and the last line
- os prober doesn’t detect other systems
- any idea what cause this
- can it be avoided
os prober relies on information on the relevant partition/device - usually /etc/os-release (perhaps I meant lsb-release).
The issue is often caused by not observing how the system was booted. Many firmware contains a default option to boot in BIOS mode if the boot media can do it - but they are incompatible.
Ensure your system firmware only boot in EFI mode.
This is usually a consequence of mixing native UEFI and non-UEFI operating systems on the same drive. You can have native UEFI and non-UEFI operating systems on separate drives, but not on the same drive.
I recall having an issue like this and it ended up being because of timeshift snapshots for some reason.
It MIGHT have had to do with me removing my home from being a subvol to not on btrfs, but I really can’t remember and I never asked about it on any forum, I just figured this out myself so I have no reference 
Try deleting all your timeshift “backups” (if you have any) and run sudo update-grub, restart and see if that solves it?
You might have to do a sudo mkinitcpio -P before update-grub, can’t remember if was needed or not.
In some cases you’d need to mount your partitions in order for os-prober to recognize them (whether drive is encrypted or etc.). General rule from my experience is that if you can see and read the data in the terminal os-prober will work just fine.
Here is a similar question / solution recently - Boot into systemd-boot alongside grub
Apart from what already has been said, you can check the system logs after running os-prober. It logs a lot of information about what is doing and why it uses some partition or not:
journalctl -e
(You can move with cursor keys and with PgUp, pgDown. Letter q to quit)
Sorry for not replying earlier! All systems on that drive should be native UEFI, but I’ll try to find out if this is indeed the case. I’ll also try again after deleting all snapshots and after mounting all partitions. If none of this works, I’ll look at the logs and if I can’t find anything useful in them.