unRAID Server Release 6.0-beta13-x86_64 Available


limetech

Recommended Posts

Well apcupsd is right now the only one for which you've added the package to the default install. That is what makes it "special" and why there is a reasonable argument to be made for a note saying, "if you don't listen to us about removing all your other plugins before upgrading, you should listen to us about this."

 

This isn't official support, this is noting a problem you KNOW people will have because, supported or not, people are using apcupsd and a change you made is now "known" to cause issues and you know how to prevent it. That is distinctly different than asking you to make a note about every possible unofficial plug-in that isn't essential to the safe operation of a unRaid ... something I don't think you can successfully argue about apcupsd.

 

But I could also see your argument that people should be removing them all, period, no quarter given :)

 

Just another thought for the little it is worth.

 

The intent was for apcupsd webGui plugin to be included in the build, but we removed because we haven't completed it's testing and we didn't want to delay this release even more.  Right we didn't explicitly test the public plugin, thinking it should have worked - all that should have happened was the plugin noticed the package was already installed, and just skip that and move on.  But I forgot we rebuilt apcupsd package to be more secure by making a slight change in /etc/apc*.conf to have it listen only on localhost instead of all interfaces.  So yeah, this one slipped through, but that's why there are betas right?  Pretty sure we're going to move to closed betas for 6.1.

 

