-
Posts
224 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by bobokun
-
-
Is thelounge still being updated? I see the latest release on github is v4.4.1 but the latest docker image shows it's still on v4.3.1
-
Can you please add nvme-cli? thank you
-
I'm seeing this issue also on the latest version 6.12.3? Have either of you solve this?
-
I'm seeing these errors in my syslog recently...I'm not sure if this is a serious issue or not.
I've tried running memtest and it passed after 48hours of continuous runs.
May 22 17:25:23 unNAS kernel: zsh[18251]: segfault at 154300877e9f ip 0000154300877e9f sp 00007ffccb6ddf98 error 14 May 22 17:25:23 unNAS kernel: Code: Unable to access opcode bytes at RIP 0x154300877e75. May 22 17:25:25 unNAS kernel: show_signal_msg: 2 callbacks suppressed May 22 17:25:25 unNAS kernel: zsh[18340]: segfault at 154300877e9f ip 0000154300877e9f sp 00007ffccb6ddf98 error 14 May 22 17:25:25 unNAS kernel: Code: Unable to access opcode bytes at RIP 0x154300877e75. May 22 17:25:28 unNAS kernel: zsh[18466]: segfault at 154300877e9f ip 0000154300877e9f sp 00007ffccb6ddf98 error 14 May 22 17:25:28 unNAS kernel: Code: Unable to access opcode bytes at RIP 0x154300877e75. May 22 17:25:28 unNAS kernel: zsh[18473]: segfault at 154300877e9f ip 0000154300877e9f sp 00007ffccb6ddf98 error 14 May 22 17:25:28 unNAS kernel: Code: Unable to access opcode bytes at RIP 0x154300877e75. May 22 17:25:28 unNAS kernel: zsh[18483]: segfault at 154300877e9f ip 0000154300877e9f sp 00007ffccb6ddf98 error 14 May 22 17:25:28 unNAS kernel: Code: Unable to access opcode bytes at RIP 0x154300877e75. May 22 17:25:28 unNAS kernel: zsh[18503]: segfault at 154300877e9f ip 0000154300877e9f sp 00007ffccb6ddf98 error 14 May 22 17:25:28 unNAS kernel: Code: Unable to access opcode bytes at RIP 0x154300877e75. May 22 17:25:29 unNAS kernel: zsh[18507]: segfault at 154300877e9f ip 0000154300877e9f sp 00007ffccb6ddf98 error 14 May 22 17:25:29 unNAS kernel: Code: Unable to access opcode bytes at RIP 0x154300877e75. May 22 17:25:29 unNAS kernel: zsh[18514]: segfault at 154300877e9f ip 0000154300877e9f sp 00007ffccb6ddf98 error 14 in computil.so[1543e1657000+3000] May 22 17:25:29 unNAS kernel: Code: Unable to access opcode bytes at RIP 0x154300877e75. May 22 17:25:29 unNAS kernel: zsh[18523]: segfault at 154300877e9f ip 0000154300877e9f sp 00007ffccb6ddf98 error 14 in computil.so[1543e1657000+3000] May 22 17:25:29 unNAS kernel: Code: Unable to access opcode bytes at RIP 0x154300877e75. May 22 17:25:29 unNAS kernel: zsh[18530]: segfault at 154300877e9f ip 0000154300877e9f sp 00007ffccb6ddf98 error 14 in computil.so[1543e1657000+3000] May 22 17:25:29 unNAS kernel: Code: Unable to access opcode bytes at RIP 0x154300877e75. May 22 17:25:29 unNAS kernel: zsh[18536]: segfault at 154300877e9f ip 0000154300877e9f sp 00007ffccb6ddf98 error 14 in computil.so[1543e1657000+3000] May 22 17:25:29 unNAS kernel: Code: Unable to access opcode bytes at RIP 0x154300877e75.
-
On 2/26/2023 at 8:15 AM, Krakout said:
For me .tmux.conf did not exist for some reason, created it, echo'ed the definition and it worked fine. Thanks!
set -g default-terminal "xterm-256color"
Also works if you prefer to have color in your tmux terminal
- 1
-
Hi can I please request the tool fd to be added to nerdtools?
-
On 1/14/2023 at 10:48 AM, dlandon said:
You might try the preclear docker and see if you get different results.
Thanks! Just ran preclear again with binhex docker preclear and it all passed okay. Weird how we couldn't figure out why it wasn't working with the preclear plugin. It used to work fine before 😅.
-
I just tried to preclear a different disk and it once again also failed and got a invalid MBR signature from Unraid. Can someone verify the latest version of preclear is working with unraid 6.11.5?
-
I tried connecting the drive directly to my server rather than using the external dock and ran a preclear but it still fails at the verifying Unraid's preclear signature step. I'm not sure if there's an issue with this drive or the preclear plugin.
-
On 1/10/2023 at 11:50 AM, trurl said:
Might depend on how transparent the interface is. But since it is giving SMART reports for the disk and reporting the correct size for a standard 14TB disk I think it is probably OK.
So I ran memtest and after 8 passes I don't have any memory errors.. still not sure what the solution is.
-
I tried running preclear again on the disk and once again it failed. This is what I found in the disk log information, does it help?
Jan 7 08:58:36 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 7 08:58:36 unNAS kernel: sd 10:0:0:0: [sdl] 27344764928 512-byte logical blocks: (14.0 TB/12.7 TiB) Jan 7 08:58:36 unNAS kernel: sd 10:0:0:0: [sdl] Write Protect is off Jan 7 08:58:36 unNAS kernel: sd 10:0:0:0: [sdl] Mode Sense: 03 00 00 00 Jan 7 08:58:36 unNAS kernel: sd 10:0:0:0: [sdl] No Caching mode page found Jan 7 08:58:36 unNAS kernel: sd 10:0:0:0: [sdl] Assuming drive cache: write through Jan 7 08:58:36 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 7 08:58:36 unNAS kernel: sd 10:0:0:0: [sdl] Attached SCSI disk Jan 7 08:58:39 unNAS emhttpd: WDC_WD14_0EFGX-68B0GN0_PROLIFICMP000000001-0:0 (sdl) 512 27344764928 Jan 7 08:59:55 unNAS emhttpd: spinning up /dev/sdl Jan 7 08:59:55 unNAS emhttpd: read SMART /dev/sdl Jan 7 12:59:56 unNAS emhttpd: spinning down /dev/sdl Jan 7 15:52:06 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 7 15:52:06 unNAS kernel: sd 10:0:0:0: [sdl] 27344764928 512-byte logical blocks: (14.0 TB/12.7 TiB) Jan 7 15:52:06 unNAS kernel: sd 10:0:0:0: [sdl] Write Protect is off Jan 7 15:52:06 unNAS kernel: sd 10:0:0:0: [sdl] Mode Sense: 03 00 00 00 Jan 7 15:52:06 unNAS kernel: sd 10:0:0:0: [sdl] No Caching mode page found Jan 7 15:52:06 unNAS kernel: sd 10:0:0:0: [sdl] Assuming drive cache: write through Jan 7 15:52:06 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 7 15:52:06 unNAS kernel: sd 10:0:0:0: [sdl] Attached SCSI disk Jan 7 15:55:12 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 7 15:55:57 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 7 15:55:57 unNAS kernel: sd 10:0:0:0: [sdl] 27344764928 512-byte logical blocks: (14.0 TB/12.7 TiB) Jan 7 15:55:57 unNAS kernel: sd 10:0:0:0: [sdl] Write Protect is off Jan 7 15:55:57 unNAS kernel: sd 10:0:0:0: [sdl] Mode Sense: 03 00 00 00 Jan 7 15:55:57 unNAS kernel: sd 10:0:0:0: [sdl] No Caching mode page found Jan 7 15:55:57 unNAS kernel: sd 10:0:0:0: [sdl] Assuming drive cache: write through Jan 7 15:55:57 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 7 15:55:57 unNAS kernel: sd 10:0:0:0: [sdl] Attached SCSI disk Jan 8 08:57:02 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 8 08:57:02 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 8 11:08:05 unNAS kernel: sd 10:0:0:0: [sdl] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Jan 8 11:08:05 unNAS kernel: sd 10:0:0:0: [sdl] tag#0 Sense Key : 0x5 [current] Jan 8 11:08:05 unNAS kernel: sd 10:0:0:0: [sdl] tag#0 ASC=0x20 ASCQ=0x0 Jan 8 11:08:05 unNAS kernel: sd 10:0:0:0: [sdl] tag#0 CDB: opcode=0x8a 8a 00 00 00 00 00 c1 98 68 00 00 00 08 00 00 00 Jan 8 11:08:05 unNAS kernel: critical target error, dev sdl, sector 3247990784 op 0x1:(WRITE) flags 0x104000 phys_seg 256 prio class 0 Jan 8 11:08:05 unNAS kernel: Buffer I/O error on dev sdl, logical block 405998848, lost async page write Jan 8 11:08:05 unNAS kernel: Buffer I/O error on dev sdl, logical block 405998849, lost async page write Jan 8 11:08:05 unNAS kernel: Buffer I/O error on dev sdl, logical block 405998850, lost async page write Jan 8 11:08:05 unNAS kernel: Buffer I/O error on dev sdl, logical block 405998851, lost async page write Jan 8 11:08:05 unNAS kernel: Buffer I/O error on dev sdl, logical block 405998852, lost async page write Jan 8 11:08:05 unNAS kernel: Buffer I/O error on dev sdl, logical block 405998853, lost async page write Jan 8 11:08:05 unNAS kernel: Buffer I/O error on dev sdl, logical block 405998854, lost async page write Jan 8 11:08:05 unNAS kernel: Buffer I/O error on dev sdl, logical block 405998855, lost async page write Jan 8 11:08:05 unNAS kernel: Buffer I/O error on dev sdl, logical block 405998856, lost async page write Jan 8 11:08:05 unNAS kernel: Buffer I/O error on dev sdl, logical block 405998857, lost async page write Jan 9 08:33:06 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 9 08:34:05 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 9 08:34:06 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 9 08:34:06 unNAS kernel: sdl: sdl1 Jan 9 08:34:06 unNAS unassigned.devices: Partition 'sdl1' does not have a file system and cannot be mounted. Jan 9 08:34:07 unNAS emhttpd: read SMART /dev/sdl Jan 9 08:45:58 unNAS unassigned.devices: Removing all partitions from disk '/dev/sdl'. Jan 9 08:46:00 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 9 08:46:02 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 9 08:51:16 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 9 08:51:16 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 9 12:34:08 unNAS emhttpd: spinning down /dev/sdl Jan 10 08:27:16 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 10 08:28:16 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 10 08:28:17 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 10 08:28:17 unNAS kernel: sdl: sdl1 Jan 10 08:28:17 unNAS unassigned.devices: Partition 'sdl1' does not have a file system and cannot be mounted. Jan 10 10:16:49 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 10 10:16:49 unNAS kernel: sd 10:0:0:0: [sdl] 27344764928 512-byte logical blocks: (14.0 TB/12.7 TiB) Jan 10 10:16:49 unNAS kernel: sd 10:0:0:0: [sdl] Write Protect is off Jan 10 10:16:49 unNAS kernel: sd 10:0:0:0: [sdl] Mode Sense: 03 00 00 00 Jan 10 10:16:49 unNAS kernel: sd 10:0:0:0: [sdl] No Caching mode page found Jan 10 10:16:49 unNAS kernel: sd 10:0:0:0: [sdl] Assuming drive cache: write through Jan 10 10:16:49 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 10 10:16:49 unNAS kernel: sdl: sdl1 Jan 10 10:16:49 unNAS kernel: sd 10:0:0:0: [sdl] Attached SCSI disk Jan 10 10:16:51 unNAS unassigned.devices: Partition 'sdl1' does not have a file system and cannot be mounted. Jan 10 10:18:12 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 10 10:18:12 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 11 09:54:13 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 11 09:54:58 unNAS emhttpd: read SMART /dev/sdl Jan 11 09:55:12 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 11 09:55:13 unNAS kernel: sd 10:0:0:0: [sdl] Very big device. Trying to use READ CAPACITY(16). Jan 11 09:55:13 unNAS kernel: sdl: sdl1 Jan 11 09:55:13 unNAS unassigned.devices: Partition 'sdl1' does not have a file system and cannot be mounted. ** Press ANY KEY to close this window **
-
1 hour ago, trurl said:
Have you done memtest recently?
I did memtest maybe 1 year ago when I upgrade my RAM. Ran it for 48hours without any issues. I'm using a external HDD docking station plugged into my server via USB to do the preclear. Do you think that might be the reason?
-
30 minutes ago, trurl said:
Did you also let it do post-read verification? Doesn't look like it from the log, though I haven't precleared a disk in a long time.
The reason I ask is post-read failure can be an indication of bad RAM, since bad RAM can result in the data being changed from zero either when being written or when being read. Possibly bad RAM could have a similar effect on signature verification.
Yes I had post-read verification on but because it failed at the verifying Unraid's Signature stage it never got to the last stage.
-
I'm having some issues with preclearing a new drive that I purchased. Every time I try to preclear it always fails at the last step in verifying Unraid's signature. I'm running on the latest version of the plugin. Is my drive bad?
Running on Unraid version 6.11.5
Unassigned Devices Preclear version 2023.01.08
-
for Visual Studio Code Server does it need to be ran in Privileged mode?
-
would we be able to get powershell added as well please?
-
Is there a way to skip the Userscript from triggering if the previous run is still running? Currently it seems like the userscript will trigger a new run at the scheduled time even if the previous one is not complete.
-
Should I be using smb instead of nfs to share files between two linux servers?
-
It looks like I can't access any of my docker networks and when I look at the logs I'm seeing some weird kernel issue. Please see attached diagnostics. I can stop and start the array but it shows that my docker services failed to start and my VMs failed to start. The only way to fix this is to reboot the server.
-
I don't mind helping out with beta testing and that's why I'm here to provide any diagnostic reports when those errors do come in. So far I've tried to produce a new VM using Seabios and mode 4 rather than ovmf mode 8. Both tests have had the kernel errors. Let me know if there is anything else I should be testing.
-
Created a fresh windows VM with Seabios and mode 4, still getting the kernel errors and forcing me to hard reset my server.
-
57 minutes ago, ich777 said:
Seems like something weird is going on here, can you eventually try to setup a test VM with SeaBIOS and Machine Q35 for testing?
What type of GVT-g mode did you set? eventually try mode 8 if you have selected mode 4.
I was using mode 8, should I try mode 4?
I'll set up a seaBIOS test VM and see if it makes any difference.
- 1
-
Sure, please see attached for the diagnostics.
I've tried opening a 1080p file and 4k file in a media player inside the VM and it seems to be utilizing the CPU more than the igPU. But I do see some video decode and video processing utilization, about 20-40%
-
I tried to use parsec and when I tried to play a 4k video on youtube, I get a connection error and can't seem to connect back to the VM through parsec/VNC/RDP. Seems like it crashes the VM. I coudln't even kill the process in htop.
I couldn't access the VM page on Unraid and when I went to go into VM settings to turn off the VM using VM Manager and turn it back on I still see it stuck. I think I have to force shutdown my Unraid server. In the logs I see a bunch of kernel errors as well.
[Support] ich777 - Application Dockers
in Docker Containers
Posted
Nope, I'll switch over to another container. Np