unRAID OS version 6.4.0-rc8q available


384 posts in this topic Last Reply

Recommended Posts

8 hours ago, johnnie.black said:

 

One of your cache devices dropped offline, this is a hardware problem:

 


Sep  2 23:42:58 husky kernel: ata17.00: disabled

 

not sure what hardware problem there is when both ssd are/were shown and have been fine until I ran the balance command.

Link to post
  • Replies 383
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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

"rc" means "really close".

Wow......  Didn't see that coming......   Nice one guys!  

Posted Images

Just now, zoggy said:

 

not sure what hardware problem there is when both ssd are/were shown and have been fine until I ran the balance command.

 

Device dropped offline, balance will cause more activity but a disk can't drop just because of that if everything is working correctly, probably cables or the controller, since you only posted an extract I can't see if it's a SASLP or SAS2LP, but either can have issues resulting in dropped devices.

Link to post
7 hours ago, bonienl said:

The lowest fall-back you can do is entering the IP address of the server and bypass DNS. This will always work!

 

This was actually the point I was trying to make. Once you enable SSL, you can no longer access the server by IP because this:
  http://<ip>
will redirect here:
  https://<hash>.unraid.net

 

99% of the time that is exactly what you would want, the issue is if your internet is down and you can't do DNS resolution, what are the options?

Tom did a quick test and found that your browser (or router?) will cache the DNS entry so the redirect will still work during a short outage at least. For a longer outage you'd probably have to add it to a hosts file. Or modify /boot/config/ident.cfg to disable SSL

Link to post
4 minutes ago, ljm42 said:

 

This was actually the point I was trying to make. Once you enable SSL, you can no longer access the server by IP because this:
  http://<ip>
will redirect here:
  https://<hash>.unraid.net

 

99% of the time that is exactly what you would want, the issue is if your internet is down and you can't do DNS resolution, what are the options?

Tom did a quick test and found that your browser (or router?) will cache the DNS entry so the redirect will still work during a short outage at least. For a longer outage you'd probably have to add it to a hosts file. Or modify /boot/config/ident.cfg to disable SSL

 

Do: https://ip

 

Link to post
48 minutes ago, DZMM said:

ok, I'm steering well clear of the new ssl provision page until someone else smarter than me figures it out!  Just had a nightmare couple of hours after figuring out what went wrong with my RC6-->RC8 upgrade.

 

  1. went to settings/identification and thought I'd change the https port to 444 as my letsencrypt docker already using 443.  When I clicked 'done'  (not Apply) in the GUI via my W10 VM, all my VMs stopped immediately
  2. I rebooted ok and went back to the page and thought I'd brave hitting 'Provision' - same again all my VMs stopped
  3. After rebooting, I couldn't access unraid on the usual address and the xxxxxxxx.unraid.net address appeared, but it wouldn't load the dashboard.  I went to the terminal and entered the lines in the OP to reset and rebooted
  4. After rebooting, my pfSense VM now wouldn't start and was stuck in a bootloop.  Luckily I had a recent config backup from yesterday that I restored by building a new pfSense VM and then restoring the config - (I'm glad I've now tested this restore method as it was relatively painless except for waiting for the packages to download)
  5. All is good now

Not sure what happened with 1,2 and 4 but I'm going to leave it now as I've been at this too long now and I think I've got the end goal of being able to access my server from anywhere at the moment via VPN already, although a bookmark would be even nicer.

I'm not sure if the existing entries in my pfsense resolver conflicted with the recommended entry?

 

I already have:

 

server:private-address: 127.0.0.0/8
server:include: /var/unbound/pfb_dnsbl.*conf

First line is from the airvpn guide "(Copy and Paste) This setting is for DNS Rebinding | | protection in the 127.0.0.0/8 localhost zone." and the second line is added by pfBlockerNG.

 

Not sure if adding:

 

server:private-domain: "unraid.net"

conflicts??

 

Link to post
31 minutes ago, johnnie.black said:

 

Device dropped offline, balance will cause more activity but a disk can't drop just because of that if everything is working correctly, probably cables or the controller, since you only posted an extract I can't see if it's a SASLP or SAS2LP, but either can have issues resulting in dropped devices.

 