awe come on now ... closed betas are no fun :(

 

And I understand how it happened now, but all I've ever been saying, about this and the other "issue" was that as these issues are identified as reasonably valid, or as in this case there is a specific method to help you identify and/or validate the issue, that it gets posted to the OP especially when it has even the wiff of a potential to risk data. 99% of the time you guys wouldn't have had to do anything in past betas, but this beta shows that you might consider a reasonable policy of updating the OP as the beta is shaken out. It isn't like you aren't giving advice in the thread, but in some cases it just needs to be added to the OP.

Link to comment
  • Replies 239
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

(I haven't read all 9 pages yet)

 

All kinds of Docker problems though.  I had issues with running into the max container size but it wouldn't let me increase it.  So, I nuked the docker .img and now I can't restart the service.

In summary, LT pulled beta 13 and we are now awaiting beta 14 because of some cache drive issues.  But, I'm still sitting on b13 because those issues don't affect me.  To get docker working, you might want to go to the flash drive, navigate to config/plugins/dockerMan, and delete the .tgz files which are in there.  Then reboot.  Should work after that
Link to comment

But I forgot we rebuilt apcupsd package to be more secure by making a slight change in /etc/apc*.conf to have it listen only on localhost instead of all interfaces.

 

I hope you are not talking about restricting the "Network Information Server" from listing to the lan port.  I currently have unRaid as the server and my PC and Router as clients as they all use the same UPS.  I want unRaid to shutdown if there is a power outage.  My server runs 24/7/365 and with a directly connected usb cable is not relying on another PC to initiate a shutdown.

 

If my router gets corrupted, I can always reload it.  If my PC is on, I am probably here and can manually shut it down.  So I want to keep using unRaid as the server vs being a client.  If it is merely editing a configuration file, I can do that but would prefer to have it work out of the box as it does today and as the source does.  If it has to be set of as a default, how about a config setting on the plugin to enable listing to other ports.

Link to comment

But I forgot we rebuilt apcupsd package to be more secure by making a slight change in /etc/apc*.conf to have it listen only on localhost instead of all interfaces.

 

I hope you are not talking about restricting the "Network Information Server" from listing to the lan port.  I currently have unRaid as the server and my PC and Router as clients as they all use the same UPS.  I want unRaid to shutdown if there is a power outage.  My server runs 24/7/365 and with a directly connected usb cable is not relying on another PC to initiate a shutdown.

 

If my router gets corrupted, I can always reload it.  If my PC is on, I am probably here and can manually shut it down.  So I want to keep using unRaid as the server vs being a client.  If it is merely editing a configuration file, I can do that but would prefer to have it work out of the box as it does today and as the source does.  If it has to be set of as a default, how about a config setting on the plugin to enable listing to other ports.

 

Yes that's the change we made to the apcupsd package, the NIS service only listens on 127.0.0.1 now instead of 0.0.0.0 by default.  (Config file: /etc/apcupsd/apcupsd.conf).

 

We'll probably make this a config option on the webGui but our intentions were to lock this down by default. 

Link to comment
I hope you are not talking about restricting the "Network Information Server" from listing to the lan port.

 

This is exactly what has been done. Edits to the .conf file do not survive a reboot.  I'm very grateful to dlandon - he added the auto-edit (presumably using sed) to the current version of the apcupsd plugin within minutes of being made aware of the issue.

Link to comment

Is there a recommended way of formatting cache to get it working again? And is this advisable or will such formatting break again in a future update?

 

If b14 doesn't appear by the weekend, I'd like to reformat and restore VMs from backup as it seems reverting to b12 won't solve the problem.

 

Thanks

 

Link to comment

After upgrading to -beta13 if your cache disk now appears 'unformatted', please do not run file system check or scrub, or reformat.  Instead please capture the system log without rebooting and post here.  Probably what's happening is this: those who experience this issue have probably manually partitioned their cache disk, or perhaps partitioned and built file system on some other linux distro.  I need to know if this is the case before implementing a fix.  thx

 

This should be in the OP.

 

In general every single thing we work out should be put in the OP. user should not be expected to read hundreds of posts :)

Not until its confirmed.

 

Just a point of note that as a policy if something needs confirmed then it should still be added to the OP as "possible" and needing confirmed". Users should not be required to read hundreds of posts and decide if something is important thats our job.

 

The plugin manager really needs to verify that the update is ok by checking an md5sum. My update got corrupted and I had to update the USB manually.

 

Absolutely this is essential Can you open a bug report please.

 

[sigh] Just so I understand, you're telling me that it is a "theory" to tell people, "if you experience any problem with drives showing as unformatted, DO NOT TR Y TO FIX IT, and send us a syslog"

I see what you're getting at. Will address when I get to the office.

 

Hey Jonp

 

I see you added this to the OP, but don't see any reference to the apcupsd piece (you need to remove from 12 before upgrading to 13). This should likely be noted as well to save people headaches.

 

Probably not the right place for it.  We do not officially support this feature just yet.  We are getting ready to, but anyone that's getting ahead of us and using community work here is really on their own.  This isn't an issue of us not caring, it's us not being able to keep track of each community work that gets affected through each release in our beta.  If we do it for APCUPSd, why wouldn't we have to do this for other plugins then?

 

To me this suggests that perhaps the right place for this is wiki where the community can work on "extended" release note not beholdent on LT making it formal by adding to the OP.

 

Otherwise its just kinda sucky that known issues could hit users after they have been reported.

 

 

Link to comment

I updated from 6beta10a. I used the link that was posted in the beta12 thread. When the server rebooted and I checked the server was on beta13. I don't use a cache pool. Is it still advisable to upgrade to beta14?

Since beta 14 is not yet available then upgrading might be difficult :)

 

As long as your cache disk not show up as unformatted on the reboot then I think the issue that is pushing for a quick turnaround to beta 14 will not affect you (it did not affect me).

 

Obviously when beta 14 IS available you should upgrade to that release just in case there are any other fixes incorporated other than the one around the cache disk.

Link to comment

For the record, updated my server and it came up all A-OK.

 

Had the double click update issue.

 

I've been running a docker image for months so this copy on write business probably effects me so I'll keep an eye out for a solution (rather not rebuild the image) unless it'll come back just as it was before.

 

Not checked the spin down of my green drives as of yet.

Link to comment

hi all, i updated yesterday to beta13 and now i have write permission errors with mac (error -36). after the error the shares and the guy is unresponsable.

how can i do a dump or log, so that you can help me?

 

thank you all in advance

What were you updating from?

 

Have you tried running the new Permission utility - this often fixes permissions issues.

 

You should provide a syslog to help others with diagnosing your problems.

Link to comment

i updated from beta12. the think is, the GUI is also unresponsive when i access only one share.

i updated through the GUI and cleared the browser cache. what is the command to do the fix permissions in screen? it looks like the smb daemon is crashing and there is no new log file…

 

all i can do is poweroff with the button, not even ssh and powerdown / reboot is working. the server doesn't react to it.

 

 

hi all, i updated yesterday to beta13 and now i have write permission errors with mac (error -36). after the error the shares and the guy is unresponsable.

how can i do a dump or log, so that you can help me?

 

thank you all in advance

What were you updating from?

 

Have you tried running the new Permission utility - this often fixes permissions issues.

Link to comment

i'm running newperm and (hopefully) parity check (which process shows this?)

i can access with ssh, but the gui is still not available. how can i parse the log live? (so i don't have to attach a monitor)

OK - earlier you said ssh was not working!

 

The log is at /var/logs/syslog.  You could examine it using a command like:

less /var/logs/syslog

I often run a command like

tail -n 1000 -f /var/logs/syslog

if I want to see updates as they happen.

You could also copy it to the flash drive using

cp /var/logs/syslog /bootcode]

Link to comment

sorry for the mistake. logs are in /var/log. here is the result.

 

maybe this is the interesting part:

...

Feb 18 13:10:16 r5-server avahi-daemon[7042]: Service "r5-server" (/services/smb.service) successfully established.

Feb 18 13:10:18 r5-server kernel: ------------[ cut here ]------------

Feb 18 13:10:18 r5-server kernel: kernel BUG at fs/btrfs/inode.c:3123!

