Grub2 cannot handle RAID?

This weekend I tried to install Ubuntu 18.04.2.
On Dell 3050 with SSD (i5, 7th generation, quad core): EFI, RAID SSD settings.
The installation "erase all, install ubuntu" failed.
I tried a lot of things in the BIOS to get rid of it. No way.

So looking around, at gentoo I found a page of grub2 exceptions, and one of it says that you have to change the configuration manually in case of RAID, and will have to handle efibootmgr to aware bios about the /boot/efi existence.

Shit. Still have to do that part, then.

But why is my BIOS SSD "SATA RAID", and is it true this is the cause for not getting Ubuntu alive, automatically?

The first question part: the machine was preinstallend windows10 pro, and the partition style seemed to be more or less hybridic: MBR+GPT+EFI. That means, as long as windows10 was still installed, any legacy partition and/or imaging CD or DVD software could be started and saw MBR and EFI-boot (gdisk so it right, too), but as soon it was an intended ubuntu-only machine, no legacy bootups were allowed anymore.
Funny too, Windows 10 pro seemed to be installed in a hybrid way with boot/efi/windows bootloader instead of an *.efi file, and the windows-os used the efi-partition for a lot more more than just that bootloader.

In the BIOS there were two Windows bootloaders defined.
As soon I dropped one of them, Ubuntu was aware of windows.

So the fun is: there are backups made with software, which cannot be started anymore, and there are external images made with dd (funny their content is manipulatable), but dd tries to install partition-images as disk-images (without additive manual scripting).

As far as I see: the only reason for restoring might a better understanding of the BIOS. I want it to be a ubuntu machine.

Is the gentoo page correct about grub2, or, in this case, might it be correct to reset the BIOS SATA drive (SSD) to be not-RAID to let do grub2 all the work? Or, does it mean, I'll have to do the efibootmgr work manually, anyway?

Thanks