warpspeed
Members
-
Joined
Everything posted by warpspeed
-
is it just me or is there a large number of issues coming up with the most recent upgrades relating to disk mounting issues due to corruption or mismatched partition records or similar... I wonder if there are some proactive/preventative checks/scans that could be done ahead of upgrading, that might help identify, mitigate or correct these sorts of things before people upgrade and find out the hard way... e.g. file system checks in maintenance mode? or similar?
-
Only four votes so far! Would have thought folks would be a little more enthusiastic to share. I'm curious whether there are perhaps some stats like this that Lime Tech could share with us... obviously not numbers, but it'd be interesting to see the percentages of what versions people are running - if they have that.
-
Just curious what everyone's favourite/preferred/safe unraid version currently is. I've set the poll for 1 week.
-
I'm on 6.12.10 right now, and I installed the plugin and installed the patch a few days ago. Overnight last night I got a notification of a critical update, this morning I went in and checked and it said I already had it installed. Notification: Critical Update: 26-01-2025 04:30 AM Critical Update Available Critical Updates Are Available For Your Unraid Server Tool: No new patches found! The following patches are already installed and will be reinstalled automatically when your server boots 1.0.0 Notes This patch fixes a subset of known security issues. For more information see this blog post. Bug Fixes Fix Reflected XSS issues in 6.12.10 Interestingly syslog even identifies that it was already installed: Jan 26 04:30:01 unraid root: Checking for patches for OS version 6.12.10 Jan 26 04:30:02 unraid root: Skipping 20250118234703-pr243.patch-- Already installed
-
Edit: re-posted in the correct thread:
-
EDIT: I see the date request is already being discussed, so.... +1 to whatever can be done there --------------- Feature request: Please update the date/time preference to use the regional settings of the server. I get a US date format for the last updated and it bends my brain because it's backward. Talking about this: "Last refresh at 1/23/2025, 20:13:50" It'd be nice to see that formatted as Last refresh: <date according to servers region setting>, <time according to servers time setting> If that's not possible, it'd be great if we could have basic date formats as preferences (DD/MM/YYYY, MM/DD/YYYY, YYYY-MM-DD, etc.) Thanks
-
Does this version have all the same NFS fixes as 7.0?
-
If the plugin is part of the unraid official repos now then for consistency and security, shouldn't any URL calls use official unraid URLs, not random third party domains.
-
In relation to this thread: and this one: and my comment here: So while what I noted above seemed to solve that problem. Yesterday I had an issue where my Ubuntu VM seemed to become partially unresponsive while doing various things over NFS (sab downloading). Several hours later, I tried to figure out what was going on as several things on the VM were unhappy. I ended up rebooting it. Then tried to load a Unraid NFS share via autofs. Whenever I did this, it'd just lock up and not mount or anything. No error logs on either side. I tried restarting NFS and RPC on unraid, that didn't help. I shut all my VMs down then tried to stop the array to try a reboot. The array hung trying to unmount /mnt/user I ran lsof and found that the 'shfs' process was holding a couple of files open on /mnt/cache and another share. I did a 'kill <pid of shfs>' and then the unmount proceeded to happen correctly. I rebooted the server, and now everything is okay again. Except the files that were being manipulated at the time over NFS are either zero file size or didn't get recreated. Previously on 6.12.10 my server has been rock solid for weeks. I upgraded to 6.12.14 2 days ago and the up time was about 2 days. This is the first time i've ever seen an error like this. It seems like sab running inside the ubuntu vm, with all of its data directories mounted over NFS had a sad related to NFS.... This is from the syslog of the vm (I cannot find anything else related in unraid logs or anywhere else: Dec 07 19:46:39 <vm hostname> kernel: INFO: task sab********:4126 blocked for more than 122 seconds. Dec 07 19:46:39 <vm hostname> kernel: Not tainted 6.8.0-45-generic #45~22.04.1-Ubuntu Dec 07 19:46:39 <vm hostname> kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Dec 07 19:46:39 <vm hostname> kernel: task:sab******** state:D stack:0 pid:4126 tgid:4094 ppid:1 flags:0x00000002 Dec 07 19:46:39 <vm hostname> kernel: Call Trace: Dec 07 19:46:39 <vm hostname> kernel: <TASK> Dec 07 19:46:39 <vm hostname> kernel: __schedule+0x27c/0x6a0 Dec 07 19:46:39 <vm hostname> kernel: ? nfs_pageio_complete+0xee/0x140 [nfs] Dec 07 19:46:39 <vm hostname> kernel: schedule+0x33/0x110 Dec 07 19:46:39 <vm hostname> kernel: io_schedule+0x46/0x80 Dec 07 19:46:39 <vm hostname> kernel: folio_wait_bit_common+0x136/0x330 Dec 07 19:46:39 <vm hostname> kernel: ? __pfx_wake_page_function+0x10/0x10 Dec 07 19:46:39 <vm hostname> kernel: folio_wait_bit+0x18/0x30 Dec 07 19:46:39 <vm hostname> kernel: folio_wait_writeback+0x2b/0xa0 Dec 07 19:46:39 <vm hostname> kernel: __filemap_fdatawait_range+0x93/0x110 Dec 07 19:46:39 <vm hostname> kernel: filemap_write_and_wait_range+0x94/0xc0 Dec 07 19:46:39 <vm hostname> kernel: nfs_wb_all+0x27/0x130 [nfs] Dec 07 19:46:39 <vm hostname> kernel: nfs4_file_flush+0x7e/0xe0 [nfsv4] Dec 07 19:46:39 <vm hostname> kernel: filp_flush+0x35/0x90 Dec 07 19:46:39 <vm hostname> kernel: __x64_sys_close+0x34/0x90 Dec 07 19:46:39 <vm hostname> kernel: x64_sys_call+0x1a20/0x24b0 Dec 07 19:46:39 <vm hostname> kernel: do_syscall_64+0x81/0x170 Dec 07 19:46:39 <vm hostname> kernel: ? do_syscall_64+0x8d/0x170 Dec 07 19:46:39 <vm hostname> kernel: ? syscall_exit_to_user_mode+0x86/0x260 Dec 07 19:46:39 <vm hostname> kernel: ? do_syscall_64+0x8d/0x170 Dec 07 19:46:39 <vm hostname> kernel: ? do_syscall_64+0x8d/0x170 Dec 07 19:46:39 <vm hostname> kernel: ? clear_bhb_loop+0x15/0x70 Dec 07 19:46:39 <vm hostname> kernel: ? clear_bhb_loop+0x15/0x70 Dec 07 19:46:39 <vm hostname> kernel: ? clear_bhb_loop+0x15/0x70 Dec 07 19:46:39 <vm hostname> kernel: entry_SYSCALL_64_after_hwframe+0x78/0x80 Dec 07 19:46:39 <vm hostname> kernel: RIP: 0033:0x7c085ef14f8b Dec 07 19:46:39 <vm hostname> kernel: RSP: 002b:00007c0838bff4a0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 Dec 07 19:46:39 <vm hostname> kernel: RAX: ffffffffffffffda RBX: 00005cc6f79e8130 RCX: 00007c085ef14f8b Dec 07 19:46:39 <vm hostname> kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000001d Dec 07 19:46:39 <vm hostname> kernel: RBP: 00005cc6f79e8130 R08: 0000000000000000 R09: 0000000000000000 Dec 07 19:46:39 <vm hostname> kernel: R10: 00005cc6f69d47c0 R11: 0000000000000293 R12: 000000000000001d Dec 07 19:46:39 <vm hostname> kernel: R13: 00007c0838bff500 R14: 0000000000000000 R15: 0000000000000000 Dec 07 19:46:39 <vm hostname> kernel: </TASK> NFS share mounted from the vm to unraid with these options in autofs config: -users,rw,auto,noatime,async,hard,rsize=32768,wsize=32768,fstype=nfs4 I looked through all the log files on unraid and couldn't find anything untoward about this issue aside from shfs stuck with some files open while unmounting. After rebooting unraid everything came up happy again, but I think I'm going to downgrade again back to 6.12.10.
-
Relevant when going 6.12.10 to 6.12.14 - problem still exists, likely solution included:
-
Just checking the release notes, no particular fixes for the NFS issues a bunch of folks have been experiencing on the recent 6.12 series? e.g. no mention of this
-
That's interesting. I didn't need to do that. I just needed to make sure the bios settings for the iGPU were set to turn it on. I have remote console and iGPU working fine on an X13SAE-F.
-
6.12.13 came with Kernel 6.1.106. 6.1 is now up to 6.1.114. There have been a bunch of NFS changes in 6.1.107, 110, 111, and 113. It'd be great to see another point release for 6.12, with (in the least) a kernel update to see if it resolves the NFS issues. Here's all the NFS changes since 6.12.13 (6.1.106). 6.1.107 Jeff Layton (1): nfsd: drop the nfsd_put helper NeilBrown (6): NFS: avoid infinite loop in pnfs_update_layout. nfsd: Simplify code around svc_exit_thread() call in nfsd() nfsd: separate nfsd_last_thread() from nfsd_put() NFSD: simplify error paths in nfsd_svc() nfsd: call nfsd_last_thread() before final nfsd_put() nfsd: don't call locks_release_private() twice concurrently 6.1.110 Trond Myklebust (1): NFSv4: Add missing rescheduling points in nfs_client_return_marked_delegations 6.1.111 Trond Myklebust (2): NFSv4: Fix clearing of layout segments in layoutreturn NFS: Avoid unnecessary rescanning of the per-server delegation list 6.1.113 Chuck Lever (3): fs: Create a generic is_dot_dotdot() utility NFSD: Fix NFSv4's PUTPUBFH operation NFSD: Mark filecache "down" if init fails Guoqing Jiang (2): nfsd: call cache_put if xdr_reserve_space returns NULL Jeff Layton (2): nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire nfsd: fix refcount leak when file is unhashed after being found Li Lingfeng (3): nfsd: return -EINVAL when namelen is 0 nfs: fix memory leak in error path of nfs4_do_reclaim nfsd: map the EBADMSG to nfserr_io to avoid warning NeilBrown (1): nfsd: fix delegation_blocked() to block correctly for at least 30 seconds Yanjun Zhang (1): NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()
-
Yep, had this too, reported it. Doesn't seem to have gotten anywhere. I'm sitting on 6.12.10. On 6.12.10 I get occasional issues with some files, but it mostly works fine. 6.12.11 it won't even connect. Here's some existing threads:
-
Are there any issues with moving from the Docker instance of Tailscale to the plugin? I currently use the Docker version and it works just fine.
-
With Tailscale being integrated into Unraid, does that mean it'll still stay in the Plugin, or is it going to be fully integrated? I ask because right now, anything integrated into the OS, only gets updated when the OS gets updated. And then, if folks have issues with a release, they have to hold back. If Tailscale is completely integrated into the OS, then Tailscale will only be updated when the OS is updated. That would be a regression from today's plugin/docker approaches where they can be updated independently of the OS releases.
-
Good idea, I definitely could do that. But I'd prefer not to as it's high traffic and I'd rather it not loop through my subnet routers.
-
Thanks, in regards to 1. I would do that but the config files only accept IP addresses. In regards to 2. I wasn't aware we could do that now, must be a recent new Tailscale feature - that'd certainly solve my problem then. Thanks!
-
Yes aware of that, that's why I posted in here. There are still a number of outstanding impacting bugs in 6.12 that are preventing folks from running the latest version. And there's been no news or discussion of any further bug fix updates for 6.12 in over a month. The issue is, if 7 comes out now and has a whole swag of new issues because it's a major update, that then leaves everyone still on 6.12, stuck where they are. It would be good to see the outstanding bugs in 6.12 addressed so that 6.12 ends up very stable and folks can confidently run the latest version of that, before 7 gets released. Otherwise it also makes updating harder, as the normal update mechanism will want to shift everyone to v7.
-
Are we going to get a 6.12 bugfix release before 7.x is released. 6.12 bug fixes seem to have gone quiet and many of us are sitting on earlier releases due to bugs.
-
Is there a way to switch from this docker to the plugin without changing Tailscale creds and IP? I have been using this docker and I have external services that depend on the Tailscale IP. It's not going to be particularly easy to switch from one to the other without breaking connectivity for some remote services.
-
Yes, you need to do it using ipmitool on the command line e.g. ipmitool -I lan -U USERNAME -P PASSWORD -H IP_ADDRESS sensor thresh CPU_FAN1 lower 120 220 320 ipmitool -I lan -U USERNAME -P PASSWORD -H IP_ADDRESS sensor thresh CPU_FAN1 upper 1600 1700 1800
-
BTW, I'm using this motherboard now, it works fine.
-
I have the same board, I had similar issues. You need to adjust the thresholds lower, and also not set the low end PWM percentage too low. YMMV.
-
In neither the 6.12.12 or 6.12.13 release notes is there any mention (except the start/stop array issue) of the NFS issues that various folks were experiencing in 6.12.11 - not noted as an issue, or a workaround, or whether addressed in the update. If they haven't been addressed, the least I'd have expected is a note that there may be issues with NFS. Though I thought I saw a partial workaround in one of the threads too. I'm referring to these threads:
