-
schale01 started following Server becomes unresponsive
-
Server becomes unresponsive
Server becomes unresponsive after upgrading to 6.12.3. Issue was also observed on 6.12.2 and 6.12.1 as well as 6.11 reverting to 6.10 does resolve the issue. Issue occurs with little to no server load after an 12 to 24 hours. Issue appears to be repeatable when running docker container transmission with wireguard network interface. Attached debug kernal log. 2023-07-21T23:25:52-04:00 Carbon14 kernel: mdcmd (31): set md_num_stripes 1280 2023-07-21T23:25:52-04:00 Carbon14 kernel: mdcmd (32): set md_queue_limit 80 2023-07-21T23:25:52-04:00 Carbon14 kernel: mdcmd (33): set md_sync_limit 5 2023-07-21T23:25:52-04:00 Carbon14 kernel: mdcmd (34): set md_write_method 2023-07-21T23:25:52-04:00 Carbon14 kernel: mdcmd (35): start STOPPED 2023-07-21T23:25:52-04:00 Carbon14 kernel: unraid: allocating 25990K for 1280 stripes (5 disks) 2023-07-21T23:25:52-04:00 Carbon14 kernel: md1p1: running, size: 1953514552 blocks 2023-07-21T23:25:52-04:00 Carbon14 kernel: md2p1: running, size: 1953514552 blocks 2023-07-21T23:25:52-04:00 Carbon14 kernel: md3p1: running, size: 1465138552 blocks 2023-07-21T23:25:53-04:00 Carbon14 kernel: SGI XFS with ACLs, security attributes, no debug enabled 2023-07-21T23:25:53-04:00 Carbon14 kernel: XFS (md1p1): Mounting V5 Filesystem 2023-07-21T23:25:53-04:00 Carbon14 kernel: XFS (md1p1): Starting recovery (logdev: internal) 2023-07-21T23:25:53-04:00 Carbon14 kernel: XFS (md1p1): Ending recovery (logdev: internal) 2023-07-21T23:25:53-04:00 Carbon14 kernel: xfs filesystem being mounted at /mnt/disk1 supports timestamps until 2038 (0x7fffffff) 2023-07-21T23:25:53-04:00 Carbon14 kernel: XFS (md2p1): Mounting V5 Filesystem 2023-07-21T23:25:53-04:00 Carbon14 kernel: XFS (md2p1): Starting recovery (logdev: internal) 2023-07-21T23:25:53-04:00 Carbon14 kernel: XFS (md2p1): Ending recovery (logdev: internal) 2023-07-21T23:25:53-04:00 Carbon14 kernel: xfs filesystem being mounted at /mnt/disk2 supports timestamps until 2038 (0x7fffffff) 2023-07-21T23:25:54-04:00 Carbon14 kernel: XFS (md3p1): Mounting V5 Filesystem 2023-07-21T23:25:54-04:00 Carbon14 kernel: XFS (md3p1): Starting recovery (logdev: internal) 2023-07-21T23:25:54-04:00 Carbon14 kernel: XFS (md3p1): Ending recovery (logdev: internal) 2023-07-21T23:25:54-04:00 Carbon14 kernel: xfs filesystem being mounted at /mnt/disk3 supports timestamps until 2038 (0x7fffffff) 2023-07-21T23:25:55-04:00 Carbon14 kernel: BTRFS info (device nvme0n1p1): using crc32c (crc32c-intel) checksum algorithm 2023-07-21T23:25:55-04:00 Carbon14 kernel: BTRFS info (device nvme0n1p1): using free space tree 2023-07-21T23:25:55-04:00 Carbon14 kernel: BTRFS info (device nvme0n1p1): enabling ssd optimizations 2023-07-21T23:25:55-04:00 Carbon14 kernel: BTRFS info (device nvme0n1p1: state M): turning on async discard 2023-07-21T23:25:55-04:00 Carbon14 kernel: BTRFS info (device sdf1): using crc32c (crc32c-intel) checksum algorithm 2023-07-21T23:25:55-04:00 Carbon14 kernel: BTRFS info (device sdf1): using free space tree 2023-07-21T23:25:55-04:00 Carbon14 kernel: BTRFS info (device sdf1: state M): turning on async discard 2023-07-21T23:26:02-04:00 Carbon14 kernel: loop2: detected capacity change from 0 to 41943040 2023-07-21T23:26:02-04:00 Carbon14 kernel: BTRFS: device fsid 8923b5f4-d5f2-4678-b493-0ab90b7ce0be devid 1 transid 9774336 /dev/loop2 scanned by mount (9644) 2023-07-21T23:26:02-04:00 Carbon14 kernel: BTRFS info (device loop2): using crc32c (crc32c-intel) checksum algorithm 2023-07-21T23:26:02-04:00 Carbon14 kernel: BTRFS info (device loop2): using free space tree 2023-07-21T23:26:02-04:00 Carbon14 kernel: BTRFS info (device loop2): start tree-log replay 2023-07-21T23:26:02-04:00 Carbon14 kernel: BTRFS info (device loop2): checking UUID tree 2023-07-21T23:26:06-04:00 Carbon14 kernel: Bridge firewalling registered 2023-07-21T23:26:06-04:00 Carbon14 kernel: Initializing XFRM netlink socket 2023-07-21T23:26:11-04:00 Carbon14 kernel: loop3: detected capacity change from 0 to 2097152 2023-07-21T23:26:11-04:00 Carbon14 kernel: BTRFS: device fsid 5c6f5ada-a0aa-4d1b-b311-15fc6b18fb7b devid 1 transid 2064 /dev/loop3 scanned by mount (10305) 2023-07-21T23:26:11-04:00 Carbon14 kernel: BTRFS info (device loop3): using crc32c (crc32c-intel) checksum algorithm 2023-07-21T23:26:11-04:00 Carbon14 kernel: BTRFS info (device loop3): using free space tree 2023-07-21T23:26:12-04:00 Carbon14 kernel: tun: Universal TUN/TAP device driver, 1.6 2023-07-21T23:26:12-04:00 Carbon14 kernel: mdcmd (36): check correct 2023-07-21T23:26:12-04:00 Carbon14 kernel: md: recovery thread: check P ... 2023-07-21T23:26:13-04:00 Carbon14 kernel: L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details. 2023-07-21T23:26:16-04:00 Carbon14 kernel: eth0: renamed from veth6751040 2023-07-21T23:26:26-04:00 Carbon14 kernel: mdcmd (37): nocheck cancel 2023-07-21T23:26:26-04:00 Carbon14 kernel: md: recovery thread: exit status: -4 2023-07-21T23:28:05-04:00 Carbon14 kernel: br-dd02cf62dc1e: port 1(veth4aac129) entered blocking state 2023-07-21T23:28:05-04:00 Carbon14 kernel: br-dd02cf62dc1e: port 1(veth4aac129) entered disabled state 2023-07-21T23:28:05-04:00 Carbon14 kernel: device veth4aac129 entered promiscuous mode 2023-07-21T23:28:05-04:00 Carbon14 kernel: br-dd02cf62dc1e: port 1(veth4aac129) entered blocking state 2023-07-21T23:28:05-04:00 Carbon14 kernel: br-dd02cf62dc1e: port 1(veth4aac129) entered forwarding state 2023-07-21T23:28:05-04:00 Carbon14 kernel: br-dd02cf62dc1e: port 1(veth4aac129) entered disabled state 2023-07-21T23:28:07-04:00 Carbon14 kernel: eth0: renamed from vethcf3b69f 2023-07-21T23:28:07-04:00 Carbon14 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth4aac129: link becomes ready 2023-07-21T23:28:07-04:00 Carbon14 kernel: br-dd02cf62dc1e: port 1(veth4aac129) entered blocking state 2023-07-21T23:28:07-04:00 Carbon14 kernel: br-dd02cf62dc1e: port 1(veth4aac129) entered forwarding state 2023-07-21T23:28:07-04:00 Carbon14 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): br-dd02cf62dc1e: link becomes ready carbon14-diagnostics-20230722-0112.zip
-
schale01 started following MACVLan vs IPVLan a discussion.....
-
MACVLan vs IPVLan a discussion.....
After a recent upgrade to 6.11.5 I started getting server lock ups. No webgui, no ssh, no ping response, not even output from console. It seemed to happen when using apps such as Plex or transmission. Never had the issue before so I've currently rolled back to 6.10.3 and am no longer seeing issues. I'm starting to think that the recent kernel update really hates macvlan more then ever. When I have some time I'll try to update again and switch over all my Dockers to ipvlan to confirm if that was the cause.
-
-
schale01 started following OMG - 4K gaming in a VM really works! , Speedtest.net for unRAID 6.1+ , 6.4 beta? and 1 other
-
Cloudready (ChromeOS) VM
Just posting for anyone that had any trouble getting the CloudReady VM images to boot. https://neverware.zendesk.com/hc/en-us/articles/214564457--UPDATED-Un-Official-CloudReady-Virtual-Machine-Images- Convert to raw img using: tar xvf CloudReady_48.1_x64_Virtualbox.ova $ qemu-img convert -O raw CloudReady_Free_x64-disk1.vmdk CloudReady_Free_x64-disk1.img This gave me a a raw disk img with several partitions $ fdisk -l CloudReady_Free_x64-disk1.img Disk CloudReady_Free_x64-disk1.img: 16 GiB, 17179869184 bytes, 33554432 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 95B869D9-9524-604B-B8E5-E739B78E9518 Device Start End Sectors Size Type CloudReady_Free_x64-disk1.img1 64 64 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img2 65 65 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img3 66 66 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img4 67 67 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img5 68 68 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img6 69 69 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img7 70 70 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img8 71 71 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img9 72 72 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img10 73 73 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img11 74 74 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img12 75 75 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img13 76 76 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img14 77 77 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img15 78 78 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img16 14831682 33554397 18722716 8.9G Microsoft basic data CloudReady_Free_x64-disk1.img17 20546 53313 32768 16M ChromeOS kernel CloudReady_Free_x64-disk1.img18 8589378 14831681 6242304 3G ChromeOS root fs CloudReady_Free_x64-disk1.img19 53314 86081 32768 16M ChromeOS kernel CloudReady_Free_x64-disk1.img20 2347074 8589377 6242304 3G ChromeOS root fs CloudReady_Free_x64-disk1.img21 16514 16514 1 512B ChromeOS kernel CloudReady_Free_x64-disk1.img22 16515 16515 1 512B ChromeOS root fs CloudReady_Free_x64-disk1.img23 86082 2183233 2097152 1G Microsoft basic data CloudReady_Free_x64-disk1.img24 16516 16516 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img25 16517 16517 1 512B ChromeOS reserved CloudReady_Free_x64-disk1.img26 130 16513 16384 8M unknown CloudReady_Free_x64-disk1.img27 2314306 2347073 32768 16M EFI System Set XML up as follows: <domain type='kvm' id='19'> <name>ChromeOS OVMF</name> <uuid>355e8d91-618e-e9bf-5469-4440741c75ac</uuid> <metadata> <vmtemplate xmlns="unraid" name="ChromeOS" icon="chromeos.png" os="chromeos"/> </metadata> <memory unit='KiB'>4194304</memory> <currentMemory unit='KiB'>4194304</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>2</vcpu> <cputune> <vcpupin vcpu='0' cpuset='3'/> <vcpupin vcpu='1' cpuset='7'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-2.7'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/355e8d91-618e-e9bf-5469-4440741c75ac_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='1' threads='2'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/ChromeOS/CloudReady_Free_x64-disk1.img'/> <backingStore/> <target dev='hdc' bus='ide'/> <boot order='1'/> <alias name='ide0-1-0'/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <alias name='usb'/> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <alias name='usb'/> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <alias name='usb'/> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <controller type='ide' index='0'> <alias name='ide'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <interface type='bridge'> <mac address='52:54:00:bf:9d:c7'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/0'/> <target port='0'/> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/0'> <source path='/dev/pts/0'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-19-ChromeOS OVMF/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='usb'> <address type='usb' bus='0' port='2'/> </input> <input type='keyboard' bus='ps2'/> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='5900' autoport='yes' websocket='5700' listen='0.0.0.0' keymap='en-us'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </memballoon> </devices> <seclabel type='none' model='none'/> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+100</label> <imagelabel>+0:+100</imagelabel> </seclabel> </domain> Image booted. And completed Setup. I was unable to use any mouse input thru VNC. If anyone finds a fix for that let me know. EDIT: Adding an additional input type fixed the issue. <input type='mouse' bus='usb'> EDIT2: May have spoken too soon. Looks like the mouse still has an issue with offset on VNC. Investigating.
-
[Support] activ - TransmissionVPN
Anyone else having issues with downloaded files permissions. All downloads have a permissions set of -rw-r--r-- instead of -rw-rw-rw-
schale01
Members
-
Joined
-
Last visited