MowMdown

What’s the actual issue?

You’ll have to open a support ticket to find out why the USB has been blacklisted.

Make sure the disk shelf is powered on before unraid boots

It’s a known issue. It will be fixed in 7.3.3

There are no limitations other than, you can’t use an existing configuration with a trial.

It’s ok. I just wanted to let others know in case they update and get stuck.

I get stuck during boot on my ugreen dxp 2800 I get something like igc eth0 NETDEV WATCHDOG CPU 2 TIMEOUT and it has a counter that just increases indefinitly. Removing the .plg allows the system to boot normally. Specifically whatever process runs right after these lines in the boot sequence: Sep 3 21:42:56 ugreenRAID rc.wireless: Starting WiFi network... Sep 3 21:42:56 ugreenRAID rc.wireless: WiFi network... No Wifi present. Sep 3 21:42:56 ugreenRAID rc.messagebus: Starting System Message Bus... Sep 3 21:42:56 ugreenRAID rc.messagebus: /usr/bin/dbus-daemon --system Sep 3 21:42:56 ugreenRAID rc.messagebus: System Message Bus... Started. Sep 3 21:42:56 ugreenRAID rc.elogind: Starting Elogin daemon... Sep 3 21:42:56 ugreenRAID rc.elogind: /lib64/elogind/elogind --daemon Sep 3 21:42:57 ugreenRAID elogind-daemon[2061]: New seat seat0. Sep 3 21:42:57 ugreenRAID elogind-daemon[2061]: Watching system buttons on /dev/input/event6 (Power Button) Sep 3 21:42:57 ugreenRAID elogind-daemon[2061]: Watching system buttons on /dev/input/event5 (Power Button) Sep 3 21:42:57 ugreenRAID elogind-daemon[2061]: Watching system buttons on /dev/input/event4 (Sleep Button) Sep 3 21:42:57 ugreenRAID rc.elogind: Elogin daemon... Started. Sep 3 21:42:57 ugreenRAID rc.ip_forward: Activating IPv4 packet forwarding. Sep 3 21:42:57 ugreenRAID rc.ip_forward: Activating IPv6 packet forwarding. Sep 3 21:42:57 ugreenRAID rc.inetd: Starting Internet daemon... Sep 3 21:42:57 ugreenRAID rc.inetd: /usr/sbin/inetd Sep 3 21:42:57 ugreenRAID rc.inetd: Internet daemon... Started. Sep 3 21:42:57 ugreenRAID rc.sshd: Starting SSH server daemon... Sep 3 21:42:57 ugreenRAID dhcpcd[1927]: br0: Router Advertisement from fe80::9ea5:70ff:fe77:80d Sep 3 21:42:57 ugreenRAID rc.sshd: /usr/sbin/sshd Sep 3 21:42:57 ugreenRAID sshd[2199]: Server listening on fd5f:b92d:5a81:0:6e1f:f7ff:fee2:f0f8 port 22. Sep 3 21:42:57 ugreenRAID sshd[2199]: Server listening on fd5f:b92d:5a81::f02 port 22. Sep 3 21:42:57 ugreenRAID sshd[2199]: Server listening on 10.0.10.2 port 22. Sep 3 21:42:57 ugreenRAID dhcpcd-run-hooks: interface=br0, reason=BOUND6, protocol=dhcp6 Sep 3 21:42:57 ugreenRAID update_services: no queued job present Sep 3 21:42:57 ugreenRAID update_services: queue new job 1, wait for 20s <-----PROBLEM STARTS HERE -----> The odd thing is 7.4.0-b1 boots fine

FYI: Ugreen NAS LED drivers have been deprecated by Ich777 and as of 7.4.0-beta2 they will cause boot issues. Make sure to remove the driver plugin before rebooting.

Does this happen when the GPU is under significant load on the unraid system or when it's idle? If it occurs when the GPU is under heavy load it is probably the PSU having a problem supplying power to the GPU.

You seem to be running out of RAM as there are OOM events.

There is a factory reset plugin that will do exactly that. As for containers, you can just delete the docker.img and their corresponding folders under your appdata share

btrfs is detecting corruption on your cache pool. Recommended to run a 24 hour extended memtest. MemTest is only definitive if it finds an error. Your docker.img also appears to have some kind of issue(s) possibly related to the corruption, you will want to check all disk connections as well and then recreate the docker.img after doing a little research it appears that maybe the disk errors are just due to TRIM not being supported if your disks are connected to the system in a non-typical fashion?

You are going to want to take a visit over to the Plex Support Forums for help with this as it's not unraid related. My guess is your database is corrupt. If the Chuck PA script didnt work to repair the database, you will likely need to start over with a new one.

I dont see anything obvious logged other than your jetkvm device seems to have the usb connection reset. Do you recall messing with your JetKVM device? Enabling/disabling options that would essentially cause the USB connection to reset? I suggest running unraid in safe boot mode and keeping containers/VMs disabled for a few days to ensure it's not being caused by a rogue plugin or container/VM. If it can stay running as a basic NAS start enabling services 1 at a time, containers as well.

Look under /dev/dvb/ for "adapter0" or something, then you will pass that such as Value: /dev/dvb/adapter0:/dev/dvb/dapater0