unRAID Server Release 6.2 Stable Release Available


Recommended Posts



Clicking 'Check for Updates' on the Plugins page is the preferred way to upgrade.


Upgrade Notes

  • After upgrading using the plugin, your previous unRAID release version will be stored in the "previous" folder on your USB flash device
  • To undo your upgrade, copy the files from the "previous" folder to the root of your USB flash boot device and reboot your server
  • If you are using plugins, please see this thread regarding plugin support.
  • unRAID 5.x and earlier users should refer to this post for information on upgrading to unRAID 6


unRAID Server Version 6.2 Release Notes


For a complete overview of all the new features, please see this blog post.  Here is a summary:


New Features

  • Dual parity support
  • Increased device limits for Trial and Pro
  • GUI boot mode
  • Auto share creation
  • Prefer cache mode
  • VLAN and multiple Ethernet support
  • 10gbps networking optimizations
  • shfsf/mover hard link and socket support
  • General storage performance improvements
  • Docker: default volume mapping for appdata
  • Docker: simplified controls for basic view
  • Docker: update containers without starting them
  • Virtual Machines: simplified VM storage management
  • Virtual Machines: improved support for OVMF
  • Virtual Machines: hyper-v extension support for Windows guests w/ GPU passthrough
  • Virtual Machines: miscellaneous bug fixes and enhancements for GPU pass through
  • Virtual Machines: assign stubbed PCI devices to VMs
  • Virtual Machines: improved support for assigning USB devices
  • Virtual Machines: improved VNC quality and performance
  • Virtual Machines: download VirtIO drivers directly in webGui


Security Advisory Updates

  • gnupg: version 1.4.21 (CVE-2016-6313)
  • libgcrypt: version 1.7.3 (CVE-2016-6313)
  • curl: version 7.50.1 (CVE-2016-5419, CVE-2016-5420, CVE-2016-5421, CVE-2016-3739)
  • libidn: version 1.33 (CVE-2015-8948, CVE-2016-6261, CVE-2016-6262, CVE-2016-6263)
  • openssh: version 7.3p1 (CVE-2015-8325, CVE-2016-6210)
  • php: version 5.6.24 (CVE-2016-5385, CVE-2016-6207, CVE-2016-5766, CVE-2016-5767, CVE-2016-5768, CVE-2016-5769, CVE-2016-5770, CVE-2016-5771, CVE-2016-5772, CVE-2016-5773, CVE-2016-3074, CVE-2015-8865, CVE-2016-4073, CVE-2016-4072, CVE-2016-4071, CVE-2016-4070, CVE-2013-7456, CVE-2016-5093, CVE-2016-5094, CVE-2016-5096)
  • samba: version 4.4.5 (CVE-2016-2119, CVE-2015-5370, CVE-2016-2110, CVE-2016-2111, CVE-2016-2112, CVE-2016-2113, CVE-2016-2114, CVE-2016-2115, CVE-2016-2118)
  • gd: version 2.2.1 (CVE-2015-8874, CVE-2016-3074)
  • pcre: version 8.39 (CVE-2016-1283)
  • wget: version 1.18 (CVE-2016-4971)
  • gnutls: version 3.4.13 (CVE-2016-4456, CVE-2016-4456)
  • libarchive: version 3.1.2 (CVE-2016-1541)
  • libxml2: version 2.9.4 (CVE-2016-4447, CVE-2016-4448, CVE-2016-4449)
  • ntp: version 4.2.8p8 (CVE-2016-1551, CVE-2016-1549, CVE-2016-2516, CVE-2016-2517, CVE-2016-2518, CVE-2016-2519, CVE-2016-1547, CVE-2016-1548, CVE-2015-7704, CVE-2015-8138, CVE-2016-1550, CVE-2016-4953, CVE-2016-4954, CVE-2016-4955, CVE-2016-4956, CVE-2016-4957)
  • openssl: version 1.0.2h (CVE-2016-2108, CVE-2016-2107, CVE-2016-2105, CVE-2016-2106, CVE-2016-2109, CVE-2016-2176)
  • qemu: version (CVE-2016-3712, CVE-2016-3710)


