Unraid OS version 6.9.0 available


Recommended Posts

54 minutes ago, Cull2ArcaHeresy said:

mover only goes between main array and cache (no cache/fast/slow 3 tier option or cache/other pool option)

 

Not specifically the "cache" pool but the pool you nominated for use with that user share.

 

56 minutes ago, Cull2ArcaHeresy said:

pool can only be in raid0 or raid1 (with 2, 3, or 4 copies of data). Raid6 replaced with raid1c3, meaning instead of #disk-2parity / #disk you only get 1/3 of storage max? Is super reduces capacity (for more than a few drives), but less stress during rebuild + higher redundancy the only option here?

 

Any of the available btrfs RAID profiles can be used, including Single, RAID10, RAID5 and RAID6, in addition to the ones you mention, if you allocate the appropriate minimum number of disks to the pool. The use of RAID1c3 refers to the file system metadata associated with RAID6, in order to fulfill the requirement for two disk failures to be supported. RAID5 and 6 still suffer from the "write hole" problem and very long scrub times so they can't be recommended without caveats, though I'm happy to use them.

 

Link to comment
On 3/3/2021 at 12:24 PM, Squid said:

Doesn't for me.  The "du" of /var/lib/docker under both an image and as a folder are roughly the same

 

There must be some problem here. 

My /mnt/cache/system/docker/dockerdata (docker in folder) is about 72-79GB if I check with du. My old docker.img had a max size of 30GB and was near half full. 

If I check using the unraid gui and click calculate for the system share I get about 80GB used but when I use df -h i see that my cache drive only has 19GB used. 

Edited by Niklas
Link to comment
7 hours ago, John_M said:

Any of the available btrfs RAID profiles can be used, including Single, RAID10, RAID5 and RAID6...The use of RAID1c3 refers to the file system metadata associated with RAID6, in order to fulfill the requirement for two disk failures to be supported

I thought it was saying that if you chose raid6 that it would replace it with raid1c3, but the behind the scenes reason makes much more sense

 

7 hours ago, John_M said:

RAID5 and 6 still suffer from the "write hole" problem and very long scrub times so they can't be recommended without caveats, though I'm happy to use them.

Functionally speaking (for parity calculation), isnt unraid single/double parity the same as raid5/6 and has the same vulnerability? I do have a UPS that estimates ~30 minutes runtime, but I know any unclean shutdown/system crash could still cause problems. I know it is all a balancing act of capacity vs redundancy/risk. Considering all these 4tb sas drives are used which the seller told me to expect ~1 drive failure per year if on 24/7, i might end up going with raid1(c2) just for less stress on drives...raid 50 or 60 would be great option, but not seeing that in btrfs lists.

 

 

 

2 hours ago, hawihoney said:

Why not add the unused disks to the array?

At unraid capacity of 28+2 parity. Also only 3 open bays, but a second ds4246 has been ordered.

Link to comment
15 minutes ago, Cull2ArcaHeresy said:

Functionally speaking (for parity calculation), isnt unraid single/double parity the same as raid5/6 and has the same vulnerability?

Yes, but there are more risks running btrfs raid5/6 pools, there are still some known issues and bugs, and if there is a problem you can lose the whole pool, you can still use them, I do and have multiple raid5 pools, just be aware of the possible issues and keep good backups.

Link to comment

Just upgraded 6.8.3 > 6.9.0 with no issues so far. Everything seems to be running as it was, took less than 5 minutes.

 

Removed the edited go file config for hw transcoding, then un-blacklisted the intel driver with 

touch /boot/config/modprobe.d/i915.conf

 

Tested Plex and it's using hw transcoding fine. 

 

For something I was absolutely bricking it to pull the trigger on, it was absolutely seamless and hardly seems worth the fear now🤣

 

Cheers!

  • Like 3
Link to comment

Upgraded from 6.8.3 - > 6.9.0 with only one weird issue.

* I tried to create a new pool out of my Unassigned Devices SSD (serving as VMs and appdata storage)

This returned "filesystem is unmountable" due to "partition alignment" (I think the message was)

So I made a backup of all the data, and proceeded to format the SSD (via the Main / Array Operation / Format button)

Then it mounted the SSD, but nothing seems to have been changed. even the partition table seemed untouched.

 

Link to comment

just upgraded.  posting what i had to do for others in case they had similar issues to me.

  • docker-compose
    • all of my containers are in a single docker-compose.yml file and that reloaded without any problems after the array was started.  hooray!
  • ssh
    • per the release notes, a password is required now.  i enjoy the convenience of no password so i ended up just setting up private key authentication instead.

