March 29, 201610 yr @RobJ, There's always a first. That is a lousy thing to say. It's as perfectly fine a thing to say as is posting about the history. History does not always dictate the future. That's all I was conveying. Past performance may not always indicate the future performance but the best way to predict future performance is by using past performance.
March 29, 201610 yr - When necessary to query keyserver, poll up to 45 seconds for a connection. Does this mean that when booting unraid, that the key check now allows 45seconds for the array to come online and VM's to start. IE virtualised pfsense before the keycheck disables the system for an invalid key ? Yup the license check is still a piece of crap. Whatever was done in this release is even worse then the previous two. Previously in 18 and 19 i could reach the unraid web gui and would be told invalid license. Now in 20 the web gui won't load at all until i get a WAN connection, this means i have to manually go patch in a router to get internet access for the license check. It is as retarded as it sounds !! I really don't know why more focus isn't placed on resolving this rather poorly thought out license validation and wasting effort on throw away inclusions like updating firefox in the console gui who no one asked for / wants / even needs. +1 My system refuse to validate and its the first time i ever had any interaction with LT support and they have been zero help. Waited most of the day for them to verify it will not validat and they the took the rest of the day to tell me I need a reliable internet connection. How did you do this ? "manually go patch in a router to get internet access for the license check" First and foremost Stew, I responded to your e-mail, which you sent us at 1:30 AM this morning, not but two hours later because I happened to wake up at that time, saw the message, and decided to respond to you in the middle of the night to at least get the discussion going. As others have indicated, this is beta software and you do not have to participate in the beta if you don't like its requirements. We publicly addressed why we want someone to have their server internet accessible to participate in the beta: For -beta and -rc releases, of all key types, the server must validate at boot time. The reason is that this lets us "invalidate" a beta release. That is, if a beta gets out there with a major snafu we can prevent it being run by new users who stumble upon the release zip file. For example, if there is a bug in P+Q handling. Remember the reiserfs snafu last year? We want to minimize that. For stable releases, Basic/Plus/Pro keys do not validate at boot time, that is, works the same as it always has. Starting with 6.2, Trials will require validation with key server. This is in preparation for making the Trial experience easier. This is a very clear policy and if you missed that post, well, now you've seen it. As far as the other posts in this thread going back and forth about this topic, enough. Any further posts on licensing will be moved to the bilge. This is not up for debate. This thread is to focus on fixing software bugs, not debate our licensing policy on beta software. If you want to do that, you can send us an e-mail with your complaint as per this thread. We're not trying to be jerks here. We have good reasons for requiring Internet access for the beta period and they have already been stated. If your server cannot make a connection to the Internet for the beta, then you will need to refrain from participating in it. I'm sorry if you don't like that answer, but there it is.
March 29, 201610 yr This is a very clear policy and if you missed that post, well, now you've seen it. As far as the other posts in this thread going back and forth about this topic, enough. Any further posts on licensing will be moved to the bilge. This is not up for debate. This thread is to focus on fixing software bugs, not debate our licensing policy on beta software. If you want to do that, you can send us an e-mail with your complaint as per this thread. We're not trying to be jerks here. We have good reasons for requiring Internet access for the beta period and they have already been stated. If your server cannot make a connection to the Internet for the beta, then you will need to refrain from participating in it. I'm sorry if you don't like that answer, but there it is. ***MIC DROP***
March 29, 201610 yr Just found by accident that clearing a disk now does not put array offline, array is available during the process, don't think this was in the release notes.
March 29, 201610 yr Just found by accident that clearing a disk now does not put array offline, array is available during the process, don't think this was in the release notes. nice find! so its just like when a rebuild is going on??
March 29, 201610 yr nice find! so its just like when a rebuild is going on?? Yes, you can see the clear progress like a rebuild, when it's finish just need to format it.
March 29, 201610 yr Just found by accident that clearing a disk now does not put array offline, array is available during the process, don't think this was in the release notes. Yeah, this is new behavior in v6.2 and should be mentioned in the release notes (present since b18).
March 29, 201610 yr Just found by accident that clearing a disk now does not put array offline, array is available during the process, don't think this was in the release notes. That is a fantastic update!
March 29, 201610 yr Just found by accident that clearing a disk now does not put array offline, array is available during the process, don't think this was in the release notes. Can you explain how this works (to the user) please? Do you "ask" it to clear a HDD and it moves all files to other HDDs (like the unBalance plugin)? If so that is nice (and deprecates the plugin)? Does it move files to existing directories on HDDs first (ie fill them) before creating new directories as I prefer to avoid having my files scattered over random HDDs?
March 29, 201610 yr Can you explain how this works (to the user) please? Do you "ask" it to clear a HDD and it moves all files to other HDDs (like the unBalance plugin)? If so that is nice (and deprecates the plugin)? Does it move files to existing directories on HDDs first (ie fill them) before creating new directories as I prefer to avoid having my files scattered over random HDDs? Clearing is needed when adding a new disk to the protected array, it has nothing to do with moving data, difference is that prior to 6.2-beta array had to be offline during this process, this could take many hours with large disks.
March 29, 201610 yr Can you explain how this works (to the user) please? Do you "ask" it to clear a HDD and it moves all files to other HDDs (like the unBalance plugin)? If so that is nice (and deprecates the plugin)? Does it move files to existing directories on HDDs first (ie fill them) before creating new directories as I prefer to avoid having my files scattered over random HDDs? when adding a new disk that isnt preclrear. unraid will clear it out for you but array would stay offline. it seems this is no longer the fact.
March 29, 201610 yr Just found by accident that clearing a disk now does not put array offline, array is available during the process, don't think this was in the release notes. I completely agree that this is a nice new feature, and needs to be mentioned ... BUT it also needs to have a warning with it! There was a very important reason this wasn't done before, and that is that Parity is invalid while clearing is being performed! (Unless the drive has been Precleared of course!) It was always safer the old way, keeping the array offline until the new drive is completely zeroed. When the array is started, parity is assumed to be correct, so if anything happens, the bits of the parity drive can be used with the other drives to rebuild any data drive. As soon as you add a new disk of unknown contents to the array, parity is wrong for every non-zero bit on that drive! And it won't be correct until the last bit is zeroed, cleared. Normally, nothing should happen during the clearing, so the likelihood of a mishap is extremely small. But if anything goes wrong during the clearing, then the array is in a degraded state, with an invalid parity drive. At that point, no drives can be rebuilt. On the other hand, this is not as serious as that sounds, since if the clearing is aborted for any reason, you would simply remove the new drive, then 'trust parity' again, and you should be back where you started, before adding the new drive. If what goes wrong is a *different* drive 'red-balling', then it's vital that you either make sure the clearing proceeds to completion (thereby returning parity to correctness), or you remove the new drive and attempt to get parity trusted (if that's possible in this situation). It's still a nice feature, but I wanted to make sure users understand the ramifications. There's a small risk involved. Edit: I should add that Tom may have already implemented this in a safer way, such that if anything at all goes wrong, the new drive is immediately unassigned.
March 29, 201610 yr Just found by accident that clearing a disk now does not put array offline, array is available during the process, don't think this was in the release notes. I completely agree that this is a nice new feature, and needs to be mentioned ... BUT it also needs to have a warning with it! There was a very important reason this wasn't done before, and that is that Parity is invalid while clearing is being performed! (Unless the drive has been Precleared of course!) It was always safer the old way, keeping the array offline until the new drive is completely zeroed. When the array is started, parity is assumed to be correct, so if anything happens, the bits of the parity drive can be used with the other drives to rebuild any data drive. As soon as you add a new disk of unknown contents to the array, parity is wrong for every non-zero bit on that drive! And it won't be correct until the last bit is zeroed, cleared. Normally, nothing should happen during the clearing, so the likelihood of a mishap is extremely small. But if anything goes wrong during the clearing, then the array is in a degraded state, with an invalid parity drive. At that point, no drives can be rebuilt. On the other hand, this is not as serious as that sounds, since if the clearing is aborted for any reason, you would simply remove the new drive, then 'trust parity' again, and you should be back where you started, before adding the new drive. If what goes wrong is a *different* drive 'red-balling', then it's vital that you either make sure the clearing proceeds to completion (thereby returning parity to correctness), or you remove the new drive and attempt to get parity trusted (if that's possible in this situation). It's still a nice feature, but I wanted to make sure users understand the ramifications. There's a small risk involved. Edit: I should add that Tom may have already implemented this in a safer way, such that if anything at all goes wrong, the new drive is immediately unassigned. Lol, I believe this feature is in 6.1.9 as well as a few earlier versions. The way it works (I'll let Tom clarify the technical details) is that the disk isn't truly added to the array until AFTER the clearing process is complete. This eliminates all the concerns brought up.
March 29, 201610 yr Possible to add, clear and format disk larger than parity... WOW, is my first reaction because the excess will be unprotected with no indication of a problem on that page! And then there is a second reaction---What happens when you have to replace one of the parity disks???
March 29, 201610 yr Just found by accident that clearing a disk now does not put array offline, array is available during the process, don't think this was in the release notes. I completely agree that this is a nice new feature, and needs to be mentioned ... BUT it also needs to have a warning with it! There was a very important reason this wasn't done before, and that is that Parity is invalid while clearing is being performed! (Unless the drive has been Precleared of course!) It was always safer the old way, keeping the array offline until the new drive is completely zeroed. ...[snipped]... Edit: I should add that Tom may have already implemented this in a safer way, such that if anything at all goes wrong, the new drive is immediately unassigned. Lol, I believe this feature is in 6.1.9 as well as a few earlier versions. The way it works (I'll let Tom clarify the technical details) is that the disk isn't truly added to the array until AFTER the clearing process is complete. This eliminates all the concerns brought up. Thank you jonp, that's perfect!
March 29, 201610 yr Please excuse what may be an annoying question, redundant, but I can't remember if I or another asked if you had exhaustively tested the RAM? I'm thinking something like 24 hours of Memtest. Although there have been reports of issues with certain USB 3.0 drivers, what I see above looks too low level to be USB related. Looks more like RAM or timers or CPU or VM/driver race condition or the like. Edit: It would be interesting to know if anyone else has the same motherboard and BIOS and CPU etc, and what issues they are having? Thanks for the reply Rob. I have done some 24/7 mem tests with no issues. I haven't done one recently though, worth another set of runs do we think? Edit: I have started a memtest so let's see what that does Let's try this: Reboot the system so you're at a clean boot. Without the array started yet, login via SSH or Telnet. Type the following command: killall /usr/sbin/irqbalance After this is done, start the array and begin using the system like normal. Report back if you still have issues afterwards.
March 29, 201610 yr Hi, this beta is working fine now. Updating from 6.1.9 to beta 18 somehow messed up my SSH keys (which was why I could not connect to my server through SSH for the last few beta builds). Deleting the /config/ssh folder on my boot drive fixed the issue, though. One request: Please add a german keyboard option to the VNC section there is no remote keyboard layout that enables me to properly type my passwords, paths, etc. over VNC. (german switzerland is not at all similar to german standard layouts). An additional option to select other keyboard layouts for the GUI/default boot modes would be AWESOME! Thanks for reporting this. I believe you can manually edit the XML for now to resolve this, but we will add this option to the VNC keyboard selector drop-down. The manual XML edit required would be to this area: <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0' keymap='de'> <listen type='address' address='0.0.0.0'/> </graphics> The bolded part is what I changed. Instead of "de-ch" I used just "de". Let me know if that works for you.
March 29, 201610 yr Another thing I noted: If my Windows 10 VM is in 3.0 USB mode, my 3.0 drives work flawlessly on my passed-through PCIe controller. My 2.0 flash drive is no detected, however. Is this expected behavior, or should I post diagnostics? The virtual USB controllers are hit and miss when it comes to device support. Some devices will work fine with both controllers, others only work fine with the 3.0 controller whereas yet others still may only work with the 2.0 controller. If you want to help get support for your 2.0 flash device, your best bet would be to e-mail the QEMU mailing list with the details. In the meantime, if the 2.0 flash device is required, you'll need to go back to passing through the entire PCIe controller.
March 29, 201610 yr Docker updates worked perfectly but now I am having some issues getting my Win10 VM updated. I went into the VM tab and attempted to "edit" the VM (Win10ProIsolCPUs) so that it would update to the new settings. I may have done something wrong during that process because now the VM wont start and their are errors displayed on the VM tab. See screen capture. I have copies of my old XML file and copies of the Win10 disk image. Should I attempt to fix this current "edit" or would it be better to use a template and import the existing Win10 disk image and then make changes to the generated XML if needed? edit I went into terminal and Virsh to see if I could start the VM from there. It reported that the VM started and when I turned on my TV the VM was being passed through Audio and Video as well as USB controller and attached devices. See screen shots. The VM tab is still showing errors and the dashboard is no longer showing my working Dockers or VM's Diagnostics attached Couldn't add the diagnostics file to the previous post so here it is Jude, Please try booting into safe mode and report back if the errors persist.
March 29, 201610 yr Docker updates worked perfectly but now I am having some issues getting my Win10 VM updated. I went into the VM tab and attempted to "edit" the VM (Win10ProIsolCPUs) so that it would update to the new settings. I may have done something wrong during that process because now the VM wont start and their are errors displayed on the VM tab. See screen capture. I have copies of my old XML file and copies of the Win10 disk image. Should I attempt to fix this current "edit" or would it be better to use a template and import the existing Win10 disk image and then make changes to the generated XML if needed? edit I went into terminal and Virsh to see if I could start the VM from there. It reported that the VM started and when I turned on my TV the VM was being passed through Audio and Video as well as USB controller and attached devices. See screen shots. The VM tab is still showing errors and the dashboard is no longer showing my working Dockers or VM's Diagnostics attached Couldn't add the diagnostics file to the previous post so here it is Jude, Please try booting into safe mode and report back if the errors persist. Restarted in Safe mode same errors showing on VM tab page (see screen cap) Clicking on the Windows icon brings up the menu but it will not start the VM. Using the Virsh utility I was not able to start the VM root@Tower:~# virsh Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # start Win10ProIsolCPUs error: Failed to start domain Win10ProIsolCPUs error: internal error: process exited while connecting to monitor: 2016-03-29T16:49:35.257351Z qemu-system-x86_64: -device vfio-pci,host=08:00.0,id=hostdev3,bus=pci.2,addr=0x7: vfio: error, group 13 is not viable, please ensure all devices within the iommu_group are bound to their vfio bus driver. 2016-03-29T16:49:35.257415Z qemu-system-x86_64: -device vfio-pci,host=08:00.0,id=hostdev3,bus=pci.2,addr=0x7: vfio: failed to get group 13 2016-03-29T16:49:35.257439Z qemu-system-x86_64: -device vfio-pci,host=08:00.0,id=hostdev3,bus=pci.2,addr=0x7: Device initialization failed virsh # XML <domain type='kvm' id='1'> <name>Win10ProIsolCPUs</name> <uuid>0c2749f8-96cd-1238-0965-6f9d33c9758f</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>5</vcpu> <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='3'/> <vcpupin vcpu='2' cpuset='4'/> <vcpupin vcpu='3' cpuset='5'/> <vcpupin vcpu='4' cpuset='6'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-q35-2.3'>hvm</type> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor id='none'/> </hyperv> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='5' threads='1'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/disk/vmdisk/Win10Pro/vdisk1.img'/> <backingStore/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISO Library Share/Windows.iso'/> <backingStore/> <target dev='hda' bus='sata'/> <readonly/> <boot order='2'/> <alias name='sata0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/VirtIO Drivers/virtio-win-0.1.109.iso'/> <backingStore/> <target dev='hdb' bus='sata'/> <readonly/> <alias name='sata0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='nec-xhci'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <controller type='sata' index='0'> <alias name='ide'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'> <alias name='pcie.0'/> </controller> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <model name='i82801b11-bridge'/> <alias name='pci.1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='2'/> <alias name='pci.2'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:69:22:69'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/1'/> <target port='0'/> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/1'> <source path='/dev/pts/1'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-Win10ProIsolCPUs/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <hostdev mode='subsystem' type='pci' managed='yes' xvga='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </source> <alias name='hostdev2'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x08' slot='0x00' function='0x0'/> </source> <alias name='hostdev3'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x07' function='0x0'/> </hostdev> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x08' function='0x0'/> </memballoon> </devices> </domain> Diagnostics attached Edit Booted up again in normal mode. Errors still on VM tab but able to use the Windows icon menu to start the VM tower-diagnostics-20160329-1152.zip
March 29, 201610 yr Please excuse what may be an annoying question, redundant, but I can't remember if I or another asked if you had exhaustively tested the RAM? I'm thinking something like 24 hours of Memtest. Although there have been reports of issues with certain USB 3.0 drivers, what I see above looks too low level to be USB related. Looks more like RAM or timers or CPU or VM/driver race condition or the like. Edit: It would be interesting to know if anyone else has the same motherboard and BIOS and CPU etc, and what issues they are having? Thanks for the reply Rob. I have done some 24/7 mem tests with no issues. I haven't done one recently though, worth another set of runs do we think? Edit: I have started a memtest so let's see what that does Let's try this: Reboot the system so you're at a clean boot. Without the array started yet, login via SSH or Telnet. Type the following command: killall /usr/sbin/irqbalance After this is done, start the array and begin using the system like normal. Report back if you still have issues afterwards. Thanks jonp Well my system passed 20 hours of the memtest so i don't think it is a memory issue. I have just tried this, and will report back As a note, i disabled autostart of my array to run this properly, ran the command as asked, and i have not had a single hardware error reported in my logs. I usually have at least 1 or 2 by the time the array has auto started There is 1 more thing i thought of which may cause trouble. My NVMe drive was formatted as XFS before i put it into unraid and it was never reformatted so it is using my old format. It picks up as XFS correctly, obviously this is mounted as my cache drive and has my vms and that on it. As its NVMe im wondering if this could cause system lockups if the drive were to crash since it is a direct pci-e device Just one to throw out there
March 29, 201610 yr Possible to add, clear and format disk larger than parity... What happens if you fail the array by pulling 2 of the smaller disks? Or pull the larger disk and one small one? Does the array still start degraded?
Archived
This topic is now archived and is closed to further replies.