itimpi

Did you try to format the disks?

Another thing to check is whether the CPU fan is working properly as if not that could cause a shutdown when the CPU overheats.

Have you tried using the Manual Method with the new drives - in my experience that often works when the USB Creator tool does not. Even when using the Manual method it may be worth using Rufus to do the formatting of the drive.

Your existing containers should still be there, but what you will not have saved is the settings used when setting them up. The settings were saved as XML templates on the flash drive so if you lost the contents of that you will have to set them up again.

I suspect your issue revolves around this: Jul 3 17:28:55 Lenovo-HR630X emhttpd: pool-one: zfs spares not supported I would think that @JorgeB as an expert on this sort of thing will know how to get around this.

If it fails in the same way (which is what one would expect) then if you can afford to wait a while before reverting then posting your diagnostics (preferably in a new thread under General) might get you a quick resolution if it is something we have seen before.

You tried to install a 7,1,4 rc when 7.1.4 stable (which is more recent) is available! If you try the 7.1.4 stable release make sure that you capture your system's diagnostics zip file as that is likely to identify why you have any issue.

It is not an Unraid issue - it is an Intel issue with that processor tending to fail while in use. Google for details.

1 data plus parity is a special case where the drives end up mirrored. As long as the drives are the same size it does not matter which way around you assign them.

Just for interest why did you try to update to a rc release rather than the stable one?

You get the same effect by setting cache as Primary Storage and Array as secondary storage. When you specify a /mnt/user path then you do not have to know what device a file is currently stored on as it is found on any device. When you specify /mnt/cache then Unraid only looks there.

I would read through all the more recent release notes to see if there is anything that you want to give a compelling reason to update. Having said that as long as you first make a backup of your flash drive so you can easily revert to your current release then nor much risk.

Not much point really. The moment you formatted the drive then parity was updated to reflect this. As was mentioned all a rebuild will do is make a physical drive match the emulated one.

Note that /mnt/user/appdata includes /mnt/cache/appdata as it is a merge of the ‘appdata’ folder on any array drive or pool.

No - these are different protocols.

No - it is Split Level that takes precedence. I got your situation mixed up with somebody else’s The decision as to which drive to use is made at the individual file - and is not based on the total size. If no drive has the required amount of free space then you will get an ‘out-of-space error. The relevant sub-system is not clever enough to remember ghis do it can move onto the next file and get the same error again. It would be nice if there was some way of doing this more tidily but I think it would be none-trivial to implement and is only an issue if your disks are overfilled - most people then simply get another dtive or replace an existing one with a larger one.

That setting DOES work in normal operation. However you also need to read the part of the documentation that mentions the setting is ignored if it is being over-ridden by Split Level. You also need to realise that the part of the system that selects a drive for a new file has no idea how large a file is involved (at that point it has a logical size of 0) which is why it mentions that the setting should be larger than the biggest file you intend to write to avoid a subsequent ‘out-of-space’ error.

Parity and parity2 use different algorithms to calculate their contents so a simple Rename is not possible. If you change Parity2 to no device, and assign the drive instead to the Parity slot its contents will need rebuilding. The array would be unprotected until this completes.

Those errors are typical of connection issues due to cabling and/or power.

I think it might be a good idea if Limetech added an ‘Common Unraid terms’ page to the online documentation and include abbreviations.

Why not simply use a less restrictive Split Level setting?

All the .cfg files in the config folder should be human readable text. If they are not then the file has been corrupted and will need replacing/regeteating.

Check the config/go file on the flash drive looks OK as there is no sign of an attempt to run emhttpd which amongst other things starts the GUI

Unraid has the option to revert to the previous release under the Tools section of the GUI. Even easier is to make a backup of the flash drive (by clicking on the boot device on Main and selecting the Backup option) before attempting the upgrade and if any issues are encountered restore the backup to the flash drive to revert.

Only if the Split Level setting allows it to do so. If it does not then the file cannot be written to the array and you will get an ‘out of space’ error returned.