6.9.0 Random Crashes/Restarts Since Upgrading


Recommended Posts

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 by Qubix1
Link to comment

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?
image.thumb.png.0c1ee877e3e3a2d9404a776c5f61fe8a.png
 

 

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:

 

Link to comment

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.

  • Like 1
Link to comment

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:

 

 

 

Link to comment
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.

  • Like 1
Link to comment

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.

  • Like 1
Link to comment

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!

Link to comment

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

 

image.png.62c37f796dc47009650395da2fd772b9.png

 

image.png.1bcb848df8617d5544c7651144424452.png

 

❤️ You bye

 

 

Link to comment
16 minutes ago, Tristankin said:

Yeah, this is definitely not my issue. I have been using /dev/shm from the beginning.
image.thumb.png.c78e21c1717e4bb654cef6996fd0902d.png
 

 

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

Link to comment

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:

 

Link to comment

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:

 

Link to comment
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.

 

image.thumb.png.e3cf48c7a74e865bfd3a6a3676b5ea84.png

 

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.

 

image.thumb.png.593c1638ce4f0bd0d5ff3fa147cd97d3.png

Edited by Vr2Io
Link to comment

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

 

image.thumb.png.e3e0af79d7ddb55a5c8793780e02477c.png

 

Still cant access by going to \\FIREFLY but the ip still works

 

Recent syslog attached

firefly-syslog-20210319-0512.zip

Link to comment

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.

 

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.