Known Issues

  • NFS connectivity issues with some media players
  • Reported performance issues with some low/mid range hardware
  • Spindown of SAS and other pure-SCSI devices assigned to the parity-protected array does not work (but SATA devices attached to SAS controller does work)


Cumulative Change Log


See here


Guides for New Features


Dual Parity


Assigning a second parity disk


  • Stop the array
  • Navigate to the Main tab
  • Assign a new storage device to the Parity2 disk slot (must be equal to or larger than your largest data disk
  • Start the array


A parity sync will begin automatically after starting the array with a new storage device assigned to the Parity2 slot.


Replacing a failed disk


The procedure to replace a failed disk is the same as it is with single parity.  In a dual-parity configuration, two failed disks may be replaced at the same time.


Upgrading a parity disk (to a larger size)

  • Stop the array
  • Assign the new larger disk to the parity slot you wish to upgrade
  • Start the array


Downgrading to 6.1.x from 6.2


If you decide to roll-back to a previous 6.1.x release of unRAID after setting up dual-parity on 6.2, you will no longer have dual-parity on the 6.1.x release.  If you then later upgrade again to 6.2, you will once again need to assign your secondary parity disk and start the array to begin another parity sync.


GUI boot mode


To access the GUI boot mode, attach a monitor, mouse, and keyboard to your system and boot it up with 6.2.  When the boot menu loads, you can select the option to boot into the GUI.


To make this boot mode the default, perform the following steps:


  • Navigate to the Main tab
  • Click on the flash device to go to its settings page
  • Under Syslinux Configuration, move the line "menu default" to live under the GUI boot mode option
  • Click apply and future reboots will automatically launch the GUI boot mode


Note: GUI boot mode requires about 200MB additional RAM at run-time.


Automatic System Shares


When starting the array a share called "system" will be automatically created with the "Prefer" cache mode.  "Prefer" means the share will be created on the cache disk/pool if present, otherwise on the array.  If created on the array, and then later a cache disk/pool becomes available, the "mover" will attempt to move the share to the cache disk/pool.


When Docker is started, a subfolder called "docker" will be created in the "system" share where a loopback image file called "docker.img" will be created for the service.  In addition, a share called "appdata" will be automatically created with the "Prefer" cache mode.  The "appdata" share is the default location where per-container "application data" is stored.


When Virtual Machine manager is started, a subfolder called "libvirt" will be created in the "system" share where a loopback image file called "libvirt.img" will be created for the service.  In addition, a share called "domains" will be automatically created with the "Prefer" cache mode, and a share called "isos" will be automatically created with "Use cache" mode.  The "domains" share is the default location where virtual machine vdisks are stored, and the "isos" share is the default location where various ISO files are stored for assignment to virtual machines.


NOTE:  Existing configured paths for the docker.img and libvirt.img file, as well as for "appdata" and "domains" will not be modified upon upgrade.


Default Docker /config Volume Mapping


You can adjust this setting under the Settings -> Docker page.  Whatever path is specified here will have sub-folders created underneath it automatically whenever new containers are added to the system that have a /config volume mapping specified.


Docker 1.10 Container Update Process


The reason we have not upgraded Docker in unRAID 6.1 has been because of a significant change to the Docker Hub API.  Legacy versions of Docker can still talk to the legacy API, but the newer versions require you to talk through the newer API.  This newer API broke a number of functions in the Docker Manager that is in unRAID 6.1, but since the API for Docker still functions against that release version, it has continued to serve its purpose for the community.  In unRAID 6.2, we are using a later release of Docker (1.10.2) and we've resolved all the API related issues so that Docker Manager works ok.  However, there is a one-time update procedure that each container will need to go through in order to point it towards that new API going forward, even if the container itself truly isn't in need of an update.


From the Docker 1.10 release notes:



IMPORTANT: Docker 1.10 uses a new content-addressable storage for images and layers.

A migration is performed the first time docker is run, and can take a significant amount of time depending on the number of images present.


Refer to this page on the wiki for more information: https://github.com/docker/docker/wiki/Engine-v1.10.0-content-addressability-migration


Virtual Machines


NOTE:  before upgrading to 6.2, please be sure to backup any VMs you have AND set disable them from auto-starting.  This will give you the opportunity to perform the post-upgrade procedures before starting them.


NOTE:  In addition, any edits you make in 6.2 to your VMs will not be present if you roll-back to 6.1.x at a later point in time.  When you roll-back, your VM configurations (XML) will be in the state they were prior to the upgrade.  This also means that new VMs you create in 6.2 will NOT show up under VM manager if you roll back to 6.1.x.  This doesn't affect virtual disk image, only the VM configurations themselves


Post-Upgrade Procedures


A number of "under the hood" changes have occurred for virtualization in this release.  To ensure that your VMs take advantage of all these changes and continue to function properly, the following one-time actions should be performed before starting your VMs for the first time.


NOTE:  Any custom XML edits you have made will be lost after performing this procedure.


  • For each VM, go to the VMs tab, click the VM's icon, and select the Edit option
  • Turn on "Advanced View" in the top right of the Edit VM page
  • If you are using VNC for the primary graphics card, adjust the VNC Video Driver field to QXL
  • Click Apply


Even if your VM isn't using VNC (such as GPU pass through), you should perform the above procedure.


Upgrading 6.1.x to 6.2 OVMF VMs

After upgrading to 6.2 and performing the previously documented procedure against an OVMF VM that was created under a 6.1.x version of unRAID, your first time booting that VM in 6.2 will likely take you to a UEFI shell prompt, and not boot your OS.  To resolve this type the following commands:


cd efi
cd boot


Adjust the first command to fs1: if fs0: doesn't work.  This only needs to be performed once per OVMF VM.


Stubbing and assigning other PCI devices


To stub PCI devices so they can be assigned to VMs through the webGui directly, you'll need to follow these steps:


  • Login to your server using the unRAID webGui
  • Navigate to the Tools -> System Devices page
  • Locate the PCI device you wish to stub and then copy the vendor and product ID specified in brackets near the end of it's row.  Example (the bolded part highlights the vendor/product ID):


01:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 [8086:1528] (rev 01)


  • Navigate to the Main tab and click on your Flash device
  • Under the Syslinux Configuration section, locate the line that says "menu default"
  • Beneath that line, you will see the following:


append initrd=/bzroot


  • Change the line, adding the bolded part as shown in the example below:


append vfio-pci.ids=8086:1528 initrd=/bzroot


  • Click Apply and then reboot your system.


When adding/editing VMs from this point forward, the stubbed PCI device(s) will show up at the bottom with check boxes that you can click to assign them.


Nested virtualization support


Now you can install VMWare on unRAID as a VM itself!  Yup!  It really works!


OpenELEC 6.0.0 Support


After starting up your 6.2 release for the first time, edit your existing OpenELEC VM(s) and you will find a new version available to download in the webGui.  Download it to your system and start up your VM(s) to begin using this upgrade!


Turbo Write

To enable this setting, visit the Settings -> Disk Settings page and set Tunable (md_write_method) to "reconstruct write".

Link to comment
  • Replies 443
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Additional Upgrade Advice

-- Tips, Issues, Recommendations, Clarifications ...


While the original poster was 'limetech', we moderators have taken it over, and the material here is almost entirely collected and entered by moderators and veteran users.  While we are making a best effort to ensure all information is accurate, if the item does not say it's from someone at Lime Technology, it's NOT official!  We don't want anyone blaming Lime Technology for something they did not do or say!


Added notes from Lime Technology

- The "Check for Updates" via the Plugins page will also work to upgrade those using 6.2-beta/rc.  However we will be deleting the "unRAIDServer-6.2" repo from github in a few days.

- Also, important: those of you who have local clones of "dynamix-6.2" - we will be renaming this to "dynamix-next".  All you have to do is change the origin setting in your git config file to reference the new repo name once this happens.


Need help? Read me first!  Requests for support should go in the appropriate support forum, and should include the Diagnostics zip.


Latest updates

- If you are upgrading from 6.1 or earlier, read this post *and* the one before it!

- unRAID Server Version 6.2.4 - Official stable release

- unRAID version 6.3.0-rc4 - Pre-release Board (beta releases)


Upgrades not working

- As of 6.2.2, there is a change in the Lime Technology download server, which is causing prior versions to not see the latest unRAID releases, and indicate they are up-to-date, when they aren't.

- Go to Install Plugin and paste this link ->  https://raw.githubusercontent.com/limetech/webgui/6.2/plugins/unRAIDServer/unRAIDServer.plg



- There may be an issue with Windows VM's not starting on certain AMD chips, possibly FX series.  See this thread.  This has been reported for multiple 6.2 releases.  Try the suggestions from eschultz in this thread.

- Nothing else new yet (see "Known Issues" in first post)


Packages and Dependencies

- After upgrading, if you are using tools from the NerdPack, make sure you go into the NerdPack plugin and toggle all of your installs off, then back on (click Apply if needed), in order to update all of your tools to the correct versions for 6.2.  Otherwise, you may see segfaults, high CPU usage, and other bad behavior.


Docker and the new system paths

  Update!  unRAID 6.2.1 corrects the restriction on usage of a drive mounted through the Unassigned Devices plugin!  So if you upgrade to 6.2.1 or later, you can leave your docker.img on an unassigned drive!

  Notes and comments from Squid

- You probably don't need to change anything!

- If you're not going to use unRAID's default locations for appdata (and once again no real need to), the only thing you should change is the Default appdata storage location setting to match your appdata location.  Not doing this will not affect any running apps, or any previously installed apps installed through Community Application's Previous Apps section, but on any new apps being added the /config mapping may be incorrect when unRAID tries to fill it out.  Additionally, having Docker applications using 2 different shares for their respective appdata storage will also impact CA's appdata backup module if you are utilizing it.  For more information about the default appdata storage location, see this Docker FAQ entry.

--- The only real caveat with this is that you have to manually type the path if it's NOT within /mnt/user (on both the Docker image location and the appdata location).

- The "system" share is a default location for the docker.img and the libvirt.img file.  Nothing and nowhere does it say you have to use it.  I still have my docker.img stored at /mnt/cache/docker.img.  No ill effects.

- Nor do you have to export that share via SMB.  I've got my export on the system share disabled so I don't see it when I browse the network.

- Why are they auto generated?  Because it makes life easier for people just getting started on unRAID.

- Unlike 6.1.9, you can now reference your appdata shares within the Docker templates as /mnt/user/appdata/appName, and have it work correctly!

- 6.2 also better supports host volume shares stored outside of your array.  See this Docker FAQ Entry for more details.

- The Docker FAQ is a good resource for additional Docker related questions and issues.

- Those having Docker issues (such as no Docker tab, "layers from manifest" error, no working dockers, all Dockers need upgrade, etc), the common solution recommended seems to be the same - in Docker configuration, delete your docker.img, recreate it again (not on an unassigned drive!), then reinstall your Docker apps through Community Application's Previous Apps section or via the my* templates.  Your apps will be back the exact same way as before, with no adjustment of the volume mappings, ports, etc required.  This should be easy, fairly quick, a one-time operation.


Missing Docker tab

- If after the upgrade you discover that your Docker tab is gone, one reason may be that you have your docker.img installed on an unassigned drive.  Please see the previous section about Docker paths.

- Update!  Upgrade to unRAID 6.2.1 or later, and you can leave docker.img on an unassigned drive.


Network changes and issues

- Whenever there is a significant upgrade of the underlying kernel, inevitably there are a few users with multiple NIC's that lose connectivity, because the kernel will identify the NIC's in a different order than previous kernels did.  That means eth0 will shift to a different NIC, perhaps one you aren't even using.  That also means your server may be offline, unreachable!  Often the fix can be as simple as switching the network cable to the other port, but usually you will want to study the situation, and determine what needs to be switched or reconfigured, to restore things the way you wanted them.  There are significant changes mentioned in the following that will impact this going forward and make it less of a problem, since you will be able to configure which physical port is eth0, eth1, etc, and expect them to stay that way, even if a future kernel again changes its mind as to which to setup first.

  *** Notes and comments from dlandon ***

- For those of you having issues with networking, Docker updates, VMs not seeing the network, etc.  Please go through the following steps to see if it helps.  The reason for this is that unRAID needs to have a bridge called br0 for VMs and some changes may have renamed your NICs.  There are several things to do to set up the bridge and make it work.

- Go to 'Settings->Network Settings' and be sure 'Enable Bridging:' is set to yes.  If you have multiple NICs that are bonded, don't set any bonding mode other than active backup for now.  Setting this to other modes can cause issues.  You can come back later and tune this up after you get other settings made and the system is running correctly.  Don't set up any VLANs at this time.  Verify IP address and default gateway settings.  If the settings already look correct, make a change then set it back and click 'Apply' to re-save them.

- Go to 'Settings->VM Settings' and select br0 as the 'Default Network Bridge'.

- Edit each VM and be sure that the 'Network Bridge:' is set to br0.

- When updating from 6.1 there were some significant improvements to the networking and these manual settings have to be made for the new networking to work properly.  In the older versions of unRAID, the user created and named a bridge.  That no longer applies.  Back in the Xen VM days we all had a bridge we called Xenbr0.  That no longer works and these steps have to be made to update the bridge.

- If you have multiple NICS and don't bond them, you will need to verify that eth0 is the same NIC as before.  Linux may be renaming the NICs so eth0 is not the NIC you think it is.  If you have multiple NICS I recommend that you bond them.

- If none of this works and you are still having issues, remove all plugins and reboot.  Then install plugins one at a time and see if they affect the network.  Some plugins have been reported as causing network issues.  The best way to do this is to remove the plugins one at a time and then use CA (Community Apps) to restore them using the 'Previous Apps' button.

  *** Notes and comments from bonienl ***

- In order to add better multi-NIC support, and to add VLAN and other capabilities, the network configuration has been greatly revamped and expanded.  But the changes *may* cause issues on first boot.

- The new network configuration page will show individual settings for each Ethernet interface present in the system. Interfaces are automatically discovered and added (or removed) when opening the network configuration page.

- The main interface eth0 is used as management interface for unRAID itself and requires Internet access to allow proper operation of unRAID with regards to updates and installations.

- On a system with multiple Ethernet interfaces subsequent interfaces are presented as eth1, eth2, etc. By default these additional interfaces are configured as part of the bond0 interface together with interface eth0. This allows a user to connect a UTP cable to any of the available Ethernet ports, and access the webGUI without worrying which interface is actually eth0.

- Users have now a choice to use the additional Ethernet interfaces to create segregated network connections, e.g. let VMs communicate in their own (protected) domain. This requires the interface(s) to be configured as bridge though.

- Also systems with a single physical Ethernet interface are capable to create segregated network connections by using VLANs also known as logical connections. Advanced setups may combine physical interfaces and logical connections to increase the number of networks as desired.

- The last section of the network configuration page is "Interface Rules", this section allows a user to change the assignment of the interfaces and make this persistent across system reboots. Say a user has added a new & better Ethernet card and wants this to be eth0. This is simply achieved by  choosing the corresponding MAC address of the new interface and assigning it as eth0. A system reboot is required to make the new assignments active.

- If the networking is not working at first, try deleting the /flash/config/network.cfg on your flash drive and rebooting.  But you may have to setup your network again from scratch.

--- Also try editing the config/network.cfg on the boot drive, and setting a static DNS (and gateway addresses) up, / and or for a gateway.

--- Also try the new boot GUI from the boot menu (no network required!), you can then configure your networking as needed.


XFS errors and unmountable drives

- The XFS file system support is newer in 6.2, and it's possible that on first array start of XFS drives, one or more XFS drives will be unmountable or errors will be found in the file system that did not have errors prior to 6.2.  In other words, the 6.0 and 6.1 XFS did not detect certain problems that the 6.2 XFS does.

- Just run xfs_repair -v on the drive (see Check Disk File systems), and the drive file system should be corrected.  However, if you are instructed to use the -L option, then repeat the repair with -vL as the option (the v just makes it report more info, more verbose).

- A number of users have had to run the repair with the -L option, when they found an unmountable drive after the upgrade.

- Unmountable drives may also be caused by the Auto option for File system type.  The Auto option is supposed to auto-recognize which file system (XFS, ReiserFS, or BTRFS) is being used on a drive, but it is apparently getting confused and failing, usually resulting in a failure to mount, then showing the drive as Unmountable.  It is strongly recommended to set the File system type to the actual file system in use on that drive, not leave it at Auto.


Upgrade fails if not enough RAM

- RAM amount of 1GB appears to be too little for upgrading through the plugin, within the program.  You will need to do an old-fashioned update by downloading the distro, and extracting and copying the appropriate files to your boot drive.  For more detail and instructions, see this post

- Consider increasing your RAM!


Error: "layers from manifest don't match image configuration"

- Easy fix, relatively quick too, see this Docker FAQ entry


No 6.2 upgrade available

- Several 6.1.9 users have found that when they "Check for updates" on the Plugins page, no update is available.  You will need to do an old-fashioned update by downloading the distro, and extracting and copying the appropriate files to your boot drive.  For more detail and instructions, see this post


Pitfalls of updating Docker containers from past releases

  Notes from SparklyBalls - for more info see this

- First off, due to the time span between releases, some Docker containers may no longer be available on the hub.  Not much can be done here, seeking alternatives is the only option.

- Secondly, the version of a Docker image you have installed with 6.1.9 could have been updated quite a lot and configuration files etc in your appdata from older versions may cause problems when pulling the newer image.  (Those of you who keep up to date with docker image refreshes will have no problems here).  So if you have issues after the upgrade to 6.2 with any particular Docker image, be sure to mention you have made the 6.2 upgrade in the relevant support thread, this could help Docker maintainers identify problems and work out possible solutions.


Powerdown was temporarily terminated

- For awhile, Powerdown was blocked for installation in 6.2.  The built-in powerdown function is being enhanced to provide much of the Powerdown functionality.  Update!  Powerdown is again allowed to be installed.  But upgrade to unRAID 6.2.4 for improved shutdown support.

- http://lime-technology.com/forum/index.php?topic=48972.msg497484#msg497484

- Some of the Powerdown plugin features have now been added to the Tips and Tweaks plugin, including saving the diagnostics and archiving logs on shutdown.

- For those running K and S scripts (kill scripts at shutdown and init scripts at startup), the User Scripts plugin allows you to run scripts at startup or shutdown of the array.

- To keep the Powerdown plugin, don't update it.  You will want to make sure that Auto update is off for it.



- Probably one of the most important features added to v6 is Notifications, and many users have never turned them on!  Your system wants to tell you of everything important or wrong with the system!

- All users should go to "Settings"  >>  "Notification Settings" and set it up so that they will receive notifications of when a problem develops.  Start with requesting daily checks and e-mails.  Weekly notifications may be less intrusive but monthly notifications are probably too far apart.  This can alert the user to an easily fixed problem, before it worsens or accumulates, possibly resulting in data loss!


Windows logins and credentials

- Windows (especially Windows 10) often has issues with logins.  Try removing current Windows credentials, by running Windows Credential Manager and removing them, then retrying the operation that failed (and reentering the name and password).


Methods for backing up your VM's

- Here's a comprehensive method from danioj



- For some help with 'stubbing', see this post


Very high CPU usage

- Several users have reported very high CPU numbers after upgrading to a 6.2 version.  Try uninstalling any plugins you aren't using, and reapplying settings in some of the Settings pages (toggle them off then back on and click Apply).  In particular, you may have to toggle off and on any NerdPack tools you were installing, to make sure you have the tool versions appropriate for 6.2.  It's a good idea to reboot after this.


Performance issues

- If the webGUI is suddenly very slow changing pages, see this FAQ entry.

- Users upgrading to any 6.2 version will have the default Disk Setting Tunable (md_sync_thresh) value of 192.  If you have previously raised your tunable numbers, perhaps by using the unraid-tunables-tester, you may have significantly worse performance.

- In 6.2, the disk tunables can make a big difference in write speed and parity build and check speed.

- We don't have good guidelines worked out yet, but you may want to raise md_sync_thresh to be about 30 less than md_sync_windowHere's one story where that worked.

- A quote from the past from Tom: "This tunable was added to improve the parity check performance some users were having with the SAS2LP, IIRC, your controller uses the same chipset, basically the SASLP and SAS2LP work faster if this value is approximately half the md_sync_window value, other controllers like most LSI based ones, work faster with a md_sync_thresh just a little lower than md_sync_window."


On 6.1.9, webGUI fails

- This is NOT a 6.2 issue, but because it's coming up quite often, it's listed here.

- Unfortunately, for very unusual reasons, the new webGUI for 6.2 is auto updating the webGUI on 6.1.9, causing it to fail, with errors showing.  And after corrections have been made, even rebooting has been problematic for some.

- The best advice seems to be ->  Delete the file  config/plugins/dynamix.plg  on your flash device and reboot your system.

- For more information, see this thread.


Moderators, please help collect any useful info and add it here.

Link to comment

Tom and team -  This is awesome and have been waiting for a long time now. I am on 6.1.9 and the check update shows up 6.2. I am running two vms,  a win8.1 and Win10. Is there a recommended process outline to upgrade from the previous stable release?




Hi!  Just updated the OP to include the Guides for New Features section which explains the upgrade process.

Link to comment

Stubbing and assigning other PCI devices


To stub PCI devices so they can be assigned to VMs through the webGui directly, you'll need to follow these steps:





I stopped stubbing my NICs some time ago because a hardware change can result in a different PCI device number, and can still assign them to my VMs, is stubbing still recommended?

Link to comment

Stubbing and assigning other PCI devices


To stub PCI devices so they can be assigned to VMs through the webGui directly, you'll need to follow these steps:





I stopped stubbing my NICs some time ago because a hardware change can result in a different PCI device number, and can still assign them to my VMs, is stubbing still recommended?


Stubbing is recommended. How often are you making hardware changes that stubbing is problematic for you?

Link to comment

This is awesome! What a great list of features to suddenly (from my perspective) arrive so shortly after I've started using unRAID again. I was hoping some kind of vlan functionality would be added and as I've only recently set up unRAID I hadn't really looked into the 6.2 RC or anything so all of these features are a nice surprise to me.


Quick question - the post says "If you are using plugins, please see this thread regarding plugin support." I see no mention of any changes between 6.1 and 6.2 so I assume I'm OK to just go ahead and update from 6.1 (6.1.9..) straight to 6.2 without affecting my existing setup?

Link to comment

Stubbing and assigning other PCI devices


To stub PCI devices so they can be assigned to VMs through the webGui directly, you'll need to follow these steps:





I stopped stubbing my NICs some time ago because a hardware change can result in a different PCI device number, and can still assign them to my VMs, is stubbing still recommended?


Stubbing is recommended. How often are you making hardware changes that stubbing is problematic for you?


I'm constantly tinkering with my servers  :P , it's working fine without stubbing so I'll keep it like that for now.


Forgot on my previous post, congrats for the 6.2 stable!!! Soon™ is now  :)

