-
Posts
1896 -
Joined
-
Last visited
-
Days Won
8
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by jbartlett
-
-
18 minutes ago, bastl said:
@jbartlett Try it on a slower drive if you have the time for, maybe the array itself. It looks like it is an IO related issue. Quickly setup a default Linux vm and click trough the installer and see what happens. 😉
I think I did try that once on an array XSD spinner, I'll do it again to make sure.
I just (apparently) successfully installed an Ubuntu server on a 2 GB (minimum spec) qcow2 and while the install did not display any errors, booting it show a "no such file or directory" when checking the root file system at boot and then segfaulted/hung.
-
I have a long-existing Windows 10 VM running with three qcow2 drives on a Samsung 960 EVO nvme drive formatted with XFS and it had no issue running for several days on RC4 and the qcow2 files do not seem to be corrupted after reverting back to the stable release.
I never tried creating a VM on RC4 with a small vdisk, never smaller than 120G, but the OS install never completed successfully while the qcow2 file was on a XFS. I must've tried a couple dozen times using Windows 10 & Ubuntu.
-
59 minutes ago, quinnmjcj said:
Had the following issue on rc-4 (didn't try any of the previous 6.80rc builds): Can't run any .py or .sh script (didn't try an executable) on the boot flash.
To expand on bonienl's response, the solution is to copy the script to the /tmp directory, mod permissions, and execute it from there. This is how the go script is executed.
-
1 hour ago, Fizzyade said:
i used the qcow option straight on the unraid drop box and upon upgrading to rc4 both my linux vm’s corrupted within minutes of each other.
Please state the file system that hosted the qcow drives.
-
2 minutes ago, limetech said:
We can downgrade qemu from 4.1.x back to 4.0.x - think that will solve it?
I'm willing to test that. Even on vacation checking on wedding venues and from remoting in via Splashtop (if released after tomorrow).
-
My previous tests were on a Threadripper 2. Tried them on an Intel chip for due diligence. Same results.
-
1 minute ago, limetech said:
That's not compressed.
Ah, then it's a misunderstanding between that and dynamically expanding. I'll update the subject of my report.
-
16 minutes ago, limetech said:
Can't hold back 6.8 release because of this. Compressed qcow2 has never been an option in our VM manager.
It has been for awhile.
(selected qcow2 though the screenshot is of the default)
-
4 minutes ago, limetech said:
Why are you creating a separate bug report then?
Because that report as posted is different, and hosting on a BTRFS cache drive. I didn't read the comments on it until after posting this report and it is in those comments that I saw people mentioning issues with XFS so I commented with a link to it.
-
I see similar issues posted in this report
-
4 hours ago, jonathanm said:
What vdisk type did you choose? RAW or qcow?
qcow2. It seems that the root issue is installing a qcow file on a XFS formatted drive (a SSD mounted by UD). Raw worked fine. qcow on BTRFS (reformatted the SSD) also worked fine.
-
Anybody try creating a new Windows 10 VM under RC4? I had a DEVIL of a time trying to get it to work. The install would copy the files, go all the way to the "Finishing up" and then display any one of several errors - corrupted media, cannot set local, could not load a driver, could not continue, or just jump right back to the setup button at the start.
Rolled back to 6.7.2 and poof - installation went like a champ though I did have to edit/save because using the RC4 built XML gave an invalid machine type error.
-
I noticed mine took longer on my three servers but it came up after a minute or so.
nasbackup-diagnostics-20191024-1728.zip vm1-diagnostics-20191024-1727.zip nas-diagnostics-20191024-1727.zip
-
29 minutes ago, John_M said:
There isn't any scaling. It isn't a Retina display. It's 1:1.
jbartlett says he's using -rc1. I'm using -rc3, which is the subject of this thread,
Server freed up, upgraded to RC3, Dashboard looks identical to RC1.
-
Dashboard column issue was created along with another
-
This is what I see on RC1 Dashboard with the white theme using Firefox with monitor set to 1920x1080
- 1
-
Just as a FYI, I can't actually tell what's bolded and what's not.
-
1 minute ago, JoeUnraidUser said:
You are incorrect about CA User Scripts. A script cannot be scheduled to run at boot. Also, you can only run Bash scripts.
My bad. I was repeating information read in other threads.
-
1 hour ago, dee31797 said:
Just curious, can you change the permissions of the flash files in the go file?
No. Global permissions are set at mount time.
-
In summary, copy any scripts to /tmp, set permissions, and execute them from there. The "go" file is executed in the same way (not from flash) since day one. Another option is to use the User Scripts plugin.
-
In my case, the root cause was a WD Black NVMe 256GB that stopped responding due to the unit overheating. It wasn't an obvious cause for me because the drive was not utilized in any fashion and it was easier to leave it in there than take it out (until this happened).
-
Honestly, I didn't even know there was a global setting for disabling the cache drive functionality outright. Seems counter productive. To me, having a drive configured as a cache drive implies it should be on.
-
That's exactly it. The shares allowed setting the cache drive as well so it wasn't obvious.
-
Changed Status to Open
Changed Priority to Annoyance
6.8.0 RC1+RC4 corrupted QCOW2 vdisks on XFS! warning "unraid qcow2_free_clusters failed: Invalid argument" propably due compressed QCOW2 files
-
-
-
-
-
in Prereleases
Posted · Edited by jbartlett
I don't have a RC4 system running a parity drive so I dropped in a decade old 300GB drive that read 62MB/sec at the start and tried that with Ubuntu desktop on a 20GB (min spec) qcow2. Installer crashed.