itimpi

Looks like it was the CA Backup plugin that closed down the Docker containers according to the syslog. At the time the diagnostics were taken the backup was still running so there was nothing to show if there were problems restarting them.

If that is the disk being rebuilt, then the errors are coming from the ‘emulated’ drive whose contents are currently being rebuilt and will still be there after the rebuild (a rebuild does not fix file system corruption). I always recommend that the repair is run on the emulated drive before attempting a rebuild as the rebuild process simply replicates onto a physical drive the exact contents of the emulated drive (including any file system corruption). at this point I would think you are best off waiting for the rebuild to finish and then running a file system check/repair on the rebuilt drive. If your parity was good it should repair satisfactorily. Keep the original drive intact as a fall back for recovering data.

With 2 different size SSDs in the cache and configured as RAID1 (the default) for redundancy, the usable space is only that of the smaller drive. You either want to forgo the redundancy and switch to a RAID profile that allows all the space on both SSDs to be used or keep the redundancy but replace the smaller SSD with a larger one.

No, this plugin will not help. It does not control when a check starts - it merely allows you to control the time slots that are used for running increments of the check. You can only use the standard built-in scheduling option for controlling the start of checks.

Your syslog shows that you definitely have corruption on disk8 so that should probably be the first priority for running a file system check/repair.

If you are going to replace any of the bz* files I would suggest replacing ALL of them just in case any of them are corrupt or incomplete.

The upgrade process is one time that a lot of writes occur to the USB drive so maybe not that unlikely.

I wonder if someone could think of an alternative to Yes that might be relatively intuitive concerning the actual behavior. If we could do that the other settings might be OK.

Are you sure you plugged into a USB3 port rather than a USB2 one?

The built-in Unraid GUI is on dynami so

I suspect you are going to need to reformat and rewrite the flash device as it is definitely getting read errors on the Unraid server at the moment. Doing an upgrade is the one time you do a significant amount of writing to the flash drive in normal running of Unraid. Before doing to make sure you have a backup of the 'config' folder from either the current flash drive or a recent backup. Putting that back after recreating the USB drive will put back your configuration.

Not sure why you are getting this problem in the first place, but you might want to look into using the Parity Check Tuning plugin to offload the tasks to periods where the server should be idle.

Unraid has to be picking the config up from somewhere! Did you see my edit where I mentioned the possibility of having another USB stick plugged in that contains it?

When you use the USB creator tool are you sure you are not pointing it to a backup of the flash drive? That is the only way I can think of that you can retain your config. i guess another possibility is that you still have a USB stick plugged into the server that contains your config and this is getting picked up?

What makes you think plugins are loading? Plugins can only be starting if you have their .plg files in the config/plugins folder on the flash drive. As was mentioned loading plugins can be suppressed by starting in Safe Mode. There will also be entries about the plugins loading in the syslog. Are you saying that your array is also showing as defined. I do not see how this would be possible unless you have copied the config folder from your previous install.

No easy GUI method. You can revert manually by downloading the zip file for the release and extract all the bz* type files overwriting the ones on the flash.

If you can read the USB drive on a PC/Mac then all the configuration information is stored in the config folder. If you want more detail on the files on the flash drive then you may find this link to be of interest.

The 6.8 series stable releases are still using a 4.19.x series kernel. The 6.8 rc7 release DID have a 5.x series kernel but rc8 reverted to a 4.19.x series as described here. You will need to wait for the 6.9.0 rc series to start to get a 5.x series kernel or revert to 6.8.0 rc7. Hopefully' the 6.9.0 rc series starts very soon.

I really wish that when you select the option to upgrade that the Release Notes would be popped up so that you had to at least acknowledge that you had seen them. I know that you can already read them by clicking on the appropriate icon but I would prefer a more pro-active approach as then more people would end up reading them.

If you are not sure what drive belongs where in the array then the technique is: Assign all drives as data drives Start the array Ideally all the genuine data drives will mount fine and 2 drives (the parity drives) will show as unmountable. make a note of the serial numbers of the parity drives. If this is not the case stop and ask for help giving details of what happened. Stop the array Go to Tools >>> New Config. Select the option to retain current assignments (as it reduces the chance of error). Click the yes I want to do this and then apply. Go back to the main tab and correct the assignments of the parity drives. Double check you have the right drives as the parity drives as assigning a data drive to parity will lose its contents. You can move any other drives around at this stage as well. Start the array and the system will start building parity based on the current assignments. All your User Shares will re-appear (as they are simply the aggregation of the top level folders on each drive) but with default settings so you may need to re-apply any customisation you want. You can now go any other customisation that is appropriate and add any plugins you normally use. At this point I would recommend clicking on the flash drive on the Main tab and selecting the option to download a backup of the flash drive. It is always good practice to do this any time you make a significant change until/if you have an automated solution.

Shares will show as unprotected if you only have a single cache drive and there are files belonging to a share on the cache drive. How were you doing the download you mentioned? Was it via a mechanism (e.g. docker) that can by-pass the User System? Since most of what look like your media share are set to Use Cache = No if you do get files on the cache belonging to a User Share mover will take no action and they will be left there. Perhaps you should look at what folders are on the cache drive to see if they correspond to User Share you want to be on the array? If you want files to be moved from cache to array by mover then the Use Cache setting needs to be set to Yes for those shares.

The big advantage of docker based solutions is that they are (in principle at least) isolated from and independent of the Unraid release that is hosting it, and will not be affected by Unraid updates. As such a docker based solution is always the preferred approach over the same capability via a plugin.

Although Unraid should transition with no problems to the new hardware as it is basically hardware agnostic this is not necessarily the case with the VMs. Make backups of any vdisks for the existing VMs. Make backups of the XML definitions of your existing VMs. If you are NOT passing through hardware then the transition is likely to be relatively easy and will probably 'just work' If the software running inside the VMs does not like the new CPU you may have to redo them to a version that does. Most modern OS will handle this switch but not all of them. If you are passing any hardware through to the VMs then you are going to have to adjust their configuration to match your new hardware. At the very least all the IOMMU mappings will probably change. You may find that hardware you passed through on the old configuration has problems on the new one.

Yes, if you have more than 1 drive in the cache the only supported format is BTRFS.

Yes. The motherboard/bios combination you are using must be capable of separating all hardware to be passed through to the VM into their own IOMMU groups. This seems to be impossible to predict in advance. You definitely want to pass through any USB controller to be used by the VM to get the best experience.