Link to comment

You left out one known issue between the last RC and this one. I assume its still a known issue? I am still have my problems with it spinning down.


- There are spinup/spindown issues with SAS devices assigned to the parity-protected array.

Yes I'll add that to the list but this is going to be a complex fix.  Note: SATA devices attached to SAS controller should work ok, but pure SCSI (including SAS) device spin down is problematic (because spin-up group support).  If you want to discuss this further please open a Defect list topic for it rather than in this topic.

Link to comment

So I took the update and my docker is destroyed.  I can't even get it to recreate a new docker.img is anyone else seeing this?


Same. I can access the location the img file was located on but when I start docker it just sits there at stopped. No new image is created and nothing in logs.


I know there is a migration process so is this it and there is just no logging?

Link to comment

So I took the update and my docker is destroyed.  I can't even get it to recreate a new docker.img is anyone else seeing this?


Please post your system diagnostics.


Well I had my docker img on an unassigned disk, formatted to ext4.  That was not a problem in 6.1.  When I instead had it create my image on my cache drive brtfs it recreated it and started.  then I had to re-import my containers.  which are all still on my ext4 unassigned disk.  Is that an anticipated change in functionality? 



Link to comment

"In unRAID 6.2, we are using the latest release of Docker (1.10.2)"




and it's 1.10.3 that's reported installed....




Yeah we were at RC already when docker 1.11 was released and we were trying to minimize subsystem changes to our RC while stamping out some other nagging issues preventing release of 6.2 stable.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.