itimpi

That file should not be there as only Unraid should put things under /mnt. For it to be persistent across reboots then you have something recreating it each time. Most likely a docker container configured with a volume mapping to /mnt which should not be there or should be mapped to something else.

Glad to hear that you have managed to get the system up 😀 If you post your system's diagnostics zip file (obtained via Tools->Diagnostics) to a new post in this thread then it will allow us to see exactly what hardware you have and might allow for a suggestion on getting the graphics card working.

This is to be expected. As far as Unraid is concerned a format is just another sort of write operation and it updates parity just like it would for any other write operation.

Are you sure it is crashing rather than simply not having a driver for your graphics card (which one are you using?). Have you checked in your router settings to see if the server is being assigned an IP address? If so you could try connecting a web browser to that address.

Please post your diagnostics zip file so we can see how you have things set up to get an informed answer. Do you have the docker service enabled? If so just starting that is probable enough if your docker.img file is configure to be there even with no containers started.

The diagnosticszip file generated when you select Tools->Diagnostics.

The only time we have seen this it is because the schedule settings were wrong. I suggest you post a screenshot of your settings.

Did you try to run the repair from the GUI or the command line? If the command line what was the exact command you used?

Really up to you - probably worth going straight to a correcting check. The only way is to be certain is to have checksums on the files or to compare it with your backups. This is built in if using the BTRFS or XFS formats, but if using XFS you have to installed something extra such as the File Integrity plugin to get checksums. However if you have not been having disk errors then corruption of files is very rare.

OK, but is the flash drive listed as a bootable device when you go into the BIOS boot options?

Should make no difference. As long as the folder is simply named 'EFI' then it should be bootable in UEFI mode. When you go into the BIOS does it show the drive as bootable into UEFI mode? If not are you sure your motherboard supports UEFI mode?

Nothing as long as you do nothing other than check it boots OK! The idea is to see if it boots cleanly as that can help diagnosing the problem area.

If you had unclean shutdowns then a few parity errors are to be expected when running a check. The way forward would normally be to run a correcting check. This should show the same number of errors as each one is corrected. A subsequent check should show 0 errors. A small number of CRC errors is not normally something to worry about other than them slightly affecting performance as they trigger retries, but if the count keeps increasing then you should be checking the power/SATA cabling. Note that this number resets so all you can do is stop it increasing.

Are you trying to boot in legacy or UEFI mode? If UEFI mode have you made sure that the EFI folder on the flash drive does not have a trailing '-' character? If trying to boot in legacy mode have you tried formatting the flash drive with something like Rufus and setting it to be bootable there? Sometimes that seems to work better than using the USB Creator tool to do the formatting.

You should not have done this (and would have gotten a pop up on trying to warn you that format is never part of data recovery). You will have formatted the emulated drive and updated parity to reflect this. The rebuild process will just be rebuilding an empty file system. Do you have backups? If not the best chance of getting data off the drive is using file recovery software such as UFS Explorer on Windows. That app is not free but does have a free option that would show what might be recovered.