Jazer

Same here... anything new on this topic? 1920 is really bad for mac users, because the XDR display uses 1728 points (not pixels) in HiDPI mode.

Coming from rc5 to rc6 - my qemu vm (Hackintosh) stopped working. Execution error internal error: qemu unexpectedly closed the monitor: 2023-05-23T11:48:06.730588Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16] 2023-05-23T11:48:06.731428Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16] 2023-05-23T11:48:06.731959Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16] 2023-05-23T11:48:06.732633Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16] 2023-05-23T11:48:06.746784Z qemu-system-x86_64: -device {"driver":"virtio-9p-pci","id":"fs0","fsdev":"fsdev-fs0","mount_tag":"macos","bus":"pci.1","addr":"0x0"}: cannot initialize fsdev 'fsdev-fs0': failed to open '/mnt/user/macos': No such file or directory Any help on that?

right... turns out to be memory issues

Changed Status to Closed

Okay... some docker template files are missing. I don't know how that could happen, because I've not manipulated it manually. I guess something happend with the USB stick. Weird. Thx anyway!

I tried it... I've removed the plugin and restarted (disabled/enabled) the docker service. Same result... no update possible.

Sure... tower-diagnostics-20230415-2304.zip

The network crashed not with the first kernel panic, but with the last. Weird. syslog

Sure... tower-diagnostics-20230322-0923.zip

Firefox & Chrome - running 6.12-rc.2 Temp Values are wrong... READS / WRITES are not changing, even parity is running. Processor temp is changing, but load ist stalled.

From time to time, the dashboard is getting stalled. E.g. starting the parity sync "stops" in the dashboard after some time, but the process continues. Changes to temperature (seen on cosole) are also not reported anymore to the UI. How can I just restart the UI, without affecting the sync process?

Okay... this is somehome wired and I need a little bit assistant to provide the recomended analyze data. The problem: After unspecific time (may take days or minutes after reboot) I get a kernel panic and my unraid server crashes the network. This means - as long as my ethernet cable is plugged in, all devices to my switch are not responding (dropped connection). As soon as I disconnect the cable (or do a hard reset), my network works again. Reconnecting the cable dropps all connections again - like a short cut. root@Tower:~# Message from syslogd@Tower at Mar 22 01:13:39 ... kernel:Kernel panic - not syncing: Fatal exception in interrupt client_loop: send disconnect: Broken pipe I'm running on 6.12-rc2 for testing on a new build (never tested 6.11.x with new build). My old 6.11.x server build works fine. tower-diagnostics-20230322-0923.zip

But even if all selected, there are only two columns.

After starting unRAID, I can connect using ssh for a while. After some hours/events, I can't establish new ssh connections anymore. The logs are fine (as I can guess). Old ssh connections are not disconnect and are working properly, but new ones are timed out. I'm not sure if this is 6.12 related - I'm testing on a brand new system. Mar 19 02:18:28 Tower sshd[8630]: Connection from 192.168.188.106 port 61207 on 192.168.188.111 port 22 rdomain "" Mar 19 02:18:28 Tower sshd[8630]: Accepted key RSA SHA256:xxx found at /root/.ssh/authorized_keys:2 Mar 19 02:18:28 Tower sshd[8630]: Postponed publickey for root from 192.168.188.106 port 61207 ssh2 [preauth] Mar 19 02:18:28 Tower sshd[8630]: Accepted key RSA SHA256:xxx found at /root/.ssh/authorized_keys:2 Mar 19 02:18:28 Tower sshd[8630]: Accepted publickey for root from 192.168.188.106 port 61207 ssh2: RSA SHA256:xxx Mar 19 02:18:28 Tower sshd[8630]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Mar 19 02:18:34 Tower kernel: rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { P28191 } 5001439 jiffies s: 69 root: 0x0/T Mar 19 02:18:34 Tower kernel: rcu: blocking rcu_node structures (internal RCU debug): Mar 19 02:19:40 Tower kernel: rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { P28191 } 5066975 jiffies s: 69 root: 0x0/T Mar 19 02:19:40 Tower kernel: rcu: blocking rcu_node structures (internal RCU debug): Mar 19 02:20:28 Tower sshd[8630]: pam_elogind(sshd:session): Failed to create session: Connection timed out Mar 19 02:20:28 Tower sshd[8630]: Connection closed by 192.168.188.106 port 61207 Mar 19 02:20:28 Tower sshd[8630]: Close session: user root from 192.168.188.106 port 61207 id 0 Mar 19 02:20:28 Tower sshd[8630]: pam_unix(sshd:session): session closed for user root Mar 19 02:20:28 Tower sshd[8630]: Transferred: sent 3848, received 3884 bytes Mar 19 02:20:28 Tower sshd[8630]: Closing connection to 192.168.188.106 port 61207