I have two SASLP cards, but I believe the cache drives (may only just be one) connects directly to the motherboard.

ran balance again with the options per help (-dconvert=raid1 -mconvert=raid1)

Balance on '/mnt/cache' is running
20 out of about 21 chunks balanced (21 considered),   5% left

just finished with:

    No balance found on '/mnt/cache'

cache size shows 38.9G now :(

 

logs:

Sep  3 11:13:32 husky ool www[17329]: /usr/local/emhttp/plugins/dynamix/scripts/btrfs_balance 'start' '/mnt/cache' '-dconvert=raid1 -mconvert=raid1'
Sep  3 11:13:32 husky kernel: BTRFS info (device sdk1): relocating block group 32568770560 flags metadata|raid1
Sep  3 11:13:32 husky kernel: BTRFS info (device sdk1): found 267 extents
Sep  3 11:13:32 husky kernel: BTRFS info (device sdk1): relocating block group 32535216128 flags system|raid1
Sep  3 11:13:32 husky kernel: BTRFS info (device sdk1): found 1 extents
Sep  3 11:13:32 husky kernel: BTRFS info (device sdk1): relocating block group 31461474304 flags data|raid1
Sep  3 11:13:33 husky kernel: BTRFS info (device sdk1): relocating block group 30387732480 flags data|raid1
Sep  3 11:13:33 husky kernel: BTRFS info (device sdk1): relocating block group 29313990656 flags data|raid1
Sep  3 11:13:51 husky kernel: BTRFS info (device sdk1): found 1742 extents
Sep  3 11:13:52 husky kernel: BTRFS info (device sdk1): found 1739 extents
Sep  3 11:13:52 husky kernel: BTRFS info (device sdk1): relocating block group 28240248832 flags data|raid1
Sep  3 11:13:53 husky kernel: BTRFS info (device sdk1): found 667 extents
Sep  3 11:13:57 husky kernel: BTRFS info (device sdk1): found 667 extents
Sep  3 11:13:57 husky kernel: BTRFS info (device sdk1): relocating block group 27166507008 flags data|raid1
Sep  3 11:13:57 husky kernel: BTRFS info (device sdk1): found 3 extents
Sep  3 11:13:58 husky kernel: BTRFS info (device sdk1): found 3 extents
Sep  3 11:13:58 husky kernel: BTRFS info (device sdk1): relocating block group 25019023360 flags data|raid1
Sep  3 11:13:58 husky kernel: BTRFS info (device sdk1): found 2 extents
Sep  3 11:13:58 husky kernel: BTRFS info (device sdk1): found 2 extents
Sep  3 11:13:58 husky kernel: BTRFS info (device sdk1): relocating block group 23945281536 flags data|raid1
Sep  3 11:13:58 husky kernel: BTRFS info (device sdk1): found 2 extents
Sep  3 11:13:59 husky kernel: BTRFS info (device sdk1): found 2 extents
Sep  3 11:13:59 husky kernel: BTRFS info (device sdk1): relocating block group 22871539712 flags data|raid1
Sep  3 11:14:02 husky kernel: BTRFS info (device sdk1): found 586 extents
Sep  3 11:14:09 husky kernel: BTRFS info (device sdk1): found 583 extents
Sep  3 11:14:09 husky kernel: BTRFS info (device sdk1): relocating block group 21797797888 flags data|raid1
Sep  3 11:14:47 husky kernel: BTRFS info (device sdk1): found 33 extents
Sep  3 11:14:49 husky kernel: BTRFS info (device sdk1): found 33 extents
Sep  3 11:14:49 husky kernel: BTRFS info (device sdk1): relocating block group 20724056064 flags data|raid1
Sep  3 11:15:21 husky kernel: BTRFS info (device sdk1): found 2331 extents
Sep  3 11:15:25 husky kernel: BTRFS info (device sdk1): found 2331 extents
Sep  3 11:15:25 husky kernel: BTRFS info (device sdk1): found 2156 extents
Sep  3 11:15:25 husky kernel: BTRFS info (device sdk1): relocating block group 19650314240 flags data|raid1
Sep  3 11:15:55 husky kernel: BTRFS info (device sdk1): found 2618 extents
Sep  3 11:16:05 husky kernel: BTRFS info (device sdk1): found 2610 extents
Sep  3 11:16:05 husky kernel: BTRFS info (device sdk1): relocating block group 18576572416 flags data|raid1
Sep  3 11:16:35 husky kernel: BTRFS info (device sdk1): found 4228 extents
Sep  3 11:16:39 husky kernel: BTRFS info (device sdk1): found 4228 extents
Sep  3 11:16:39 husky kernel: BTRFS info (device sdk1): relocating block group 12100567040 flags data|raid1
Sep  3 11:17:08 husky kernel: BTRFS info (device sdk1): found 1806 extents
Sep  3 11:17:13 husky kernel: BTRFS info (device sdk1): found 1806 extents
Sep  3 11:17:13 husky kernel: BTRFS info (device sdk1): relocating block group 11026825216 flags data
Sep  3 11:17:42 husky kernel: BTRFS info (device sdk1): found 4 extents
Sep  3 11:17:47 husky kernel: BTRFS info (device sdk1): found 4 extents
Sep  3 11:17:47 husky kernel: BTRFS info (device sdk1): relocating block group 9953083392 flags data
Sep  3 11:18:17 husky kernel: BTRFS info (device sdk1): found 4 extents
Sep  3 11:18:21 husky kernel: BTRFS info (device sdk1): found 4 extents
Sep  3 11:18:21 husky kernel: BTRFS info (device sdk1): relocating block group 8879341568 flags data
Sep  3 11:18:50 husky kernel: BTRFS info (device sdk1): found 4 extents
Sep  3 11:18:54 husky kernel: BTRFS info (device sdk1): found 4 extents
Sep  3 11:18:54 husky kernel: BTRFS info (device sdk1): relocating block group 7805599744 flags data
Sep  3 11:19:24 husky kernel: BTRFS info (device sdk1): found 4 extents
Sep  3 11:19:28 husky kernel: BTRFS info (device sdk1): found 4 extents
Sep  3 11:19:28 husky kernel: BTRFS info (device sdk1): relocating block group 6731857920 flags data
Sep  3 11:20:01 husky kernel: BTRFS info (device sdk1): found 4 extents
Sep  3 11:20:06 husky kernel: BTRFS info (device sdk1): found 4 extents
Sep  3 11:20:06 husky kernel: BTRFS info (device sdk1): relocating block group 5658116096 flags data
Sep  3 11:20:37 husky kernel: BTRFS info (device sdk1): found 4 extents
Sep  3 11:20:37 husky kernel: BTRFS info (device sdk1): found 4 extents

 

Link to post
2 hours ago, starbix said:

It is somehow related to this release, as the drive was recognised correctly in rc7a, but yes formatting was my mistake. I have accepted it now :| there was nothing too critical on that drive

Unmountable disks are not that uncommon. It is usually caused by file system corruption. Since you formatted and rebooted there is no way to get any evidence that it was related to this release, and no way to know whether it would have worked correctly if you had reverted to rc7a.

 

If you want to try to reproduce it so that we can get evidence then that would belong in this thread. Otherwise, take it to another thread or let it go.

Link to post

No problems here! Upgrading from RC7 just worked and everything is running as it should (plugins/dockers). I do not use the new UEFI boot feature though. Boot time seems normal: I can access telnet after about 60 seconds and the gui after 2 minutes. All with a dual parity array (totaling seven 8tb Hds all XFS) and an SSD cache drive. Unrelated to this upgrade, the unassinged devices plugin stll did not retain my previous settings, so i had to reshare all relevant partitions (but this happened also on previous reboots).

Link to post
44 minutes ago, zoggy said:

cache size shows 38.9G now

 

The log you posted is perfectly normal for a balance operation, you had 2 different profiles on your cache, most likely from previous times one of the devices dropped offline, if now there's only the raid1 profile it's fixed, if you have more problems start a new thread on the general support forum as your issues are unrelated to this release.

Link to post

For those of you that have un-mountable disks in this latest release, did you format the disk in UD before putting it into the array?  UD was not formatting and partitioning XFS or BTRFS disks to start at sectors 63 or 64 as unRAID requires.  I replaced my cache disk in rc7 with UD because of an error that prevented unRAID from formatting the disk.  I formatted the disk with UD and the starting sector was 2048.  I expected unRAID to force a re-format if the starting sector was not 63 or 64, but it did not.  Instead the cache disk was happily accepted and included as a new cache disk.  When I upgraded to rc8, the cache disk was un-mountable.  I rolled back to rc7 and unloaded the cache disk, upgraded to rc8 and formatted the disk and loaded it back again.

 

You can tell if you have this problem by looking at the disk settings (click on the disk name) and if you see partition format is unknown, then your partition start is not 63 or 64.

 

If is the case for you, downgrade to rc7, unload the disk that shows un-mountable, then upgrade, format the disk, and re-load the data.

Link to post
Just now, dlandon said:

For those of you that have un-mountable disks in this latest release, did you format the disk in UD before putting it into the array?  UD was not formatting and partitioning XFS or BTRFS disks to start at sectors 63 or 64 as unRAID requires.  I replaced my cache disk in rc7 with UD because of an error that prevented unRAID from formatting the disk.  I formatted the disk with UD and the starting sector was 2048.  I expected unRAID to force a re-format if the starting sector was not 63 or 64, but it did not.  Instead the cache disk was happily accepted and included as a new cache disk.  When I upgraded to rc8, the cache disk was un-mountable.  I rolled back to rc7 and unloaded the cache disk, upgraded to rc8 and formatted the disk and loaded it back again.

 

You can tell if you have this problem by looking at the disk settings (click on the disk name) and if you see partition format is unknown, then your partition start is not 63 or 64.

 

If is the case for you, downgrade to rc7, unload the disk that shows un-mountable, then upgrade, format the disk, and re-load the data.

 

Partition format is unknown for me on an XFS file system on my cache drive.  I'll fallback to rc7 and reformat.

Link to post

I suspect that a lot of these issues with un-mountable disks is from formatting and partitioning with UD and unRAID accepting the partitioning when it doesn't start on sector 63 or 64.  I've changed UD to format xfs and btrfs disks with the proper starting sector based on the unRAID default setting.

Link to post
1 minute ago, smdion said:

 

That very possible.  Its been a while; so can't say 100%, but thats a high probability. 

At least you now know what the problem is and how to solve it.  It's not really difficult, but took me hours yesterday to unload and re-load 400GB of data from my cache drive.

Link to post
Just now, dlandon said:

At least you now know what the problem is and how to solve it.  It's not really difficult, but took me hours yesterday to unload and re-load 400GB of data from my cache drive.

Yep.. in process now. Will update shortly.  Thanks @dlandon

Link to post
3 minutes ago, starbix said:

I'm pretty sure I didn't format my drive using the UD plugin, I did however format it in rc7a

That may be another issue.  I wasn't able to get unRAID to format my new cache disk, so there may have been issues with the format for you.

Link to post
1 hour ago, dlandon said:

For those of you that have un-mountable disks in this latest release, did you format the disk in UD before putting it into the array?  UD was not formatting and partitioning XFS or BTRFS disks to start at sectors 63 or 64 as unRAID requires.  I replaced my cache disk in rc7 with UD because of an error that prevented unRAID from formatting the disk.  I formatted the disk with UD and the starting sector was 2048.  I expected unRAID to force a re-format if the starting sector was not 63 or 64, but it did not.  Instead the cache disk was happily accepted and included as a new cache disk.  When I upgraded to rc8, the cache disk was un-mountable.  I rolled back to rc7 and unloaded the cache disk, upgraded to rc8 and formatted the disk and loaded it back again.

 

You can tell if you have this problem by looking at the disk settings (click on the disk name) and if you see partition format is unknown, then your partition start is not 63 or 64.

 

If is the case for you, downgrade to rc7, unload the disk that shows un-mountable, then upgrade, format the disk, and re-load the data.

Thanks for the info. I had the same problem. On this release, cache drive showed as an invalid partition. SSD formatted in XFS. I think I originally formatted with UD before putting it in.

I have rolled back to the previous release and now am backing up the cache and will then reformat as you suggest then upgrade :)

Link to post
Guest
This topic is now closed to further replies.