and...that's it.  pretty seamless upgrade.  thank you!

  • Thanks 2
Link to comment

For anyone having trouble with GPU Passthrough on 6.9.0; either freezing or unable to install drivers, here is the fix for that: 

 

Credit goes to @Celsian 

I resolved my issue. Having dug deeper I found the following in my VM Log:

 

2021-03-06T06:32:32.186442Z qemu-system-x86_64: vfio_region_write(0000:09:00.0:region1+0x1be6ba, 0x0,1) failed: Device or resource busy

 

Some searching yielded another thread:

 

Adding a user script to User Script Plugin that runs when the array starts seems to have solved my issue, I was able to successfully boot into Windows 10 VM with the GTX 1060 passed through. I have installed the drivers successfully.

 

 

The script:

#!/bin/bash
echo 0 > /sys/class/vtconsole/vtcon0/bind
echo 0 > /sys/class/vtconsole/vtcon1/bind
echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind

 

Edited by fearlessknight
  • Thanks 1
Link to comment
18 hours ago, Hoopster said:

I am glad that worked for you (others as well), but it is certainly not normal or expected. 

 

Have you tried a reboot after it came up and did it take that long again?  If so, your configuration should be checked as something is not right.

 

Yes looks like you are right, I just rebooted again and have the same issue. Samba comes up as I can access shares but not able to get to Web GUI again.

 

Edit: 5-10 mins wait and gui is accessible now, probably more normal right?

Edited by witalit
Link to comment
23 hours ago, AgentXXL said:

 

EDIT: SOLVED - I don't understand why, but it took 2 reboots and 3 x changing/refreshing the root password before I could again use ssh from my Mac. Regardless, it's working for now.

 

Original Message Starts:

 

I'm having this issue as well, but only on my backup unRAID system. Refreshing the root password hasn't worked. I'm using MacOS Terminal like I always have and under the 'New Remote Connection' dialog it shows I'm issuing the command:

 

ssh -p 22 [email protected]

 

After refreshing the password I also tried using the built-in shell access from the unRAID GUI and it works:

 

AnimDLLoginViaGUI.jpg.f98eacf5cbcc015b88c6fbb0b0b5ca2c.jpg

 

Looking at the syslog shows that it's using the right user (uid=0 which is root), but it's not accepting the password. This worked fine before the upgrade to 6.9.0. Note that the backup system was upgraded from 6.8.3 whereas my media server (which I can ssh into) was upgraded from 6.9.0 RC2.

 

Suggestions? Thanks!

 

How are you managing your public ssh key?  That is, ssh requires existence of /root/.ssh directory which contains the file authorized_keys.  Do you have some lines in your 'go' file that accomplishes this?

Link to comment
Mar  6 11:48:58 Servo root: ERROR: system chunk array too small 34 < 97
Mar  6 11:48:58 Servo root: ERROR: superblock checksum matches but it has invalid members
Mar  6 11:48:58 Servo root: ERROR: cannot scan /dev/sdc1: Input/output error
Mar  6 11:49:26 Servo emhttpd: mount_pool: ERROR: system chunk array too small 34 < 97
Mar  6 11:49:26 Servo emhttpd: mount_pool: ERROR: superblock checksum matches but it has invalid members
Mar  6 11:49:26 Servo emhttpd: mount_pool: ERROR: cannot scan /dev/sdc1: Input/output error

1st Issue ^^

 

 

2nd Issue
All drives on my flashed h310, are showing spundown "but are actually spun up, and working"

 

Link to comment

Upgraded from last stable as I had a spin-up problem with my Seagate Ironwolf parity drive under RC2.

I see the same quirk again under the new kernel - this time having attached diagnostics.

 

From what I can tell, it appears once the mover kicks in and forces the spin up of the parity.  It tripped up once as you can see from the logs but came up and wrote fine.

 

I've done repeated manual spin downs of the parity, writing into the array via the cache, and forcing a move hence bringing up the parity again.  No errors as of yet.

 

This is a new drive and under the same hardware setup completely as 6.8.3 so it is a software/timing issue buried deep.

 

If this continues, I will move the parity off my 2116 controller (16 port) and over to my 2008 (8 port) to see if that relieves any issues.  Past that, perhaps over to the motherboard connector to isolate the issue.

 

FYI.Parity1.png.29bd5381ffc859dacf4f027e50fd62ca.png

 

Kev.

 

Update:

 

I've disabled the cache on all shares to force spin ups much faster.

 

Just had another reset on spin up.  I'll move to next controller now.

 

image.png.2cf1e4be9745be74850b0ff67fc6ebce.png

 

Update 2:

 

