6.5.2-rc1 breaks Windows 10 VM vdisk creation for me...

Works for me, but we're looking at it further.  Does 'Manual' work?

Thank you for the bug report - though it's not 'Urgent' in sense that system crashes or data is lost, changing to Minor.

Changed Priority to Minor

I can create a Windows 10 VM as before. Do you have a screenshot of what your are (not) seeing?

 

This case should only appear when your 'Default VM storage path' (normally /mnt/user/domains/), found on the VM Manager Settings page, doesn't exists.

 

Code for the VM Edit/Create page hasn't changed between 6.5.1 and 6.5.2-rc1.

Working on other stuff, will attempt to replicate soon...

 

When booting the first time I got a "Fix Common Problems" Red Notification for "Array Not Started"...  Array seemed to take way longer to boot than normal, but did eventually boot up...  Issue may be related...  My current working theory is that part of unRaid booted like the array was started before it actually was...

5 minutes ago, Warrentheo said:

When booting the first time I got a "Fix Common Problems" Red Notification for "Array Not Started"..

Assuming FCP isn't miles out of date, that means that when the tests ran (10 minutes after the Array Started event), /mnt/user didn't exist anymore and the state according to emhttp was not "STARTED"

I re-did the update, and again experienced the same error with FCP...  However this time it didn't result in the same issues with VM creation (attached screenshot showing it working as normal)...

I also attached my diagnostics...  I will in the meantime be reverting again to 6.5.1 stable...

 

4 hours ago, Squid said:

Assuming FCP isn't miles out of date, that means that when the tests ran (10 minutes after the Array Started event), /mnt/user didn't exist anymore and the state according to emhttp was not "STARTED"

The array not started error was showing immediately after login prompt showed on the unRaid console prompt, it definitely didn't take 10 minutes...  While this could be an issue with FCP version mismatch with the new unRaid, I still feel this is unRaid trying to run stuff on a partially, but not fully initialized array...  With my first upgrade to 6.5.2-rc1, this resulted in the VM tab being told that the array was started, but was still unable to parse the list of possible vdisk locations...  

 

qw-diagnostics-20180507-2251.zip

Please start your system in safe mode and restest. This is to make sure the packages and plugins which are now installed do (not) cause the issue.

 

Syslog Highlights:

......

Line 2320: May  7 22:47:04 qw root: Fix Common Problems: Error: Array is not started
......

Line 2375: May  7 22:47:04 qw root: Starting go script
Line 2376: May  7 22:47:04 qw root: Starting emhttpd

......

Line 2425: May  7 22:47:06 qw kernel: mdcmd (29): import 28
Line 2426: May  7 22:47:06 qw kernel: mdcmd (30): import 29
Line 2427: May  7 22:47:06 qw kernel: md: import_slot: 29 empty
Line 2428: May  7 22:47:06 qw emhttpd: import 30 cache device: (nvme0n1) Samsung_SSD_960_EVO_500GB_S3EUNB0J430332H
Line 2429: May  7 22:47:06 qw emhttpd: import 31 cache device: (nvme1n1) Samsung_SSD_960_EVO_500GB_S3EUNB0J502744F

Line 2430: May  7 22:47:06 qw emhttpd: import flash device: sda
Line 2431: May  7 22:47:08 qw emhttpd: Starting services...

......

And so the error is being posted before the array is even probed, let alone started...  That would seem to point to an error with FCP plugin version mis-match...  But that doesn't explain why the original error occurred with the VM creation tab not being able to detect the disks...  I wish I had saved the original syslog from that first boot...