Nop... that's an issue. I'm getting some panels.

Hmm... is this a bug? (using RC2) Mar 19 02:02:11 Tower kernel: rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { P28191 } 4018399 jiffies s: 69 root: 0x0/T Mar 19 02:02:11 Tower kernel: rcu: blocking rcu_node structures (internal RCU debug): Mar 19 02:02:58 Tower kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: Mar 19 02:02:58 Tower kernel: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-7): P28191/1:b..l Mar 19 02:02:58 Tower kernel: (detected by 7, t=9421862 jiffies, g=2189581, q=119216478 ncpus=8) Mar 19 02:02:58 Tower kernel: task:rsync state:D stack:0 pid:28191 ppid:28164 flags:0x00004002 Mar 19 02:02:58 Tower kernel: Call Trace: Mar 19 02:02:58 Tower kernel: <TASK> Mar 19 02:02:58 Tower kernel: __schedule+0x5a0/0x600 Mar 19 02:02:58 Tower kernel: schedule+0x8e/0xcc Mar 19 02:02:58 Tower kernel: __down_write_common+0x453/0x4e2 Mar 19 02:02:58 Tower kernel: ? writeback_single_inode+0x134/0x142 Mar 19 02:02:58 Tower kernel: fuse_flush+0xa6/0x199 Mar 19 02:02:58 Tower kernel: filp_close+0x2c/0x74 Mar 19 02:02:58 Tower kernel: put_files_struct+0x63/0xa4 Mar 19 02:02:58 Tower kernel: do_exit+0x390/0x923 Mar 19 02:02:58 Tower kernel: ? ksys_write+0x76/0xc2 Mar 19 02:02:58 Tower kernel: make_task_dead+0x11c/0x11c Mar 19 02:02:58 Tower kernel: rewind_stack_and_make_dead+0x17/0x17 Mar 19 02:02:58 Tower kernel: RIP: 0033:0x14a10aca2ba0 Mar 19 02:02:58 Tower kernel: RSP: 002b:00007ffd2d99b6a8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 Mar 19 02:02:58 Tower kernel: RAX: ffffffffffffffda RBX: 00000000005659c0 RCX: 000014a10aca2ba0 Mar 19 02:02:58 Tower kernel: RDX: 0000000000040000 RSI: 00000000005659c0 RDI: 0000000000000001 Mar 19 02:02:58 Tower kernel: RBP: 0000000000000001 R08: 000000000059d9c0 R09: 0000000000000010 Mar 19 02:02:58 Tower kernel: R10: 000000000000000f R11: 0000000000000202 R12: 0000000000040000 Mar 19 02:02:58 Tower kernel: R13: 0000000000000000 R14: 0000000000008000 R15: 0000000000d10990 Mar 19 02:02:58 Tower kernel: </TASK> Mar 19 02:03:17 Tower kernel: rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { P28191 } 4083935 jiffies s: 69 root: 0x0/T Mar 19 02:03:17 Tower kernel: rcu: blocking rcu_node structures (internal RCU debug): Mar 19 02:04:22 Tower kernel: rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { P28191 } 4149471 jiffies s: 69 root: 0x0/T Mar 19 02:04:22 Tower kernel: rcu: blocking rcu_node structures (internal RCU debug): Mar 19 02:05:28 Tower kernel: rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { P28191 } 4215007 jiffies s: 69 root: 0x0/T Mar 19 02:05:28 Tower kernel: rcu: blocking rcu_node structures (internal RCU debug): Mar 19 02:05:58 Tower kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: Mar 19 02:05:58 Tower kernel: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-7): P28191/1:b..l Mar 19 02:05:58 Tower kernel: (detected by 4, t=9601928 jiffies, g=2189581, q=125084304 ncpus=8) Mar 19 02:05:58 Tower kernel: task:rsync state:D stack:0 pid:28191 ppid:28164 flags:0x00004002 Mar 19 02:05:58 Tower kernel: Call Trace: Mar 19 02:05:58 Tower kernel: <TASK> Mar 19 02:05:58 Tower kernel: __schedule+0x5a0/0x600 Mar 19 02:05:58 Tower kernel: schedule+0x8e/0xcc Mar 19 02:05:58 Tower kernel: __down_write_common+0x453/0x4e2 Mar 19 02:05:58 Tower kernel: ? writeback_single_inode+0x134/0x142 Mar 19 02:05:58 Tower kernel: fuse_flush+0xa6/0x199 Mar 19 02:05:58 Tower kernel: filp_close+0x2c/0x74 Mar 19 02:05:58 Tower kernel: put_files_struct+0x63/0xa4 Mar 19 02:05:58 Tower kernel: do_exit+0x390/0x923 Mar 19 02:05:58 Tower kernel: ? ksys_write+0x76/0xc2 Mar 19 02:05:58 Tower kernel: make_task_dead+0x11c/0x11c Mar 19 02:05:58 Tower kernel: rewind_stack_and_make_dead+0x17/0x17 Mar 19 02:05:58 Tower kernel: RIP: 0033:0x14a10aca2ba0 Mar 19 02:05:58 Tower kernel: RSP: 002b:00007ffd2d99b6a8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 Mar 19 02:05:58 Tower kernel: RAX: ffffffffffffffda RBX: 00000000005659c0 RCX: 000014a10aca2ba0 Mar 19 02:05:58 Tower kernel: RDX: 0000000000040000 RSI: 00000000005659c0 RDI: 0000000000000001 Mar 19 02:05:58 Tower kernel: RBP: 0000000000000001 R08: 000000000059d9c0 R09: 0000000000000010 Mar 19 02:05:58 Tower kernel: R10: 000000000000000f R11: 0000000000000202 R12: 0000000000040000 Mar 19 02:05:58 Tower kernel: R13: 0000000000000000 R14: 0000000000008000 R15: 0000000000d10990 Mar 19 02:05:58 Tower kernel: </TASK>

