JorgeB

It should have asked you to create one, if it didn't do this:
 
https://wiki.unraid.net/Manual/Troubleshooting#Lost_root_Password

Then it suggest some hardware issue, try to disconnected everything you can from the board (including all disks/SSDs/controllers), leave the bare minimum to be able to boot and try again.

Yes, just copy the key to the /config folder of the flash drive and reboot.

SMART looks fine, there's a recent UDMA CRC error, so the issue was likely caused by a bad SATA cable, replace that cable and since the emulated disk is mounting and assuming contents look correct you can rebuild on top:
 
https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself
 
 

Try removing the gateway for the other NIC(s), it should only be set for the main NIC/bond

The parity drive is SMR, and while they usually perform mostly normal with sync operations that particular model has been known to sometimes be slow for everything.

Mar 13 04:51:03 KenServer kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Mar 13 04:51:03 KenServer kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]  
Macvlan call traces are usually the result of having dockers with a custom IP address and will end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right))

Suggest backing up and re-formatting that pool.

Tools -> New config, if you are using Parity1 you can check "parity is already valid" after re-arranging the slots.

If the issues started after changing the hardware it suggests a hardware problem, since it's easy I would first try running the server with a single stick of RAM to see if there's any difference, try with at least two different ones in case one has a problem.

Do you have a different PC to try booting Unraid? To see if the flash drive or the server is the problem. 

Mar 2 18:11:02 Tower kernel: megasas: 07.714.04.00-rc1 Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:25:00.0: BAR:0x1 BAR's base_addr(phys):0x00000000f7360000 mapped virt_addr:0x0000000044f6b965 Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:25:00.0: FW now in Ready state Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:25:00.0: 63 bit DMA mask and 32 bit consistent mask Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:25:00.0: requested/available msix 1/1 Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:25:00.0: current msix/online cpus : (1/16) Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:25:00.0: RDPQ mode : (disabled) Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:25:00.0: Failed to init firmware Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:25:00.0: Failed from megasas_init_fw 6406 Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:28:00.0: BAR:0x1 BAR's base_addr(phys):0x00000000f7a60000 mapped virt_addr:0x0000000044f6b965 Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:28:00.0: FW now in Ready state Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:28:00.0: 63 bit DMA mask and 32 bit consistent mask Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:28:00.0: requested/available msix 1/1 Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:28:00.0: current msix/online cpus : (1/16) Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:28:00.0: RDPQ mode : (disabled) Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:28:00.0: Failed to init firmware Mar 2 18:11:02 Tower kernel: megaraid_sas 0000:28:00.0: Failed from megasas_init_fw 6406  
Both RAID controllers are failing to initialize and load the driver, also note that RAID controllers are not recommended, they should be flash to LSI IT mode, which uses the mpt3sas driver, also usually much more reliable than the megaraid driver.

Device is failing to initialize, don't know why, do you have a different model NVMe device you could try?

The parity check you were running was correcting, so it's done, notifications can be off sometimes.

Check filesystem on disk4.

If it's a one time thing you can ignore, if it keeps happening try limiting more the RAM for VMs and/or docker containers, the problem is usually not just about not enough RAM but more about fragmented RAM, alternatively a small swap file on disk might help, you can use the swapfile plugin:
 
https://forums.unraid.net/topic/109342-plugin-swapfile-for-691/

That NIC is not working, so best bet is to get a new NIC (or use a different board/computer if available).
 
 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7542 nobody 20 0 394132 305528 12292 R 100.0 1.9 0:23.11 Plex Tran+  
Plex?

Start here:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173
 

You need to do a new config (Tools -> New config)

With the array stopped click on that pool and change "Enable user share assignment" from "no" to "yes".
 

Stop array, unassign all pool devices, start array, stop array, re-assign all pool devices, start array.

Emulated disk is mounting, assuming contents look correct you can rebuild on top and re-sync parity at the same time:
 
https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself
 
 

You can enable the syslog server.

Looks like this issue: