navvy

Thanks for the help. I thought as much but figured I’d ask. I appreciate it.

Yes I’ve installed it and that was after spending time trying to get sriov operational. I’ve had sriov working on my Intel 10g nic and can’t get this igpu working the same way. After researching and finding out it was Rocket Lake, figured it might just be the plug-in assumes all 11th gen are the same. Sriov doesn’t show as a supported function in lspci. Thanks for the help.

Any chance of getting this to work on the i5 11500? According to Intel it supports GVT-g not SR-IOV.

Are you running unRAID on bare metal or as a VM under another hypervisor? Sent from my SM-G930P using Tapatalk it is running as a vm under vmware esxi v6. Then this is an issue with VMware presenting a virtual floppy disk. This doesn't appear on bare metal. Sent from my SM-G930P using Tapatalk this was never a problem with 6.2.4 and i just looked over the settings of the vm and there is no virtual floppy in any of the settings (see attached pic). Try removing the SIO Controller. It's main function is to control the virtual floppy.

I'm having the same issue. Never seen it while I was on 6.2.4 or below, just started with the 6.3.0 version. I've removed all plugins except: CA Auto Update CA Backup/Restore CA Cleanup AppData Community Applications I run a few dockers and no VMs. The ioctl(SIOCGIFHWADDR) error comes up with any web page load. I am running in a VM but haven't had any issues with that in the past. (ESXi 6.0 + vCenter 6.5) Any suggestions? I'm happy to try a few things. Cheers. edit: added diags. nas-diagnostics-20170206-2040.zip

Thanks for the answer. That all sounds good. Now my tinfoil hat can be put away again.

See, I'm guilty of having my own over-reactions too. Apologies, I think this whole topic is putting people a bit on edge. Hopefully we can get a few official answers and put this thing to bed.

I absolutely did not delete any posts. navvy I'm happy to say that I 110% don't believe trurl would ever delete a post. 13 posts and you should be able to find it, but casting aspersions on a mod who is just about as impartial a man as one could "meet" is not right. Hell he even sent all that spam to bilge rather than wiping it from the face of the earth.... i was feeling peckish and ate the posts, they looked like biscuits , but they didn't taste like them I didn't accuse him of anything. I even gave him the benefit of the doubt. I don't know trurl and made no judgement against him, I was trying to finish that part of the discussion so we could get back to the point. If my comment was taken that way I do apologise, it wasn't how it was meant. And I don't know how 13 posts is relevant. That would be a blind judgement made on your part. You know nothing about me, my experience or skill level. I think we do need to dial it back and stop leaping to conclusions. My question is still: Can we get more information about what is sent? Can we find out how/if it is stored? To me this is a bigger concern than what LT may or may not do in the future.

I absolutely did not delete any posts. Ok, so maybe it got lost in the forum shuffle. Fine. Not my main point, I still think disclosure of what information is being sent, how/where it is being stored, what it may/is being used for are reasonable questions. I think all the rhetoric would dial way back if people got a straight answer on this one.

A fair question. One Im' pretty sure has been answered long ago but I don't have the time or patience to search for it so yeah, it would be nice for LT to state it again Pretty sure this has never been answered and as I said in the other thread and it was deleted, not moved, a response on what of my data is being sent to LT and is it being stored should be the minimum response from LT. I don't think that's unreasonable.

I'm just getting very concerned that something that was never a part of the unraid licensing or feature set has been added so quickly and with almost no official comment from LT, when the community is so vocal about our concerns. It really worries me that a company that has always been so user focussed and still manages to add in kernel modules, etc. on request, has completely shutdown and not entered into the discussion. All this is going to do is continue to wear away the trust that has been solidly built over the years.

I agree. This should be LT's minimum response. The rest of the discussion can continue elsewhere.

I was affected by the Reiserfs bug and lost/couldn't trust terabytes of storage which I restored from backups. My issue isn't what LimeTech are trying to do. It is with how they've done it. Citing safety as the reason for the checkin, then forcing it on trial users using stable versions is a direct contradiction. This itself erodes trust in a brand I personally have supported, both financially and through recommendations to others. And shows the already existing ability to enable this for all users. Regardless, I don't think it is unreasonable to expect disclosure on what data is being sent and/or stored on the LimeTech servers using this new feature.

You do realise something similar also applies to trial keys right? So the step from 'only Betas and RCs' for 'safety' has already been stretched to include full version, stable, SAFE but unlicensed users. Seems like a bit of a contradiction to me already. Who's to say tomorrow they decide we've designed this great licensing system and now we're going to use it for everyone. It's only one more step! I think the announcement and implementation of this 'safety feature' was ballsed up from day one. It was handled poorly. If they're serious about implementing this, more information needs to be given especially about what is being sent and stored by the activation server. And list all the reasons for implementing, not just the 'happy friendly we're the good guys' ones.

If you tell limetech what needs to be changed to make it work, and that change doesn't interfere with running unraid on baremetal, they have been very helpful in the past in making requested changes. If you don't know or can't find out how to fix it, then chances are slim. For testing, I compiled a 4.4.6 kernel on Slackware 14.1 x64 using the standard kernel as a base. I tried passing through my SAS card and the kernel froze on boot as soon as it finished initialising. Looks like it might be a kernel problem. Not sure where to go from here. Happy to test/tryout anything. I'll have a go at trying different kernel options but it's a bit of a shot in the dark.

I know we're in the minority and running unsupported by running unRAID inside ESXi, but for me this would be a deal breaker. Hopefully it's something that can be fixed before 6.2 final. I'd really hate to lose unRAID because I need to run it inside ESXi.

I gave that a go using Australia/Sydney and Australia/Melbourne to see if it made any difference and it didn't so I thought I'd try to eliminate Unraid as the problem. I changed the windows server to save the hwclock as UTC, it still says -10 hours. (Daylight savings ended this morning.) I installed Retrospect on a clean Ubuntu install with correct time and timezone settings and it still has a 10 hour offset. It looks like retrospect has an issue with ubuntu and timezones. I might try to get onto their support and see what they say. Thanks again for your help. If I get it working, I'll upload it for the community.

Looks like it might be a retrospect bug. I connected to bash in the docker and the date and time are showing correctly.

I'll give it another go, I had the full block in and removed it to simplify the code. Thanks for the advice, I'll post back how it goes.

Sorry, probably should've been more specific. I'm testing this on Unraid v6B14b with the timezone set correctly to Melbourne. The time is correct and also points to the same NTP server as the Retrospect server. I've probably missed something simple, I just cant find it.

Hi all, Newbie here so go easy... I've been working on getting Retrospect Client to work in a docker and so far it's looking good. I've based the Dockerfile on work from Needo and gfjardim and it works fine. The client starts successfully and it's visible from the server. I just can't get the timezone correct. The Retro server says the time is off by -11:00 hours. The offset is my timezone (Melbourne, Australia) to UTC. I've tried the /etc/localtime link, and running the $TZ to /etc/localtime and dpkg-reconfigure bit too. Here's the repo I've made, https://registry.hub.docker.com/u/navvy144/retro/ , any ideas would be great.