Hey... how to apply for the beta access? I will migrate to a new server, but can keep my "old" system running - while I could use my new one for testing.

I dont have this experience... sometimes it takes 2 or 3 attempts to connect it succeeds and starts the backup. What wonders me is ... Backup cancelled (22: BACKUP_CANCELED) which seems to be a manual cancelation... I don't see these entry in my log.

I can confirm that timemachine with docker works flawless, even with mover... unless mover and tm don't run at same time.

No chance this will work relaiable... I've invested a lot of hours with diffrent settigns any non of them worked out. Now I'm giving the Timemachine Docker App a chance... and it looks very promising.

To me it seems also that having multiple timemachine backups on the same share is resposnible for this issue. Maybe also the mover mixes up stuff by destroying the integrity. I'm currently trying to use one machine per share, maybe this will be more stable. And yes - moving large amount of data (initial or large backups), lead to disconnectes.

+1 // Same here... Moved from OMV to unRAID and Timemachine is so unreliable. The good thing, I'm on a "trial" license and I will not purchase until this is fixed! Timemachine is one of the most important features for me. Any luck on fixing it?

/dev/sdc: ATA device, with non-removable media Model Number: WDC WD40EZRX-00SPEB0 Serial Number: WD-WCC4E1893XXX Firmware Revision: 80.00A80 Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0 Standards: Supported: 9 8 7 6 5 Likely used: 9 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 7814037168 Logical Sector size: 512 bytes Physical Sector size: 4096 bytes device size with M = 1024*1024: 3815447 MBytes device size with M = 1000*1000: 4000787 MBytes (4000 GB) cache/buffer size = unknown Nominal Media Rotation Rate: 5400 Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, with device specific minimum R/W multiple sector transfer: Max = 16 Current = 0 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Write cache * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * NOP cmd * DOWNLOAD_MICROCODE Power-Up In Standby feature set * SET_FEATURES required to spinup after power up SET_MAX security extension * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test * General Purpose Logging feature set * 64-bit World wide name * WRITE_UNCORRECTABLE_EXT command * {READ,WRITE}_DMA_EXT_GPL commands * Segmented DOWNLOAD_MICROCODE * Gen1 signaling speed (1.5Gb/s) * Gen2 signaling speed (3.0Gb/s) * Gen3 signaling speed (6.0Gb/s) * Native Command Queueing (NCQ) * Host-initiated interface power management * Phy event counters * NCQ priority information * READ_LOG_DMA_EXT equivalent to READ_LOG_EXT DMA Setup Auto-Activate optimization Device-initiated interface power management Software settings preservation * SMART Command Transport (SCT) feature set * SCT Write Same (AC2) * SCT Features Control (AC4) * SCT Data Tables (AC5) unknown 206[12] (vendor specific) unknown 206[13] (vendor specific) unknown 206[14] (vendor specific) Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count supported: enhanced erase more than 508min for SECURITY ERASE UNIT. more than 508min for ENHANCED SECURITY ERASE UNIT. Logical Unit WWN Device Identifier: 50014ee2b4e61XXX NAA : 5 IEEE OUI : 0014ee Unique ID : 2b4e61XXX Checksum: correct This is the result of "hdparm -I /dev/sdc" for a 3,5" WDC Drive. At least power management seems to be supported. While this is a older drive, it also doesnt work on newer WD drives.

Yeah... I know about that. Even that isn't recommended, it still works for my usecase very well. I've a internal 2TB NVME Cache, which is basicly used and the Mover pushes the files to the Array with USB HDD's from time to time. Like I said, only the Standby handling with all my WD's (different Types) wont go to sleep (or can't provide the correct status). Maybe that's a known issue or even it's not unRAID related.