Tristankin Posted March 14, 2021 Share Posted March 14, 2021 Only thing different about my setup is that I held delugevpn back as the new iptables config broke everything with my swag setup. I'm trying to get it all changed over to the new IPtables config now. Quote Link to comment
stakacs Posted March 14, 2021 Share Posted March 14, 2021 Also having daily crashes - majority of my dockers die as they lose access to shares, which are disappearing server-diagnostics-20210313-1408.zip Quote Link to comment
Qubix1 Posted March 15, 2021 Share Posted March 15, 2021 (edited) Just restarted, again. This is getting old, very tempted to just revert back to 6.8.3 until they figure this mess out. Edit: First one happened at 6:10 PM and again at 7:05 PM. I did NOT have these problems when I was testing this hardware out on the RC... Come on Limetech, some response at all to this? Edited March 15, 2021 by Qubix1 Quote Link to comment
Tristankin Posted March 15, 2021 Share Posted March 15, 2021 System hung again at about 1pm here. Nothing again in the logs, I have turned off privoxy on DelugeVPN and pushed everything through IP tables in case that was the issue. I'm at a loss at what to do. If I roll back that is a temporary fix, and not helpful for others experiencing the same issues. What do I need to do to provide enough info to get this sorted? I am really starting to worry about unexpected array errors or reduced disk life from constantly performing parity checks. Let me know what you need. Is it IPv6 config? I do not have IPv6 Enabled? Mar 15 06:59:12 Firefly crond[1743]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null Mar 15 12:15:46 Firefly kernel: veth49c1513: renamed from eth0 Mar 15 12:15:46 Firefly kernel: br-b33c13ba4d4e: port 4(veth566858e) entered disabled state Mar 15 12:15:47 Firefly kernel: br-b33c13ba4d4e: port 4(veth566858e) entered disabled state Mar 15 12:15:47 Firefly kernel: device veth566858e left promiscuous mode Mar 15 12:15:47 Firefly kernel: br-b33c13ba4d4e: port 4(veth566858e) entered disabled state Mar 15 12:15:47 Firefly kernel: br-b33c13ba4d4e: port 4(veth6f57b1d) entered blocking state Mar 15 12:15:47 Firefly kernel: br-b33c13ba4d4e: port 4(veth6f57b1d) entered disabled state Mar 15 12:15:47 Firefly kernel: device veth6f57b1d entered promiscuous mode Mar 15 12:15:47 Firefly kernel: br-b33c13ba4d4e: port 4(veth6f57b1d) entered blocking state Mar 15 12:15:47 Firefly kernel: br-b33c13ba4d4e: port 4(veth6f57b1d) entered forwarding state Mar 15 12:15:47 Firefly kernel: br-b33c13ba4d4e: port 4(veth6f57b1d) entered disabled state Mar 15 12:15:48 Firefly kernel: eth0: renamed from veth852511e Mar 15 12:15:48 Firefly kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth6f57b1d: link becomes ready Mar 15 12:15:48 Firefly kernel: br-b33c13ba4d4e: port 4(veth6f57b1d) entered blocking state Mar 15 12:15:48 Firefly kernel: br-b33c13ba4d4e: port 4(veth6f57b1d) entered forwarding state Mar 15 13:19:40 Firefly kernel: microcode: microcode updated early to revision 0xde, date = 2020-05-25 Mar 15 13:19:40 Firefly kernel: Linux version 5.10.21-Unraid (root@Develop) (gcc (GCC) 9.3.0, GNU ld version 2.33.1-slack15) #1 SMP Sun Mar 7 13:39:02 PST 2021 Mar 15 13:19:40 Firefly kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Mar 15 13:19:40 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Mar 15 13:19:40 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Mar 15 13:19:40 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Mar 15 13:19:40 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' Mar 15 13:19:40 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' Mar 15 13:19:40 Firefly kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Mar 15 13:19:40 Firefly kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 Mar 15 13:19:40 Firefly kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 Mar 15 13:19:40 Firefly kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. Mar 15 13:19:40 Firefly kernel: BIOS-provided physical RAM map: Quote Link to comment
Tuumke Posted March 15, 2021 Share Posted March 15, 2021 I just had a hang as well. Think this is the 2nd one in a weeks time after upgrading to 6.9.1 Will keep an eye out to check if this happens more often. Thing with my logs is that they start from the moment i hard reset my NAS. Quote Link to comment
Migz93 Posted March 15, 2021 Author Share Posted March 15, 2021 Quick update, currently at 5 days 13 hours uptime with no restarts/crashes. I enabled VMs Saturday evening and started up my single VM on that box. Tomorrow/Thurs I'll enable docker but without any containers and go from there. I also vaguely remember, when i was on the 6.9 betas i think my issue back then was actually a freeze like some people have reported, I'm sure i remember having to actually hold the power button to kill the whole system and then bring it back but then since 6.9 & 6.9.1 stable I haven't had to do that it's just restarting. 1 Quote Link to comment
Tristankin Posted March 15, 2021 Share Posted March 15, 2021 Another hang today... Mar 15 13:20:12 Firefly rc.docker: MQTT: started succesfully! Mar 15 13:20:12 Firefly kernel: br-b33c13ba4d4e: port 3(veth1e1571d) entered blocking state Mar 15 13:20:12 Firefly kernel: br-b33c13ba4d4e: port 3(veth1e1571d) entered disabled state Mar 15 13:20:12 Firefly kernel: device veth1e1571d entered promiscuous mode Mar 15 13:20:12 Firefly kernel: br-b33c13ba4d4e: port 3(veth1e1571d) entered blocking state Mar 15 13:20:12 Firefly kernel: br-b33c13ba4d4e: port 3(veth1e1571d) entered forwarding state Mar 15 13:20:13 Firefly kernel: br-b33c13ba4d4e: port 3(veth1e1571d) entered disabled state Mar 15 13:20:13 Firefly webGUI: Successful login user root from 192.168.1.111 Mar 15 13:20:13 Firefly kernel: eth0: renamed from veth0b9a67a Mar 15 13:20:13 Firefly kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth1e1571d: link becomes ready Mar 15 13:20:13 Firefly kernel: br-b33c13ba4d4e: port 3(veth1e1571d) entered blocking state Mar 15 13:20:13 Firefly kernel: br-b33c13ba4d4e: port 3(veth1e1571d) entered forwarding state Mar 15 13:20:13 Firefly rc.docker: organizrv2: started succesfully! Mar 15 13:20:13 Firefly kernel: br-b33c13ba4d4e: port 4(veth3465bc7) entered blocking state Mar 15 13:20:13 Firefly kernel: br-b33c13ba4d4e: port 4(veth3465bc7) entered disabled state Mar 15 13:20:13 Firefly kernel: device veth3465bc7 entered promiscuous mode Mar 15 13:20:13 Firefly kernel: br-b33c13ba4d4e: port 4(veth3465bc7) entered blocking state Mar 15 13:20:13 Firefly kernel: br-b33c13ba4d4e: port 4(veth3465bc7) entered forwarding state Mar 15 13:20:14 Firefly kernel: br-b33c13ba4d4e: port 4(veth3465bc7) entered disabled state Mar 15 13:20:14 Firefly kernel: eth0: renamed from vethcc29778 Mar 15 13:20:14 Firefly kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth3465bc7: link becomes ready Mar 15 13:20:14 Firefly kernel: br-b33c13ba4d4e: port 4(veth3465bc7) entered blocking state Mar 15 13:20:14 Firefly kernel: br-b33c13ba4d4e: port 4(veth3465bc7) entered forwarding state Mar 15 13:20:14 Firefly rc.docker: swag: started succesfully! Mar 15 13:20:16 Firefly kernel: tun: Universal TUN/TAP device driver, 1.6 Mar 15 13:20:25 Firefly nmbd[8257]: [2021/03/15 13:20:25.807488, 0] ../../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) Mar 15 13:20:25 Firefly nmbd[8257]: ***** Mar 15 13:20:25 Firefly nmbd[8257]: Mar 15 13:20:25 Firefly nmbd[8257]: Samba name server FIREFLY is now a local master browser for workgroup WORKGROUP on subnet 192.168.1.10 Mar 15 13:20:25 Firefly nmbd[8257]: Mar 15 13:20:25 Firefly nmbd[8257]: ***** Mar 15 13:20:28 Firefly kernel: mdcmd (37): nocheck Cancel Mar 15 13:20:28 Firefly kernel: md: recovery thread: exit status: -4 Mar 15 13:25:41 Firefly nmbd[8257]: [2021/03/15 13:25:41.350529, 0] ../../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) Mar 15 13:25:41 Firefly nmbd[8257]: ***** Mar 15 13:25:41 Firefly nmbd[8257]: Mar 15 13:25:41 Firefly nmbd[8257]: Samba name server FIREFLY is now a local master browser for workgroup WORKGROUP on subnet 172.18.0.1 Mar 15 13:25:41 Firefly nmbd[8257]: Mar 15 13:25:41 Firefly nmbd[8257]: ***** Mar 15 13:25:41 Firefly nmbd[8257]: [2021/03/15 13:25:41.350598, 0] ../../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) Mar 15 13:25:41 Firefly nmbd[8257]: ***** Mar 15 13:25:41 Firefly nmbd[8257]: Mar 15 13:25:41 Firefly nmbd[8257]: Samba name server FIREFLY is now a local master browser for workgroup WORKGROUP on subnet 172.17.0.1 Mar 15 13:25:41 Firefly nmbd[8257]: Mar 15 13:25:41 Firefly nmbd[8257]: ***** Mar 15 13:26:00 Firefly ntpd[1708]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Mar 15 19:21:58 Firefly kernel: microcode: microcode updated early to revision 0xde, date = 2020-05-25 Mar 15 19:21:58 Firefly kernel: Linux version 5.10.21-Unraid (root@Develop) (gcc (GCC) 9.3.0, GNU ld version 2.33.1-slack15) #1 SMP Sun Mar 7 13:39:02 PST 2021 Mar 15 19:21:58 Firefly kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Mar 15 19:21:58 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Mar 15 19:21:58 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Mar 15 19:21:58 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Mar 15 19:21:58 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' Mar 15 19:21:58 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' Mar 15 19:21:58 Firefly kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Mar 15 19:21:58 Firefly kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 Mar 15 19:21:58 Firefly kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 Mar 15 19:21:58 Firefly kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. Mar 15 19:21:58 Firefly kernel: BIOS-provided physical RAM map: Quote Link to comment
dimitriz Posted March 15, 2021 Share Posted March 15, 2021 10 hours ago, Qubix1 said: Just restarted, again. This is getting old, very tempted to just revert back to 6.8.3 until they figure this mess out. Edit: First one happened at 6:10 PM and again at 7:05 PM. I did NOT have these problems when I was testing this hardware out on the RC... Come on Limetech, some response at all to this? I did precisely that last night. Rolled back to 6.8.3, wiped my NVME cache drive (that in my case was corrupted by 6.9.X since reformatting it under that version caused same corruption) and restored my appdata folder... have been up now for 12 hours so far. No corruptions or crashes, so keeping my fingers crossed. BTW, I have tested my hardware, ran memtest, etc... no issues there from what I found so far. 1 Quote Link to comment
a_bomb Posted March 15, 2021 Share Posted March 15, 2021 I took out my GTX 1050 and a few memory sticks and I have been up for over 2 days now. Quote Link to comment
Qubix1 Posted March 16, 2021 Share Posted March 16, 2021 I had already removed my GTX 1070 and USB 3.0 card that I was passing through to a VM to try to reduce as much possibilities and it was still crashing. Was using my integrated GPU on the i7 9700k for hardware transcoding. Reverted back to 6.8.3 after the 2nd restart yesterday. System was reliably restarting every day between 5-7 PM. No restarts since. I'll wait for a new version or official word specifically addressing this issue before going back. I have too many services that people use constantly to just have my system restarting spontaneously with no warning. 1 Quote Link to comment
Tristankin Posted March 16, 2021 Share Posted March 16, 2021 I have turned off half of my docker containers to see if any of them are the culprit. I prioritised services my friends and family rely on. Here is a graphic to show what is on and off. 16 hour uptime so far... Quote Link to comment
Qubix1 Posted March 16, 2021 Share Posted March 16, 2021 I had attempted the same thing, leaving up; sonarr, radarr, sabnzbd, ombi, and plex. Kept restarting regardless. Quote Link to comment
kaymer327 Posted March 16, 2021 Share Posted March 16, 2021 I had a kernel panic last night as well. Was stable on 6.8.3 since it was released. My Flash drive went bad around the time of/during the 6.9.1 upgrade - I had replacement waiting since I've had that flash drive for a while. Replaced it with one of spaceinvaderone's recommendations (SAMSUNG BAR Plus). And all was fine for about a week. Syslog doesn't seem to have any details in it from prior to the restart to recover from the panic. Any suggestions for ensuring that logging is retained in such a scenario? Syslog server? While I understand that hardware can and does go bad - the catalyst here was the 6.9.1 upgrade. Other users are reporting similar experiences (6.8.x stable, 6.9.x kernel panics) here in the forums as well as on Reddit: https://www.reddit.com/r/unRAID/comments/m5n0za/kernel_panic_help_happens_every_few_days/ https://www.reddit.com/r/unRAID/comments/m3ncd5/weird_crash_and_lost_all_appdata/ https://www.reddit.com/r/unRAID/comments/m3n0wv/nextcloud_docker_not_working_after_crash/ So seems more like a software issue than a hardware one with multiple users reporting. Thanks for any assistance! Quote Link to comment
Tristankin Posted March 16, 2021 Share Posted March 16, 2021 Well 1 Day 10 Hour uptime with 6.9.0 and the reduced number of dockers running. I had restarts with 6.9.1 and 6.9.0 before so somehow the combination is either slowing the issue or one of the dockers I am no longer running is the culprit. Quote Link to comment
stakacs Posted March 18, 2021 Share Posted March 18, 2021 Want to start off with, I am a APE level with Unraid so take it or leave it, tell me I'm wrong ill tell you your write My server was unraveling every 3 to 10 hours, I dug around here on the forum and collected a few thoughts. 1. Cache Pool was new - I think? 2. I was rock solid on 6.8.0 for as long as it was out - Probably 1 million days uptime give or take 3. Someone somewhere was talking about having a corrupted cache after the update I decided to do a cache drive backup, then put the array in maintenance and do the old "Check Filesystem Status" which came up clean and said "Good to go buddy just send it!" then wiped it out and formatted it to XFS (have a 970 Evo Plus 2TB and dont care about pooling) Server has been up and running no problem since, 2+ days with one restart for fun I set up a bunch of plex streams to run overnight on repeat. When I woke up in the AM, I had a few streams drop out, and had alerts that my docker image was nearing full, then back to normal, then back to full again WTF mate??? I then started a few more streams, and noticed my docker image was again growing. I looked at where I had my docker pointed and there were no transcode files...Plex should be using /tmp/PlexRamScratch - which I make each time the array is started WTF mate??? This APE thought that /tmp was ram, maybe its not? smooth brain, but it definitely was not going where I wanted anyway, This nerd on another forum said to use /dev/shm and Boom goes the dynamite - Plex is no longer squatting in my docker img and is filling up ram real nice ❤️ You bye Quote Link to comment
Tristankin Posted March 18, 2021 Share Posted March 18, 2021 Yeah, this is definitely not my issue. I have been using /dev/shm from the beginning. 3 Day uptime so far, I have added SWAG back in and tomorrow I will start up hass and MQTT and see what happens. Quote Link to comment
stakacs Posted March 18, 2021 Share Posted March 18, 2021 16 minutes ago, Tristankin said: Yeah, this is definitely not my issue. I have been using /dev/shm from the beginning. 3 Day uptime so far, I have added SWAG back in and tomorrow I will start up hass and MQTT and see what happens. /tmp was just a secondary issue I found that I thought was working perfectly before, at least when I set it up and verified it at the time Wiping my cache Is what stopped my crashing as far as I can tell, I didn't have to shut down dockers or anything else. Sorry if that wasn't clear Quote Link to comment
Tristankin Posted March 18, 2021 Share Posted March 18, 2021 I'm just a little worried about formatting my cache drives if I need to roll back to 6.8.3 as they will need to have the alignment changed back for them to work again. Quote Link to comment
Tristankin Posted March 19, 2021 Share Posted March 19, 2021 OK, I have changed the cache to 1MB aligned, turned off hass and MQTT and turned on bitwarden and then a few hours later I had a crash after 3 day uptime. I have turned on all dockers except for bitwarden and will see how things go. Restart log: Mar 19 10:55:15 Firefly root: plugin: creating: /usr/local/emhttp/plugins/dynamix.unraid.net/include/cfgMigration.php - from INLINE content Mar 19 10:55:15 Firefly root: plugin: running: anonymous Mar 19 10:55:15 Firefly root: plugin: running: anonymous Mar 19 10:55:15 Firefly root: plugin: running: anonymous Mar 19 10:55:18 Firefly root: Starting unraid-api in "production" mode. Mar 19 10:55:19 Firefly root: Daemonizing process. Mar 19 10:55:19 Firefly root: Daemonized successfully! Mar 19 10:55:20 Firefly root: Starting unraid-api in "production" mode. Mar 19 10:55:21 Firefly root: Daemonizing process. Mar 19 10:55:21 Firefly root: Daemonized successfully! Mar 19 11:02:00 Firefly flash_backup: adding task: php /usr/local/emhttp/plugins/dynamix.unraid.net/include/UpdateFlashBackup.php update Mar 19 13:28:45 Firefly kernel: microcode: microcode updated early to revision 0xde, date = 2020-05-25 Mar 19 13:28:45 Firefly kernel: Linux version 5.10.19-Unraid (root@Develop) (gcc (GCC) 9.3.0, GNU ld version 2.33.1-slack15) #1 SMP Sat Feb 27 08:00:30 PST 2021 Mar 19 13:28:45 Firefly kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Mar 19 13:28:45 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Mar 19 13:28:45 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Mar 19 13:28:45 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Mar 19 13:28:45 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' Mar 19 13:28:45 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' Mar 19 13:28:45 Firefly kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Mar 19 13:28:45 Firefly kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 Mar 19 13:28:45 Firefly kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 Mar 19 13:28:45 Firefly kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. Mar 19 13:28:45 Firefly kernel: BIOS-provided physical RAM map: Quote Link to comment
Tristankin Posted March 19, 2021 Share Posted March 19, 2021 Ok, so not just bitwarden, went down again with MQTT HASS and OrganizrV2, I'm sooo bored of this and not really getting anywhere. I know its dockers, might be something to do with networking but I literally have had no feedback from the team regarding what I should be looking for or how I can get more info. Mar 19 13:30:07 Firefly kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethac2e790: link becomes ready Mar 19 13:30:07 Firefly kernel: docker0: port 3(vethac2e790) entered blocking state Mar 19 13:30:07 Firefly kernel: docker0: port 3(vethac2e790) entered forwarding state Mar 19 13:30:09 Firefly kernel: br-b33c13ba4d4e: port 3(veth778e457) entered blocking state Mar 19 13:30:09 Firefly kernel: br-b33c13ba4d4e: port 3(veth778e457) entered disabled state Mar 19 13:30:09 Firefly kernel: device veth778e457 entered promiscuous mode Mar 19 13:30:09 Firefly kernel: br-b33c13ba4d4e: port 3(veth778e457) entered blocking state Mar 19 13:30:09 Firefly kernel: br-b33c13ba4d4e: port 3(veth778e457) entered forwarding state Mar 19 13:30:09 Firefly kernel: br-b33c13ba4d4e: port 3(veth778e457) entered disabled state Mar 19 13:30:10 Firefly kernel: eth0: renamed from veth5b009f2 Mar 19 13:30:10 Firefly kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth778e457: link becomes ready Mar 19 13:30:10 Firefly kernel: br-b33c13ba4d4e: port 3(veth778e457) entered blocking state Mar 19 13:30:10 Firefly kernel: br-b33c13ba4d4e: port 3(veth778e457) entered forwarding state Mar 19 13:34:35 Firefly ntpd[1693]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Mar 19 13:34:36 Firefly nmbd[8340]: [2021/03/19 13:34:36.710929, 0] ../../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) Mar 19 13:34:36 Firefly nmbd[8340]: ***** Mar 19 13:34:36 Firefly nmbd[8340]: Mar 19 13:34:36 Firefly nmbd[8340]: Samba name server FIREFLY is now a local master browser for workgroup WORKGROUP on subnet 172.18.0.1 Mar 19 13:34:36 Firefly nmbd[8340]: Mar 19 13:34:36 Firefly nmbd[8340]: ***** Mar 19 13:34:36 Firefly nmbd[8340]: [2021/03/19 13:34:36.710995, 0] ../../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) Mar 19 13:34:36 Firefly nmbd[8340]: ***** Mar 19 13:34:36 Firefly nmbd[8340]: Mar 19 13:34:36 Firefly nmbd[8340]: Samba name server FIREFLY is now a local master browser for workgroup WORKGROUP on subnet 172.17.0.1 Mar 19 13:34:36 Firefly nmbd[8340]: Mar 19 13:34:36 Firefly nmbd[8340]: ***** Mar 19 14:18:32 Firefly kernel: microcode: microcode updated early to revision 0xde, date = 2020-05-25 Mar 19 14:18:32 Firefly kernel: Linux version 5.10.19-Unraid (root@Develop) (gcc (GCC) 9.3.0, GNU ld version 2.33.1-slack15) #1 SMP Sat Feb 27 08:00:30 PST 2021 Mar 19 14:18:32 Firefly kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Mar 19 14:18:32 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Mar 19 14:18:32 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Mar 19 14:18:32 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Mar 19 14:18:32 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' Mar 19 14:18:32 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' Mar 19 14:18:32 Firefly kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Mar 19 14:18:32 Firefly kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 Mar 19 14:18:32 Firefly kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 Mar 19 14:18:32 Firefly kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. Mar 19 14:18:32 Firefly kernel: BIOS-provided physical RAM map: Quote Link to comment
Tristankin Posted March 19, 2021 Share Posted March 19, 2021 Also why am I still getting IPV6 messages when I do not have IPV6 enabled? Quote Link to comment
Vr2Io Posted March 19, 2021 Share Posted March 19, 2021 (edited) 1 hour ago, Tristankin said: Also why am I still getting IPV6 messages when I do not have IPV6 enabled? Those shouldn't relate, I have IPv6 message too. I still think plex docker may relate. I haven't use plex. My 7x24 setup with Win10 VM + HASSIO VM + two docker, no issue. ( also no VFIO passthrough ). Other non 7x24 setup also no issue. 1 hour ago, Tristankin said: Mar 19 13:34:36 Firefly nmbd[8340]: Samba name server Next may be try stop "Samba name server", I also disable it. Edited March 19, 2021 by Vr2Io Quote Link to comment
Tristankin Posted March 19, 2021 Share Posted March 19, 2021 I was getting errors with my workgroup name length "home.ubernerd.com.au" so I changed it to workgroup. I also am not able to access my shares via the computer name \\firefly (no credentials work) and have to go to the IP directly. Mar 19 16:07:07 Firefly nmbd[22431]: [2021/03/19 16:07:07.319174, 0] ../../source3/nmbd/nmbd_workgroupdb.c:56(name_to_unstring) Mar 19 16:07:07 Firefly nmbd[22431]: name_to_nstring: workgroup name HOME.UBERNERD.COM.AU is too long. Truncating to Mar 19 16:07:17 Firefly nmbd[22431]: [2021/03/19 16:07:17.328826, 0] ../../source3/nmbd/nmbd_workgroupdb.c:56(name_to_unstring) Mar 19 16:07:17 Firefly nmbd[22431]: name_to_nstring: workgroup name HOME.UBERNERD.COM.AU is too long. Truncating to Mar 19 16:07:17 Firefly nmbd[22431]: [2021/03/19 16:07:17.328865, 0] ../../source3/nmbd/nmbd_workgroupdb.c:56(name_to_unstring) Mar 19 16:07:17 Firefly nmbd[22431]: name_to_nstring: workgroup name HOME.UBERNERD.COM.AU is too long. Truncating to I have turned off WSD NETBios and local master Still cant access by going to \\FIREFLY but the ip still works Recent syslog attached firefly-syslog-20210319-0512.zip Quote Link to comment
Tristankin Posted March 19, 2021 Share Posted March 19, 2021 OK, 3rd halt in 1 day, The system in now less stable with the cache 1MB alignment. I have paired back to the same docker containers that previously gave 3 days uptime. Is it a cache pool issue? What do I need to look for? Mar 19 16:08:36 Firefly unassigned.devices: Mounting 'Auto Mount' Remote Shares... Mar 19 16:08:36 Firefly kernel: docker0: port 1(vethe1c8de7) entered blocking state Mar 19 16:08:36 Firefly kernel: docker0: port 1(vethe1c8de7) entered disabled state Mar 19 16:08:36 Firefly kernel: device vethe1c8de7 entered promiscuous mode Mar 19 16:08:36 Firefly kernel: docker0: port 1(vethe1c8de7) entered blocking state Mar 19 16:08:36 Firefly kernel: docker0: port 1(vethe1c8de7) entered forwarding state Mar 19 16:08:36 Firefly kernel: docker0: port 1(vethe1c8de7) entered disabled state Mar 19 16:08:37 Firefly kernel: eth0: renamed from vethb11e8e3 Mar 19 16:08:37 Firefly kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethe1c8de7: link becomes ready Mar 19 16:08:37 Firefly kernel: docker0: port 1(vethe1c8de7) entered blocking state Mar 19 16:08:37 Firefly kernel: docker0: port 1(vethe1c8de7) entered forwarding state Mar 19 16:08:37 Firefly kernel: IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready Mar 19 16:08:37 Firefly rc.docker: binhex-delugevpn: started succesfully! Mar 19 16:08:37 Firefly rc.docker: binhex-jackett: started succesfully! Mar 19 16:08:38 Firefly rc.docker: binhex-plex: started succesfully! Mar 19 16:08:38 Firefly rc.docker: binhex-radarr: started succesfully! Mar 19 16:08:38 Firefly rc.docker: binhex-sonarr: started succesfully! Mar 19 16:08:38 Firefly kernel: docker0: port 2(veth705544b) entered blocking state Mar 19 16:08:38 Firefly kernel: docker0: port 2(veth705544b) entered disabled state Mar 19 16:08:38 Firefly kernel: device veth705544b entered promiscuous mode Mar 19 16:08:39 Firefly kernel: eth0: renamed from veth5e4ec31 Mar 19 16:08:39 Firefly kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth705544b: link becomes ready Mar 19 16:08:39 Firefly kernel: docker0: port 2(veth705544b) entered blocking state Mar 19 16:08:39 Firefly kernel: docker0: port 2(veth705544b) entered forwarding state Mar 19 16:08:39 Firefly rc.docker: pihole-template: started succesfully! Mar 19 16:51:44 Firefly kernel: microcode: microcode updated early to revision 0xde, date = 2020-05-25 Mar 19 16:51:44 Firefly kernel: Linux version 5.10.19-Unraid (root@Develop) (gcc (GCC) 9.3.0, GNU ld version 2.33.1-slack15) #1 SMP Sat Feb 27 08:00:30 PST 2021 Mar 19 16:51:44 Firefly kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Mar 19 16:51:44 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Mar 19 16:51:44 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Mar 19 16:51:44 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Mar 19 16:51:44 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' Mar 19 16:51:44 Firefly kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' Mar 19 16:51:44 Firefly kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Mar 19 16:51:44 Firefly kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 Mar 19 16:51:44 Firefly kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 Mar 19 16:51:44 Firefly kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. Quote Link to comment
Tristankin Posted March 19, 2021 Share Posted March 19, 2021 Might have also been the unraid API, I removed that to test aswell. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.