Feb 18 13:10:18 r5-server kernel: invalid opcode: 0000 [#1] SMP

Feb 18 13:10:18 r5-server kernel: Modules linked in: md_mod coretemp nct6775 hwmon_vid i2c_i801 e1000e ptp ahci pps_core libahci [last unloaded: md_mod]

Feb 18 13:10:18 r5-server kernel: CPU: 3 PID: 10483 Comm: btrfs-cleaner Not tainted 3.18.5-unRAID #2

Feb 18 13:10:18 r5-server kernel: Hardware name: System manufacturer System Product Name/P8P67 PRO, BIOS 1502 03/02/2011

Feb 18 13:10:18 r5-server kernel: task: ffff88031b719830 ti: ffff8802eef44000 task.ti: ffff8802eef44000

Feb 18 13:10:18 r5-server kernel: RIP: 0010:[<ffffffff812cce1e>]  [<ffffffff812cce1e>] btrfs_orphan_add+0xc8/0x15d

Feb 18 13:10:18 r5-server kernel: RSP: 0018:ffff8802eef47c58  EFLAGS: 00010286

Feb 18 13:10:18 r5-server kernel: RAX: 00000000ffffffe4 RBX: ffff88031aa1e800 RCX: 0000000000000000

Feb 18 13:10:18 r5-server kernel: RDX: 0000000001200120 RSI: 0000000000040000 RDI: ffff88031df45138

Feb 18 13:10:18 r5-server kernel: RBP: ffff8802eef47c98 R08: ffff88032f7bcb10 R09: 0000160000000000

Feb 18 13:10:18 r5-server kernel: R10: 0000160000000000 R11: 000000ffffffffff R12: ffff88031c91a020

Feb 18 13:10:18 r5-server kernel: R13: ffff8800ca1a6000 R14: 0000000000000001 R15: 0000000000000001

Feb 18 13:10:18 r5-server kernel: FS:  0000000000000000(0000) GS:ffff88032f580000(0000) knlGS:0000000000000000

Feb 18 13:10:18 r5-server kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

Feb 18 13:10:18 r5-server kernel: CR2: 00000000006e4c88 CR3: 0000000001807000 CR4: 00000000000407e0

Feb 18 13:10:18 r5-server kernel: Stack:

Feb 18 13:10:18 r5-server kernel: ffff8802eef47c98 ffff88031aa1ec58 0000160000000000 ffff880307f8a600

Feb 18 13:10:18 r5-server kernel: ffff88031b3b5800 ffff8800ca179000 ffff88031c91a020 ffff8800ca1a6000

Feb 18 13:10:18 r5-server kernel: ffff8802eef47d28 ffffffff812ba667 ffff8800ca179004 ffff8800ca179000

Feb 18 13:10:18 r5-server kernel: Call Trace:

Feb 18 13:10:18 r5-server kernel: [<ffffffff812ba667>] btrfs_remove_block_group+0x11b/0x484

Feb 18 13:10:18 r5-server kernel: [<ffffffff812e8e33>] btrfs_remove_chunk+0x589/0x600

Feb 18 13:10:18 r5-server kernel: [<ffffffff812dec20>] ? free_extent_state.part.26+0x34/0x38

Feb 18 13:10:18 r5-server kernel: [<ffffffff812defe4>] ? free_extent_state+0x15/0x17

Feb 18 13:10:18 r5-server kernel: [<ffffffff812bab9b>] btrfs_delete_unused_bgs+0x1cb/0x207

Feb 18 13:10:18 r5-server kernel: [<ffffffff812c09a2>] cleaner_kthread+0x11b/0x14a

Feb 18 13:10:18 r5-server kernel: [<ffffffff812c0887>] ? btrfs_destroy_pinned_extent+0x9a/0x9a

Feb 18 13:10:18 r5-server kernel: [<ffffffff81057486>] kthread+0xd6/0xde

Feb 18 13:10:18 r5-server kernel: [<ffffffff810573b0>] ? kthread_create_on_node+0x172/0x172

Feb 18 13:10:18 r5-server kernel: [<ffffffff815fd17c>] ret_from_fork+0x7c/0xb0

Feb 18 13:10:18 r5-server kernel: [<ffffffff810573b0>] ? kthread_create_on_node+0x172/0x172

Feb 18 13:10:18 r5-server kernel: Code: 01 72 08 41 be 01 00 00 00 eb 03 45 31 f6 48 8b 7d c8 e8 6b fd 32 00 45 85 f6 74 11 4c 89 e6 4c 89 ef e8 6c 7e fe ff 85 c0 74 02 <0f> 0b 41 ff cf 75 76 49 8b 94 24 68 fe ff ff 48 85 d2 74 0b 41

Feb 18 13:10:18 r5-server kernel: RIP  [<ffffffff812cce1e>] btrfs_orphan_add+0xc8/0x15d

Feb 18 13:10:18 r5-server kernel: RSP <ffff8802eef47c58>

Feb 18 13:10:18 r5-server kernel: ---[ end trace df0ae2be634703fc ]---

...

 

another one:

Feb 18 15:46:27 r5-server kernel: ------------[ cut here ]------------

Feb 18 15:46:27 r5-server kernel: kernel BUG at fs/btrfs/inode.c:3123!

Feb 18 15:46:27 r5-server kernel: invalid opcode: 0000 [#1] SMP

Feb 18 15:46:27 r5-server kernel: Modules linked in: md_mod coretemp nct6775 hwmon_vid i2c_i801 e1000e ahci ptp libahci pps_core [last unloaded: md_mod]

Feb 18 15:46:27 r5-server kernel: CPU: 2 PID: 13250 Comm: btrfs-cleaner Not tainted 3.18.5-unRAID #2

Feb 18 15:46:27 r5-server kernel: Hardware name: System manufacturer System Product Name/P8P67 PRO, BIOS 1502 03/02/2011

Feb 18 15:46:27 r5-server kernel: task: ffff8803072a9830 ti: ffff8802eed0c000 task.ti: ffff8802eed0c000

Feb 18 15:46:27 r5-server kernel: RIP: 0010:[<ffffffff812cce1e>]  [<ffffffff812cce1e>] btrfs_orphan_add+0xc8/0x15d

Feb 18 15:46:27 r5-server kernel: RSP: 0018:ffff8802eed0fc58  EFLAGS: 00010286

Feb 18 15:46:27 r5-server kernel: RAX: 00000000ffffffe4 RBX: ffff88031af6e800 RCX: 0000000000000000

Feb 18 15:46:27 r5-server kernel: RDX: 0000000000d000d0 RSI: 0000000000040000 RDI: ffff8800bf04d138

Feb 18 15:46:27 r5-server kernel: RBP: ffff8802eed0fc98 R08: ffff88032f7a7b10 R09: 0000160000000000

Feb 18 15:46:27 r5-server kernel: R10: 0000160000000000 R11: 000000ffffffffff R12: ffff88031c96cd10

Feb 18 15:46:27 r5-server kernel: R13: ffff88031c99e000 R14: 0000000000000001 R15: 0000000000000001

Feb 18 15:46:27 r5-server kernel: FS:  0000000000000000(0000) GS:ffff88032f500000(0000) knlGS:0000000000000000

Feb 18 15:46:27 r5-server kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

Feb 18 15:46:27 r5-server kernel: CR2: 00000000006e4c88 CR3: 0000000001807000 CR4: 00000000000407e0

Feb 18 15:46:27 r5-server kernel: Stack:

Feb 18 15:46:27 r5-server kernel: ffff8802eed0fc98 ffff88031af6ec58 0000000000000000 ffff88031d16b800

Feb 18 15:46:27 r5-server kernel: ffff88031afc9800 ffff88031c998090 ffff88031c96cd10 ffff88031c99e000

Feb 18 15:46:27 r5-server kernel: ffff8802eed0fd28 ffffffff812ba667 ffff88031c998094 ffff88031c998090

Feb 18 15:46:27 r5-server kernel: Call Trace:

Feb 18 15:46:27 r5-server kernel: [<ffffffff812ba667>] btrfs_remove_block_group+0x11b/0x484

Feb 18 15:46:27 r5-server kernel: [<ffffffff812e8e33>] btrfs_remove_chunk+0x589/0x600

Feb 18 15:46:27 r5-server kernel: [<ffffffff812dec20>] ? free_extent_state.part.26+0x34/0x38

Feb 18 15:46:27 r5-server kernel: [<ffffffff812defe4>] ? free_extent_state+0x15/0x17

Feb 18 15:46:27 r5-server kernel: [<ffffffff812bab9b>] btrfs_delete_unused_bgs+0x1cb/0x207

Feb 18 15:46:27 r5-server kernel: [<ffffffff812c09a2>] cleaner_kthread+0x11b/0x14a

Feb 18 15:46:27 r5-server kernel: [<ffffffff812c0887>] ? btrfs_destroy_pinned_extent+0x9a/0x9a

Feb 18 15:46:27 r5-server kernel: [<ffffffff81057486>] kthread+0xd6/0xde

Feb 18 15:46:27 r5-server kernel: [<ffffffff810573b0>] ? kthread_create_on_node+0x172/0x172

Feb 18 15:46:27 r5-server kernel: [<ffffffff815fd17c>] ret_from_fork+0x7c/0xb0

Feb 18 15:46:27 r5-server kernel: [<ffffffff810573b0>] ? kthread_create_on_node+0x172/0x172

Feb 18 15:46:27 r5-server kernel: Code: 01 72 08 41 be 01 00 00 00 eb 03 45 31 f6 48 8b 7d c8 e8 6b fd 32 00 45 85 f6 74 11 4c 89 e6 4c 89 ef e8 6c 7e fe ff 85 c0 74 02 <0f> 0b 41 ff cf 75 76 49 8b 94 24 68 fe ff ff 48 85 d2 74 0b 41

Feb 18 15:46:27 r5-server kernel: RIP  [<ffffffff812cce1e>] btrfs_orphan_add+0xc8/0x15d

Feb 18 15:46:27 r5-server kernel: RSP <ffff8802eed0fc58>

Feb 18 15:46:27 r5-server kernel: ---[ end trace 78760967cfd76fbb ]---

 

can i downgrade to beta12? am i affected by the cache drive format problem? because i didn't format the drive outside the normal procedure. it looks like the system is running and acting fine when i disable the cache drive and start the array

log_6beta13.txt

Link to comment

I was wondering if the problem was BTRFS related!  There have been reports that those who encountered problems with BTRFS formatted cache drives have not fixed the issue by going back to B12, which is why Limetech are meant to be rushing out a B14 to fix issues in this area.  However whether this will help with your issue I have no idea.

 

You mention that your cache disk is BTRFS formatted?  Is there a reason for this (e.g. drive pooling, TRIM support for SSD) or is it just a legacy of the fact that at one point it was a requirement for docker support.  If it was the latter then it might be worth switching to XFS as that seems to be the most stable option.

 

One recovery path might be to see if you can mount the cache disk outside the array to copy off any files you need.  Once that is done you could remove the current partitions and add it back to unRAID as a cache disk to be reformatted, and having done that copy back any files you want back there.

Link to comment

I tried mounting my "unformatted" cache outside of the array on another linux box and it was unmountable.  After that  I tried to revive it using reiserfsrhk.  I was then able to mount the drive but all the files were unreadable. Fortunately I had backed up my VM the day before.

If you have a backup then I would follow the suggestion of switching to XFS as that seems to be the most stable option.
Link to comment

For the record, updated my server and it came up all A-OK.

 

Had the double click update issue.

 

I've been running a docker image for months so this copy on write business probably effects me so I'll keep an eye out for a solution (rather not rebuild the image) unless it'll come back just as it was before.

 

Not checked the spin down of my green drives as of yet.

 

Just an FYI on this, I posted a more detailed response about the COW bug related to the Docker image in the defect reports thread here:  http://lime-technology.com/forum/index.php?topic=36273.msg353919#msg353919

 

This issue is resolved in beta13 by setting a nodatacow flag on the btrfs loopback image file itself.  However, this will require the recreation of your Docker image file in order for the bug to be resolved.  Existing image files created from earlier betas will still be subject to this bug should the parent disk device the image resides on fill up with data.  For these reasons, we highly encourage users to delete and recreate their docker image file from beta13 or later.

 

NOTE:  THIS ONLY APPLIES IF YOUR DOCKER IMAGE FILE RESIDES ON A DEVICE FORMATTED WITH BTRFS!  If your Docker image file is located on a non-btrfs device, you should not be impacted by this issue.

 

However, in the rare event that recreating your image would be too large to ask, and you wish to continue the use of your existing image file as it is today, you can potentially protect yourself from future corruption by moving the image file from it's current location off to a secondary device that is NOT formatted with the btrfs filesystem.  If you wish to then return the image to the btrfs-formatted device, those comfortable with command line tools can connect via telnet / ssh and perform the following:

 

1)  Create a new directory on your btrfs-formatted disk device.

 

mkdir tmp

 

2)  Apply the nodatacow flag to the folder.

 

chattr +C -R tmp

 

3)  Move the docker image file from your non-btrfs disk to this tmp folder.

 

mv /mnt/path/to/docker.img /mnt/path/to/tmp/

 

4)  To confirm that the nodatacow flag is appropriately listed on your file, you can type the following command from within the tmp directory you created:

 

lasttr

 

If you see a C at the end of the attributes for the image file, that means you set the flag correctly.

 

In theory, if your image didn't already have corrupted bits, doing this will prevent further corruption in the future, but this is only theory and not proven.

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.