physikal

@KluthR Any info you can provide here? Thanks!

I'm actually having the same exact problem as you. Any chance you found a resolution to it? Thanks!

Ok ty. I'll reboot it and see if that helps. Thanks!

I tried that and it didn't seem to fix it. I did uninstall it via going to plugins, selecting it, then clicking remove. Then I reinstalled it via the dropdown/popup from the right. That should be good right?

I'm experiencing something different. First the myserver plugin was logged out, but now when I attempt to re-sign in it's telling me the login and password is wrong. But I know it's right because I can login to the website and check myservers where it says mine is signed out. It's very odd.

Is this the case if I was to upgrade to a NEWER SuperMicro 24 bay server, from an older supermicro 24 bay server? Is it as simple as shutting the server down, pulling all the drives and putting them in the same physical location in the new server and moving the USB drive? Thanks!

I am getting similar errors and am curious if this is your issue.

This is the result: Phase 1 - find and verify superblock... - block cache size set to 8461064 entries Phase 2 - using internal log - zero log... zero_log: head block 1998769 tail block 1998769 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 bad CRC for inode 5967449771 bad CRC for inode 5967449771, would rewrite Bad atime nsec 2173239295 on inode 5967449771, would reset to zero would have cleared inode 5967449771 - agno = 3 - agno = 4 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 4 - agno = 3 - agno = 1 - agno = 5 bad CRC for inode 5967449771, would rewrite Bad atime nsec 2173239295 on inode 5967449771, would reset to zero would have cleared inode 5967449771 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Tue Aug 30 20:34:12 2022 Phase Start End Duration Phase 1: 08/30 20:32:49 08/30 20:32:49 Phase 2: 08/30 20:32:49 08/30 20:32:58 9 seconds Phase 3: 08/30 20:32:58 08/30 20:33:54 56 seconds Phase 4: 08/30 20:33:54 08/30 20:33:55 1 second Phase 5: Skipped Phase 6: 08/30 20:33:55 08/30 20:34:12 17 seconds Phase 7: 08/30 20:34:12 08/30 20:34:12 Total run time: 1 minute, 23 seconds

Thank you so much for your help. I'll do that asap.

Disc4 is rebuilding because it was a drive that was running crazy hot (up to 54c) so I replaced it with a newer drive that I think would (and is) running cooler. I'm starting to wonder if temp was a reason for the kernel panic. So it was more of a preventative thing. Only my UnraidOS is running on USB. Correct - nothing assigned to disc 7-10. Thanks!

Alright here are the diags. tower-diagnostics-20220828-0833.zip

Roger that. As soon as I get home I will.

I know it says unmount and repair but unmount what?

Anyone else getting the error: ERROR contact:service ping satellite failed {"Satellite ID":

Thank you!

Ok good to know. Are these trim errors going to blow anything up in the future? or it's just saying it's unable to trim and going from there? Also, someone in another thread recommended installing one of these: Amazon.com: I/O CREST 2 Port SATA III PCI-e 2.0 x1 Controller Card Asmedia ASM1061 Non-Raid with Low Profile Bracket SY-PEX40039: Electronics and plugging the drives into that. If I shut the server down completely and install this, then move the drives to this...will that destroy my array because I moved the cache drives? Or will unraid detect all that on it's own? Or should I go through the process of completely moving cache to array, removing cache drives, shut down, install card, plug drives into the card, boot back up and reconfigure cache? Thanks for the quick response!

I'm actually running into this same exact problem...if connecting to SATA ports isn't an option do I need to switch back to spinning disks for my cache instead of SSD's? Or can the SSD's run fine w/o trim?

I am experiencing this same issue.

Any chance the jar file issue will be resolved? @hernandito

Any thoughts on creating a container for this? https://github.com/upfiring/upfiring-update/releases Hope all is well @Jcloud !

It's just really odd that it's showing as it came from an old IP address I had assigned via my ISP. Not an internal address.

yeah doing this now, thanks a ton for the info. I'm also rebuilding any old VM's I had that were hosting game servers under that 50.106.16.89 ISP assigned address. I'm also digging through my FW to see if I can get a mac address of that address being used internally and seeing if it matches any of my mac addresses on my internal network. Wish I had a clear smoking gun on which machine was compromised.

also I should clarify, blue means closed. So it confirmed closed.

But it's port 179? And I have no vmware installs in my home lab.

Just these