Drive dropped outright on my 2008 controller and Unraid dropped the parity and invalidated it:

 

2021-03-06_16-35.png.17050e0849299722d640eb1a5bbfc066.png

 

I'm going to replace the Seagate with a 8T WD unit and rebuild.  Definitely an issue somewhere with timings between the 2 controllers.

 

Update 3:

 

After some testing offline with the unit and digging, it looks like the Ironwolf may be too aggressively set at the factory for a lazy spin up.  This behavior must be tripping up some recent changes in the mpt2/3sas driver.

 

Seagate does have advanced tools for setting internal parameters ("seachest").  I set the drive to disable the EPC (extended power conditions) which have a few stages of timers before various power-down states.  I also for good measure disabled the low current spin-up to ensure a quick start.  Initial tests didn't flag any opcodes in the log.  I'm rebuilding with it and testing.

 

For note, the commands are:

 

SeaChest_PowerControl_xxxx -d /dev/sgYY --EPCfeature disable
SeaChest_Configure_xxxx -d /dev/sgYY --lowCurrentSpinup disable

 

Settings.thumb.png.8ce2d82f4789675d72649ba94d3fc37d.png

 

Update 4:

 

I've submitted all info to Seagate tech support citing the issue with the 10TB and my suspicions.  Deeper testing today once my rebuild is done to see if the fixes clear the issue.

 

Update 5:

 

Full parity rebuild with Ironwolf.  No issues.  I've done repeated manual drive power downs and spin ups to force the kernel errors across both the controllers above and I have not seen any errors.

 

Looks like the two tweaks above are holding.

 

Kev.

 

 

Edited by TDD
Updates
  • Like 1
  • Thanks 3
Link to comment
10 hours ago, limetech said:

How are you managing your public ssh key?  That is, ssh requires existence of /root/.ssh directory which contains the file authorized_keys.  Do you have some lines in your 'go' file that accomplishes this?

 

[EDIT: SOLVED] I've corrected my flash drive error described below. Looking through the syslog shows that there was a USB disconnect on the port/controller that my unRAID flash drive was plugged into. Not sure how/why, but I had plugged it into a USB 3 port. I did a shutdown, checked the flash drive on a Windows system and it was OK. After plugging it back into a USB 2 port, it booted successfully. The only issue created seems to be that the 2 x 16TB drives that reported as successfully precleared are not being seen as precleared. I guess I could go ahead and add them to the array, letting unRAID do its own clear process if required.

 

Original message reply starts here:

 

I usually let the systems manage the public keys in the default manner. When I made my 1st login to both of my unRAID systems via Mac Terminal I was asked if I wanted to trust the systems, which I did. This is supposed to save the host key so you don't get asked on future logins. I just checked for the existence of that directory by logging in and it appears that I don't have that folder. When I start MC it opens to the root folder and there's no .ssh folder, but there is a file named ~.ssh, as shown in this picture, with the actual path shown as /boot/config/ssh/root directory.

 

DefaultMCStartup.jpg.ad573add1e074d1f0b21d9db0ca5cbda.jpg

 

If I then manually change to /boot/config/ssh/root there is nothing in the folder. But one level back at /boot/config/ssh there's a number of files, as shown in this image:

 

ManualRootDir.jpg.50fcff2b5b039e348d54d15c85ae3192.jpg

 

As I'm now able to login after doing the reboot/refresh password 'dance', this seems to be the norm. Note that on 6.8.3 I had chosen to trust the system so firing up a ssh session from my Mac would auto-login. Now it requires the password. I know I can reset this to auto-login, but I'm OK leaving it as is. It's one extra level of protection if an intruder got access to my Mac.

 

Right now though, I appear to have a more serious problem on my media unRAID. I was pre-clearing 2 new 16TB drives for the last 2 days, with that completing around noon (Mountain TZ) today. I didn't have a chance until an hour ago to go look at it, but I immediately had some corruption on the Dashboard tab. I then noted in the upper right corner that there's apparently a problem with my flash drive.

 

AnimNASFlashDriveError.thumb.jpg.5d0912d67dc6c69a64a6b4aab3b5c4fb.jpg

 

I then noticed under the Main tab that the flash drive is shown in the Boot Drive section but it also appears under the Unassigned Devices list as shown on the following screenshot. Also note that my cache drive is not appearing in the 'Pool Devices' section and my UD mounted volume for some Docker containers and a VM is showing no usage info. Both of the drives appear OK when accessed via the shell/MC.

 

AnimNASFlashErrorCorruption.thumb.jpg.c6c4ab2fb71286aecbbfd2861720d727.jpg

 

