December 15, 20178 yr Upgrading: We have changed the way one checks for new unRAID OS releases. Please refer to Update OS below. Bugs: If you want to report an issue, please start a new topic in this board. Notable changes (-rc16b): Linux kernel 4.14.4 (with "Revert - Remove UDP Fragmentation Offload support" patch). This is an "experimental" patch that is meant to solve VM issues introduced after moving to 4.14 kernel. Please report if this works for you. Early microcode loading support. Addition of background threads that auto-update local IP address with LimeTech DNS server when using Let's Encrypt SSL certs, and that auto-renew these certs if within 30 days of expiration. Misc. bug fixes. Notable changes (-rc15e): Linux kernel 4.14.4. This is a "longterm maintenance" kernel, which is nice. There is now a Logout button for the webGUI which appears on right side of the menu bar when you have defined a root password and are logged in. Clicking this will "log you out" from all tabs/windows in that browser. Misc. bug fixes. Notable changes (-rc14): Fix "swap/disable" operation. Restore proper interpretation of SAS device temperature. Prevent mover from running when no cache volume present, or only the cache volume is present. Notable changes (-rc13): Correct handling of SMART ID 190. Replaced 'tabs' for 'spaces' in the make_bootable.bat file (Windows doesn't like tabs). Notable changes (-rc12a): None, just bug fixes, well updated linux kernel minor patch release Notable changes (-rc11i): Let's Encrypt SSL certificate renewal: if your certificate is within 30 days of expiration the Renew button on Settings/Identification/SSLCertificate Settings page will be enabled. LE certs have a lifetime of 90 days but it's free to renew. We are working on a configurable daemon to make this automatic. All encryption passphrase/keyfile handling is managed on the Main page. For now the Encryption Settings page is gone but will eventually return as a way of changing the default cipher settings. Also gone is the Restricted Start setting introduced in the last release (bad idea). Yet another attempt to reliably report NVMe temperatures. Notable changes (-rc10b): Finally looks like the AMD Ryzen GPU pass-through performance issue has been solved. We applied this patch and it does indeed appear to solve the problem. Fixed issue in the 'mover' where it wasn't handling split-levels correctly in moving files from cache to array. Further refinements in handling encryption keyfile. Added new config setting Settings/Disk Settings/Restricted Start [Yes/No]. When set to Yes, array will not Start if there are encrypted volumes and the encryption key is missing (this is the default). If set to No and encryption key is missing, array will Start but encrypted volumes will not be Mounted and also cannot be Formatted - any share data stored therein simply won't be available. After attempted array Start with missing/wrong keyfile, you can enter the passphrase/upload keyfile directly from Main page. If there are any encrypted volumes in your server, we recommend setting "Settings/Disk Settings/Enable auto start" to Yes. Following boot of course there will be no keyfile present so autostart will fail. But in this case s/w also now knows there are encrypted devices and you will see right on the Main page a place to enter the encryption passphrase or upload a keyfile. Numerous package updates, bug fixes and webGui enhancements. Notable changes (-rc9f): Improved handling of encryption passphrase/keyfile. When Starting array with encrypted volumes, you only need to enter the encryption passphrase once on the Encryption Settings page - no more confusing "passphrase confirmation". If no encrypted devices exist and you're trying to add some, then it will ask for passphrase confirmation. Introduce new Disk Setting called 'Restricted Start - Yes/No'. When set to 'Yes' then array will not Start if the encryption key is missing. If set to 'No' then array will Start (including autostart) but encrypted volumes will not be 'mounted', meaning shares and/or share data stored on them will not be accessible. The default (and normal) setting for this is 'Yes'. The Let's Encrypt SSL provisioning is only available when 'Use SSL/TLS' on Identification page is set to 'Auto'. Also, provisioning the cert no longer triggers complete restart of "services". If using 'https' all 'http' is redirected to 'https'. If not using 'https', all 'https' is redirected to 'http'. The result of this is you can always enter servername in browser address bar to get to webGui, for example "Tower/" or "Tower.local" should always get you to the webGui. In the case of SSL-enabled LE certificate, you will get redirected to the <hash>.unraid.net URL. Added an 'Update DNS' button on Identification page. If the IP address of your server changes and you're usng the LE certificate, you can click this button to tell unraid.net to update the DNS setting. We have set TTL to 60 seconds so it might take this long to see the update. Of course you have to already have the webGui open to do this. Finally fixed reporting of temperature for NVMe devices (hopefully). Updated OVMF firmware, tested with various OS types, seems to work. Other misc. fixes an improvements, refer to Changes below. We're at the end of life for linux kernel 4.12. Next release will move to 4.13 kernel. Secure Access (-rc8q): Probably some explanation is in order. The “major” feature we wanted to add into unRAID version 6.4 was block level device encryption. However to get there we realized there needs to exist a secure way of entering information such as passphrases. Hence phase 1 consisted of integrating nginx in order to leverage its support of SSL/TLS (https). Besides the benefit of https support, integration of nginx also lets us utilize websocket technology (which is an ongoing integration), and lets us greatly improve the overall responsiveness of the webGui. Phase 1 integration of nginx in unRAID only supports self-signed SSL certificates. While in general, this may be OK to provide encrypted connections between a browser and a server in a trusted LAN, relying on self-signed certs is not good practice and is theoretically vulnerable to MITM attacks. With this release we have completed Phase 2 of nginx https integration by providing the ability for our users to provision a free SSL Certficate from Let’s Encrypt. To obtain your certificate go to Settings/Identification, scroll to the bottom and click Provision. In one operation this will allocate your certificate, upload it to your server, and switch nginx to redirect all http to https. After clicking anywhere else in the webGui you should see a nice green lock icon in your browser address bar! The other thing you’ll notice in your address bar is a very funny looking URL consisting of a 40-hex-character subdomain of unraid.net. We have set up a LimeTech DNS server that will resolve that URL to your servers IP address on your local network. That FQDN is unique to your certificate. When your browser resolves that URL it is given your local IP address which it then uses to perform the https connection handshake. For this reason, we recommend that you give your server a static IP address because if the IP address changes, the browser will not be able to connect to your server. This is like locking your keys in the car! We plan on implementing a small daemon which wakes up upon such IP address change and tells the LimeTech DNS server to update its A-record, but this has not been done yet. NOTE: if you do lock your keys in the car, the coat-hanger fix to restore http access is to telnet/ssh into the server and type: rm /boot/config/ssl/certs/certificate_bundle.pem /etc/rc.d/rc.nginx reload (You might also have to clear your browser cache.) Following re-enable of http, you can again Provision a certificate which will update the DNS entry. Device block level encryption (-rc8q): We have implemented full-device encryption as follows. In unRAID, encryption is selected as another type of file system. For example, with array Stopped, click on a Device link and then click on File system type. Three new “types” are available: xfs – encrypted btrfs – encrypted reiserfs – encrypted [should we get rid of this one?] If you change the File system type to one of these and then Start the array you will notice the device appears Unmountable and the Format button is available. Formatting the device will result in creating an encrypted partition on that device with the specified file system type. ALL PREVIOUS DATA ON THAT DEVICE WILL BE DESTROYED. Hence it is not possible, in this release, to encrypt in-place. We plan to add a utility in a future release to accomplish this however. The other thing you’ll notice when you click Format is that it may fail because there is no encryption key. In this case, click on Settings/Encryption Settings and enter in a passphrase to be used to secure your encrypted devices. At present we let you enter either a passphrase or upload a file which contains your passphrase (or binary data). DO NOT FORGET YOUR PASSPHRASE OR LOSE YOUR KEYFILE. Once a partition is encrypted, if you forget your passphrase or lose your keyfile, your data is forever lost - unless you know someone very high up in the NSA Also note that array Autostart following server boot will not succeed if any devices are encrypted. This is because the keyfile (passphrase) is kept in RAM and thus lost upon reboot. This means that following system reboot you must log into the webGui, go to Tools/Encryption and enter your passphrase (or upload your keyfile). Yes this is a nuisance and we have a few ideas for automating this, but at least you now have secure https access! In the case of a btrfs cache pool, all devices comprising the pool will be encrypted. For this release, we highly recommend using encryption only on a test server with test data which has been backed up. We plan on many more refinements in future releases. 4Kn Device Support (-rc8q): Yeah should work now. Other notes (-rc8q): The /usr/local/sbin/emhttp line in your /boot/config/go file is no longer used to specify the ports where the webGui listens for connections. Instead you must configure these on the Identification page. Alternately if you need to set this up prior to server boot, you may add the port settings in /boot/config/ident.cfg. Please refer to /usr/local/sbin/emhttp script for more information if you care about this. It used to be that merely Starting the array would re-write a “unRAID standard partition layout”. This surprises some users because one would expect nothing to be written to a new device unless Format was invoked. This has been changed so that nothing is written to a device unless Format is invoked (except for Parity devices – those will still be written upon array Start if parity sync is indicated). Moving devices around between cache pool and array or unassigned is handled much better now. There are numerous webGui fixes and improvements. Upgraded linux kernel and several base packages. Where are releases -rc8a-rc8p you might ask? Those were non-public test releases. Credits (-rc8q): Thanks to @jonp for his work in securing us a Certifiate Authority (Let's Encrypt). Thanks to @eschultz for an incredible amount of work involved in setting up DNS servers and integrating with Let's Encrypt API, among other vital tasks in this release. Thanks to @bonienl for his continued dynamix amazing refinements and networking/IPv6 expertise. USB Flash boot device backup function (-rc7) Added "Flash backup" button on the flash device info page (Main/flash). Click this button to download a zip file with the entire contents of your USB Flash boot device. This zip file may be used to restore to a new unRAID USB Flash boot device either manually, or using our nifty new unRAID USB Creator tool. Linux 4.12 kernel (-rc7) - should provide better Ryzen support among other improvements. UEFI support (-rc5) It is now possible configure UEFI boot mode to boot unRAID OS. The make_bootable.bat (Windows), make_bootable_mac (MacOS) and make_bootable_linux (Linux) scripts will output a prompt: Permit UEFI boot mode [Y/N]: If answered with 'Y' a new directory is included on the USB flash boot device called 'EFI'. The presence of this directory along with its contents, and along with some additional linux kernel options permit UEFI boot. This is done in such a way that you could choose either BIOS (legacy) or UEFI to boot off your USB flash device (that is, even if you answer 'Y' here you can still configure your motherboard to use Legacy boot). If answered with 'N' the directory and contents are still created, but named 'EFI-' (a dash at the end). This will prevent UEFI firmware from considering this device. You can manually rename the 'EFI-' directory to 'EFI' and permit possible UEFI boot (and rename back to 'EFI-' to prevent it again). Note: Even if the 'EFI' directory exists, whether or not your motherboard actually uses UEFI to boot is determined by BIOS settings. In addition, some motherboards may present a strongly worded warning along the lines of "The system found unauthorized changes on the firmware, operating system or UEFI drivers." In this case look for a "Secure Boot" BIOS setting and change to "Other OS" or "Disable". If you update your server using Check for updates on the Plugin page, an 'EFI-' directory and files will be automatically created on your USB flash boot device. If you prepare a new USB flash using this release, the 'EFI-' directory and files will also be included. If you use the "manual" method of updating by copying the bz* files from the release zip, beware you will need to manually also copy over the 'EFI-' directory (and modify the first line of syslinux.cfg and copy it to 'EFI-/boot' directory). There is also a webGui setting to permit UEFI boot located on the 'flash' device information page in the 'Syslinux Configuration' section. Update OS (-rc5) Instead of bundling an "unRAID Server" plugin on the Plugins page, there is a new page on the Tools menu in the About section called 'Update OS'. Here you can check for a new unRAID OS release as well as switch between the latest release in the stable branch or the next branch. In addition there is a separate control on the Notification Settings page that configures whether or not to automatically check for updates. enabling https (-rc3) To enable https support it's necessary to edit your 'config/go' file on your USB flash boot device. Use the -p option to specify the port(s) and optionally include the -r option to redirect http request from your browser to using https. Here's the detailed usage: # Usage: # emhttp [-r] [-p port [,sslport]] [OPER] # OPER is start or stop. Default is start. # By default nginx will be setup to listen only at port 80 (http). # The -p option may be used to define different listening ports and/or setup nginx # to listen at a specified port for https. The -r option may be used to setup # nginx so that any http request is redirected to https (this requires that both # ports have been specified with -p option). For example, to have nginx listen # at both standard ports but redirect all http to https use: # emhttp -rp 80,443 # To listen at only port 443 use: # emhttp -p ,443 # Note: the stop operation is only "safe" if the array has already been stopped # (this will be fixed). Improved shfs/mover (-rc1) The LimeTech user share file system (shfs) has been improved in two areas. First, we now make use of FUSE read_buf/write_buf methods. This should result in significant throughput increases. Second, the mover script/move program no longer uses rsync to move files/directories between the cache pool and the parity array. Instead the move program invokes a new shfs ioctl() call. This should result in complete preservation of all metadata including atime and mtime. While this function has been fairly extensively tested, please keep an eye on mover activities - there shouldn't be any data loss, but it's a fairly significant code change. nginx http server (-rc1) We now use the nginx webserver as the front-end to the unRAID OS Management Utility (aka, webGui). The emhttp process has been changed to a daemon (emhttpd) listening at a unix socket. Incorporating nginx provides several features: Multi-threaded access, though emhttpd is still single-threaded. https (SSL) support. At present unRAID OS will generate a self-signed certificate. https works but you will get a scary warning from your browser about not being able to verify the certificate. No worries. nchan (websocket) support. We have only just begun the process of converting many of the browser javascript polling functions to an event-driven websocket paradigm. This opens the door for us to create something like a process manager where we can have several background operations in process, all monitored in real-time via webGui dashboard. IPv6 support (-rc1) We want to again, give a big "thank you" to bonienl who has greatly improved unRAID OS networking with the addition of IPv6 support. Give it a try and report any issues. Other (-rc1) Two new webGUI themes: Azure and Gray. Again, thanks to bonienl. Expanded driver support (QLogic) and more hardware monitoring support. Kernel modules and firmware are left on the Flash in a squashfs loopback and loaded into RAM on demand. Many more misc. improvements Version 6.4.0_rc16b 2017-12-15 Changes Base distro: php: version 7.1.12 (CVE-2016-1283) samba: version 4.6.11 (CVE-2017-14746, CVE-2017-15275) openssl: version 1.0.2n (CVE-2017-3736, CVE-2017-3737, CVE-2017-3738) curl: version 7.57.0 (CVE-2017-8818, CVE-2017-8817, CVE-2017-8816) Linux kernel: apply "Revert - Remove UDP Fragmentation Offload support" patch (https://www.mail-archive.com/[email protected]/msg204727.html) added "early loading" of microcode, primarily this is relevant to Intel additional modules: CONFIG_MICROCODE: CPU microcode loading support CONFIG_MICROCODE_INTEL: Intel microcode loading support CONFIG_MICROCODE_AMD: AMD microcode loading support CONFIG_IPMI_SSIF: IPMI SMBus handler (SSIF) CONFIG_IPMI_PANIC_EVENT: Generate a panic event to all BMCs on a panic CONFIG_IPMI_PANIC_STRING: Generate OEM events containing the panic string CONFIG_TEHUTI: Tehuti Networks 10G Ethernet Management: added updatedns and renewcert daemons fixed unclean shutdown flag sometimes being erroneously set move SSL provisioning and DNS update execute from client-side to server-side webgui: Do not send csrf token with crossdomain requests webgui: Allow special characters in host paths webgui: auto collapse text labels from right menu bar when space is scarce webgui: Display message if docker service fails to start webgui: Support IPv6 anycast addresses in routing table webgui: Diagnostics updates: Human readable free memory Full ps output with children, sorted by CPU usage webgui: Updated bond mode help text webgui: Updated SSL certificate handling help text
December 16, 20178 yr Updated backup server to rc16b without issue so far. I don''t run VMs on the backup/test server so I cannot comment on the fix. My production server remains on 6.3.5. Of course, I still have the problem of console output disappearing over IMPI as expected. This appears to be a 4.14.4 kernel issue which I have reported to ASRock as an FYI for them.
December 16, 20178 yr Neither of my servers are getting an ipv6 address. I have network settings set for ipv4 and ipv6 to get addresses automatically. backupserver-diagnostics-20171215-2032.zip EDIT: More information: Output of ifconfig: bond0: flags=5443<UP,BROADCAST,RUNNING,PROMISC,MASTER,MULTICAST> mtu 1500 inet6 fe80::be5f:f4ff:febe:7ee6 prefixlen 64 scopeid 0x20<link> ether bc:5f:f4:be:7e:e6 txqueuelen 1000 (Ethernet) RX packets 2031929 bytes 2540513273 (2.3 GiB) RX errors 0 dropped 77 overruns 0 frame 0 TX packets 2988 bytes 2963817 (2.8 MiB) TX errors 0 dropped 6 overruns 0 carrier 0 collisions 0 br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.4 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 2605:a000:1317:802a:be5f:f4ff:febe:7ee6 prefixlen 64 scopeid 0x0<global> inet6 fe80::2cd4:82ff:fe8a:eec3 prefixlen 64 scopeid 0x20<link> ether bc:5f:f4:be:7e:e6 txqueuelen 1000 (Ethernet) RX packets 7866 bytes 1276852 (1.2 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1724 bytes 2893929 (2.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Network gui on unRAID: It does look like unRAID has an ipv6 address, it's just not reporting it. Edited December 16, 20178 yr by dlandon
December 16, 20178 yr updated without issue. running a vm now with light video work. has been going for an hour and the super high emulator pin usage/vm stalls have not occurred yet.
December 16, 20178 yr 4 hours ago, limetech said: added "early loading" of microcode, primarily this is relevant to Intel additional modules: CONFIG_MICROCODE: CPU microcode loading support CONFIG_MICROCODE_INTEL: Intel microcode loading support CONFIG_MICROCODE_AMD: AMD microcode loading support Thanks! Can you describe more about the early microcode loading support? Based on my research, we need these two slack packages too: https://slackbuilds.org/repository/14.2/system/iucode_tool/ https://slackbuilds.org/repository/14.2/system/intel-microcode/ but it doesn't look like they are included in 16b? The intel-microcode package adds files to /lib/firmware, but since that is a read-only loopback image it isn't something we can do as users. Also, I'm a little confused about what kernal options are needed. The docs for iucode_tool say we need: CONFIG_MICROCODE=y CONFIG_MICROCODE_EARLY=y CONFIG_MICROCODE_INTEL_EARLY=y which is slightly different than what you've documented?
December 16, 20178 yr Author 1 hour ago, ljm42 said: Thanks! Can you describe more about the early microcode loading support? Based on my research, we need these two slack packages too: https://slackbuilds.org/repository/14.2/system/iucode_tool/ https://slackbuilds.org/repository/14.2/system/intel-microcode/ but it doesn't look like they are included in 16b? The intel-microcode package adds files to /lib/firmware, but since that is a read-only loopback image it isn't something we can do as users. Also, I'm a little confused about what kernal options are needed. The docs for iucode_tool say we need: CONFIG_MICROCODE=y CONFIG_MICROCODE_EARLY=y CONFIG_MICROCODE_INTEL_EARLY=y which is slightly different than what you've documented? CONFIG_MICROCODE_EARLY is no longer defined in the kernel, at least it's not in 4.14. We employ "Early load microcode" method as described here: https://www.kernel.org/doc/Documentation/x86/early-microcode.txt That doc is not so clear, there are others that describe the process better. In unRAID we tack on the uncompressed microcode cpio archive in front of 'bzroot'. This ends up in these directories: /kernel/x87/microcode/GenuineIntel.bin /kernel/x86/microcode/AuthenticAMD.bin In this release we left those dirs there but in next release we will delete it in /etc/rc.d/rc.local in order to free up 1.5M it consumes. The early microcode update feature automatically determines if there is a microcode update for your CPU and applies it and you don't need those user-space tools. Look for "microcode" in your system log to see if an update was applied. For example, on a test server here with an I5-4430 processor this is the first line in syslog (ie, from dmesg): kernel: microcode: microcode updated early to revision 0x22, date = 2017-01-27
December 16, 20178 yr Still same issues as rc15 for me. My windows 10 VMs do not shut down 100%, I end up with a blue screen saying "shutting down" and the circle doesn't spin. Because this VM is essentially frozen, the webui cannot load VM tab. Just hangs, everything else works though... Only way to get this going again is to hold power button down to do a hard reset. Stopping the array, disabling VM manager, shutting down or restarting via the UI are unable to fix it either. They all simply wait for the VM to shut down 100% before executing the rest of the procedure. Due to the vm not shutting down though, you get stuck here.
December 16, 20178 yr Will we finally see NFS v4 implemented in these RC's? and docker 17.09.1-ce updated before final release?
December 16, 20178 yr Author 19 minutes ago, marshy919 said: Still same issues as rc15 for me. My windows 10 VMs do not shut down 100%, I end up with a blue screen saying "shutting down" and the circle doesn't spin. Because this VM is essentially frozen, the webui cannot load VM tab. Just hangs, everything else works though... Only way to get this going again is to hold power button down to do a hard reset. Stopping the array, disabling VM manager, shutting down or restarting via the UI are unable to fix it either. They all simply wait for the VM to shut down 100% before executing the rest of the procedure. Due to the vm not shutting down though, you get stuck here. Please capture and post diagnostics while in this 'stuck' state.
December 16, 20178 yr 44 minutes ago, limetech said: The early microcode update feature automatically determines if there is a microcode update for your CPU and applies it and you don't need those user-space tools. Look for "microcode" in your system log to see if an update was applied. For example, on a test server here with an I5-4430 processor this is the first line in syslog (ie, from dmesg): Nice! I upgraded my main system and the very first line of the syslog references a microcode update, plus there are a few more lines later on: Dec 15 21:51:37 Tower kernel: microcode: microcode updated early to revision 0x22, date = 2017-01-27 Dec 15 21:51:37 Tower kernel: Linux version 4.14.4-unRAID (root@develop64) (gcc version 7.2.0 (GCC)) #1 SMP PREEMPT Wed Dec 13 12:42:33 PST 2017 ... Dec 15 21:51:37 Tower kernel: microcode: sig=0x306c3, pf=0x2, revision=0x22 Dec 15 21:51:37 Tower kernel: microcode: Microcode Update Driver: v2.2. similarly: Linux 4.14.4-unRAID. root@Tower:~# dmesg | grep "microcode" [ 0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27 [ 7.191994] microcode: sig=0x306c3, pf=0x2, revision=0x22 [ 7.192533] microcode: Microcode Update Driver: v2.2. root@Tower:~# For comparison, the syslog for a VM (which cannot modify microcode) starts directly here and has no references to microcode at all: Dec 15 21:57:25 TowerVM kernel: Linux version 4.14.4-unRAID (root@develop64) (gcc version 7.2.0 (GCC)) #1 SMP PREEMPT Wed Dec 13 12:42:33 PST 2017 Neither does dmesg: Linux 4.14.4-unRAID. root@TowerVM:~# dmesg | grep "microcode" root@TowerVM:~# Thanks for doing this, I almost can't believe that it is fully automatic. I was expecting it to be much more difficult to implement As a minor follow-on, could we modify the Tools -> System Log viewer to highlight lines with "microcode" in blue? maybe I should tag @bonienl
December 16, 20178 yr 1 hour ago, limetech said: The early microcode update feature automatically determines if there is a microcode update for your CPU and applies it and you don't need those user-space tools. Look for "microcode" in your system log to see if an update was applied. For example, on a test server here with an I5-4430 processor this is the first line in syslog (ie, from dmesg): kernel: microcode: microcode updated early to revision 0x22, date = 2017-01-27 This exact line appears in the syslog after updating to rc16b; however, according to the Intel web site, the latest microcode for the i5-4590 running in my backup server is dated 2017 -11-17. How does the update feature determine if there is an available microcode update and where does it pull it from? The prior microcode was dated 2017-07-07 (fix for the hyperthreading issue). Going strictly by the dates (revisions seems to be named with the date), it appears that the latest microcode is not being applied. BTW, I assume the "x87" directory in your Intel microcode path is really "x86" correct? Edited December 16, 20178 yr by Hoopster
December 16, 20178 yr 54 minutes ago, limetech said: Please capture and post diagnostics while in this 'stuck' state. Attached mate. Both "gaming" and "win10" VM have the same issue. I created gaming VM just 20 minutes ago to see if that'll help. tower-diagnostics-20171216-1653.zip Edit: force stoping the VM works fine, actually shutting it down from within windows causes issues. I can still use every page of the webui besides the VM page during this time until a full reset is done. Edit: another VM crash (this happened on the previous RC too doing the exact same thing) when installing Nvidia driver for GTX1070. Another attached diagnostics. This also crashes the webui for VM. tower-diagnostics-20171216-1731.zip Edited December 16, 20178 yr by marshy919
December 16, 20178 yr Author 20 minutes ago, Hoopster said: This exact line appears in the syslog after updating to rc16b; however, according to the Intel web site, the latest microcode for the i5-4590 running in my backup server is dated 2017 -11-17. How does the update feature determine if there is an available microcode update and where does it pull it from? The prior microcode was dated 2017-07-07 (fix for the hyperthreading issue). Going strictly by the dates, it appears that the latest microcode is not being applied. We downloaded "microcode-20171117.tgz" from here: https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File This file contains all the microcode for all Intel CPUs which can have their microcode updated. When they say the latest microcode for a given CPU has a certain date, I believe they are referring to the release of the microcode file itself, and not necessarily that that CPU has an update. Make sense?
December 16, 20178 yr Author 55 minutes ago, marshy919 said: Attached mate. Both "gaming" and "win10" VM have the same issue. I created gaming VM just 20 minutes ago to see if that'll help. tower-diagnostics-20171216-1653.zip Thanks for the diags. Do you have any custom edits to the vm xml files? Also, the libvirt log is complaining about some errors - not sure what they mean
December 16, 20178 yr 2 hours ago, limetech said: Thanks for the diags. Do you have any custom edits to the vm xml files? Also, the libvirt log is complaining about some errors - not sure what they mean I just edited my syslinux to not isolate any cores. Then I changed my VM to only use the last 4 cores of my CPU. Currently trying to get Nvidia driver installed without PC freezing. edit: still crashing installing driver from nvidia experience Only edit to VM config is the source file for vbios. <rom file='/mnt/user/system/vbios/GP104.rom'/> Thought it may have to do with the GPU. Edited the VM to disable the GPU and use VNC to view it. Still freezes UI when shutting down. As for the weird errors in libvrt, I saw this post by Squid. Took all PCI devices out to see if it could be an issue with a GPU or USB controller. Shutting down PC manually via Win10 or installing Nvidia driver still causes same error on UI. Edit: uninstalled drivers with ddu, which triggered them to download from windows update. they were unable to install (would still freeze the PC up). rebooted (held power) the server into safe mode, rebooted again (fresh reboot for once), back into safe mode. back to windows update and the drivers installed this time turned off the vm without it crashing the UI either. see 2032 diagnostics for me in safe mode with it all working. so safe mode works... tower-diagnostics-20171216-1904.zip tower-diagnostics-20171216-2032.zip Edited December 16, 20178 yr by marshy919
December 16, 20178 yr 55 minutes ago, limetech said: This file contains all the microcode for all Intel CPUs which can have their microcode updated. When they say the latest microcode for a given CPU has a certain date, I believe they are referring to the release of the microcode file itself, and not necessarily that that CPU has an update. Make sense? Yep, makes sense. It could be that the latest microcode update available for the i5 4590 is the 2017-01-27 microcode and if I updated my main server to rc16b the Skylake Xeon in that server may get a different microcode loaded. If the 20171117 microcode file (the latest) is what was downloaded then I suppose it contains whatever is the latest for each CPU to which an update applies regardless of the actual date on the microcode file.
December 16, 20178 yr 7 hours ago, dlandon said: Neither of my servers are getting an ipv6 address. I have network settings set for ipv4 and ipv6 to get addresses automatically. In this release IPv6 hs its own settings for IP assignment and DNS. You need to re-apply the network settings to let the new settings work properly.
December 16, 20178 yr 46 minutes ago, zin105 said: Good timing! My web server VM completely locked up and made the VM tab never load. Hope this update fixes the problem! This problem started on RC15 and has affected multiple VM's. No custom XML options or anything. See my above post. I had the same issue since rc15, use safe mode for now, its working 100%
December 16, 20178 yr 4 hours ago, bonienl said: In this release IPv6 hs its own settings for IP assignment and DNS. You need to re-apply the network settings to let the new settings work properly. That fixed it. Would have been nice to have this indicated in the release notes. So anyone updating from 6.3 will have this issue. Edited December 16, 20178 yr by dlandon
December 16, 20178 yr 40 minutes ago, dlandon said: That fixed it. Would have been nice to have this indicated in the release notes. So anyone updating from 6.3 will have this issue. Eh no, this issue only appears if you have configured IPv6 in an earlier 6.4 release. People updating from 6.3 will have IPv4 only and need to configure IPv6 if they want to use this. Edited December 16, 20178 yr by bonienl
December 16, 20178 yr 48 minutes ago, bonienl said: Eh no, this issue only appears if you have configured IPv6 in an earlier 6.4 release. People updating from 6.3 will have IPv4 only and need to configure IPv6 if they want to use this. Ah yes. Been on 6.4 so long, I forgot about the ipv6 stuff being added in 6.4.
December 16, 20178 yr A quick successful restart of my Ubuntu VM with Nvidia passthrough on an Asus x370 Prime Pro seems to confirm that the problem with hanging VM's have disappeared. Edit: Unfortunately, my VM once again did not shut down, requiring a server reboot. It had been running for many hours, and the symptoms were the same as before. Edited December 16, 20178 yr by pederm New info
December 16, 20178 yr Early microcode update worked perfectly for me. Thanks. For the VM issue, on 15 I was having the hanging issue, but based on a recommendation on that thread I updated my motherboard firmware (even though it was still fairly old, the most recent was from 2016) and since then I haven't seen the issue. Thanks again
December 16, 20178 yr Did a few hours of moderate-to-heavy video editing work this am using 18 of 20 cores and passing through 2 GPUs and everything seems alright still. Many thanks!
December 16, 20178 yr Just installed, rebooting now, will report any problems. The hanging VM problem had been a PITA since one of my VMs is pfSense with a NIC passed to it for the WAN.
Archived
This topic is now archived and is closed to further replies.