Here's one more pic showing the corruption of the Dashboard tab, which appears to be related to the flash error. Also note that it shows none of my Docker containers which are still working. I've grabbed diagnostics and verified that my daily backup of the flash drive was successful. Note that the flash backup was done by the CA Backup/Restore Appdata plugin. Clicking on 'Flash' in the main tab stalls at a blank page. Do you want me to open a specific topic in the General Support forum for this? Any precautions I should take before attempting a reboot?

 

AnimNASDashboardTabCorruption.thumb.jpg.af8260331d55761115834ee21331ca87.jpg

 

Sorry for the long post... if you want the diagnostics zip I'd prefer to send it via PM even though it's been anonymized. Let me know.... thanks!

 

Edited by AgentXXL
Spelling and clarification; Solved flash issue
Link to comment

Anybody understand why the dashboard doesn't seem to be able to show the correct orange and red disk usage bars anymore?

image.png.65699e3d7302e011c3471eaf02a277dc.png

I've tried resetting the disk free thresholds, but no luck.

 

Also IPv6 routing has new entries the GUI is not parsing properly

image.thumb.png.cba468d0246b042e2599bdcfd4b63fe4.png

root@MediaStore:/usr/local/emhttp# ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2001:xxxx:xxxx:xxxx::/64 dev br0 proto ra metric 216 pref medium
fd6f:3908:ee39:4000::/64 dev br0 proto ra metric 216 pref medium
fe80::/64 dev br0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev vnet0 proto kernel metric 256 pref medium
multicast ff00::/8 dev br0 proto kernel metric 256 pref medium
multicast ff00::/8 dev eth0 proto kernel metric 256 pref medium
multicast ff00::/8 dev vnet0 proto kernel metric 256 pref medium
default via fe80::ce2d:e0ff:fe50:e7b0 dev br0 proto ra metric 216 pref medium

 

  • Like 1
Link to comment
1 minute ago, ken-ji said:

Anybody understand why the dashboard doesn't seem to be able to show the correct orange and red disk usage bars anymore?

image.png.65699e3d7302e011c3471eaf02a277dc.png

I've tried resetting the disk free thresholds, but no luck.

 

Also IPv6 routing has new entries the GUI is not parsing properly

 


root@MediaStore:/usr/local/emhttp# ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2001:xxxx:xxxx:xxxx::/64 dev br0 proto ra metric 216 pref medium
fd6f:3908:ee39:4000::/64 dev br0 proto ra metric 216 pref medium
fe80::/64 dev br0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev vnet0 proto kernel metric 256 pref medium
multicast ff00::/8 dev br0 proto kernel metric 256 pref medium
multicast ff00::/8 dev eth0 proto kernel metric 256 pref medium
multicast ff00::/8 dev vnet0 proto kernel metric 256 pref medium
default via fe80::ce2d:e0ff:fe50:e7b0 dev br0 proto ra metric 216 pref medium

 

 

I've reported the same earlier in the thread regarding the disk usage thresholds and incorrectly making them green. Upon 1st boot after upgrading, there were notifications from every array drive stating that the drives had returned to normal utilization. There's a note in the release notes about this stating that users not using the unRAID defaults will have to reconfigure them, but as you, I and others have found, resetting the disk usage thresholds in Disk Settings hasn't corrected the issue.

 

I and others are also seeing the IPV6 messages, but they seem pretty innocuous so not a big concern at this time. We'll get these small issues solved eventually.

 

Link to comment
3 minutes ago, AgentXXL said:

 

I've reported the same earlier in the thread regarding the disk usage thresholds and incorrectly making them green. Upon 1st boot after upgrading, there were notifications from every array drive stating that the drives had returned to normal utilization. There's a note in the release notes about this stating that users not using the unRAID defaults will have to reconfigure them, but as you, I and others have found, resetting the disk usage thresholds in Disk Settings hasn't corrected the issue.

 

I and others are also seeing the IPV6 messages, but they seem pretty innocuous so not a big concern at this time. We'll get these small issues solved eventually.

 

I was fairly sure they were getting reported properly on my first boot post upgrade, but I don't have any evidence for that.

the IPv6 is harmless, but I worry people might break their servers network connectivity (until they reboot) if they try to delete the mishandled routing lines. I didn't try since I'm doing all of this remotely without an IPMI /KVM device

Link to comment

Seems like this little change in /etc/profile by @limetech is giving some of scripts grief

# limetech - modified for unRAID 'no users' environment
export HOME=/root
cd $HOME

Its causing my scripted tmux sessions to all open (uselessly) in /root rather than in the directories I've specified.

Can we not do this?

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.

Guest
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.