KptnKMan

Members
  • Posts

    190
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

KptnKMan's Achievements

Explorer

Explorer (4/14)

22

Reputation

  1. @LexBergif you're interested in doing a lot of reading around 10Gb cards, I'd recommend checking out the thread I started about this. Lots of info in there, details, links and recommendations of what I did and eventually purchased. I'm still happy with my 10Gb setup to this day.
  2. Please, I'm trying to seek some help. I have got this container running, but after setup when I got back to the login page it flashes up for a second then disappears. I've reinstalled multiple times, cleared postgres and redis, reinstalled all dependencies. I can login initially and setup Photonix, then next login the login screen flashes up for a second then disappears again. This happens from then on each time the login is accessed. The logs don't seem to show any errors, shows postgres connected. I've tried accessing from different browsers, InPrivate mode, different client workstations, same login prompt flashes up for a second then is gone. Its quite irritating and I cannot find what is the matter. Can anyone help?
  3. Sorry no, I strongly disagree with the assertion of "going bleeding edge hurt nothing". We all know clearly enough, that updating can break thing just as much as fix things... and often does introduce issues. If you need your unraid for anything more than a test/play box, then it's something we all consider when upgrading especially to dev/RC releases. The prospect of encountering issues on a working server that you need for daily functions, for the sake of "bleeding edge" is (to put it lightly) discouraging. This thread is about temperature monitors in kernel versions of unraid, so that being said, the idea of upgrading to an unraid version to maybe get a feature that you know is not in the kernel version of that release is risking a lot and frankly a bit stupid.
  4. Thanks, I appreciate you clarifying some of the key points here. I'm going to think a bit more about exactly my use case and figure out how this can be better worked into my backup plan process. I may use another tool together with this, to get 2-way syncing for some selective workflows.
  5. Hi, using the settings RCLONE_OPERATION=copy and RCLONE_DIRECTION=both I can see traffic in both directions like so: 1) new local file, copied to remote, yes. renamed file produces duplicate. 2) new remote file, copied to local, yes. renamed file produces duplicate. 3) change local file (edit txt), changes are reflected on remote, yes. 4) change remote file (edit txt), changes are NOT reflected on local, no. Changes are overwritten. This is single changes, single change at a time.
  6. Ok, I understand the risks of what you've described, but I think maybe I'm not communicating this well enough. I think I'm using the word/term "sync" loosely, so maybe I can clarify. My bad. I set the variables to RCLONE_OPERATION=copy and RCLONE_DIRECTION=both, and made 2 changes on the remote cloud side; I created a new file "dont_delete_me_please.txt" and renamed a file "rclone_test2.txt" to "rclone_test_2.txt" (added the 2nd underscore to the filename). With that logic, I expected the operation to delete the local copy of "rclone_test2.txt", then copy down "rclone_test_2.txt" and "dont_delete_me_please.txt". But I had the duplicate behaviour as shown in the screenshot. It duplicated the renamed file, and copied down the new file. But I take it that the RCLONE_OPERATION=copy behaviour will never delete anything, but only copy, which is fair enough (Is that correct?). The original issue however, was that when setting RCLONE_OPERATION=sync, it would only sync in 1 direction. So am I correct in thinking that (Assuming RCLONE_DIRECTION=both) an RCLONE_OPERATION=sync operation will copy everything in 1 direction, then copy everything (including the previous copy) in the other direction (including new duplicates)? Am I missing something?
  7. Ok, so I changed the variable RCLONE_OPERATION=sync to RCLONE_OPERATION=copy and now files are copied, but and changes are not recognised. As a result a changed file is duplicated, where the "old" (un-renamed) file is replaced and the "new" (renamed) file is synced. Any ideas?
  8. Hi, After some messing around I've got docker to connect to my OneDrive, and I'm testing syncing. However, I can only seem to sync files UP, but not DOWN, and if I add files to the folder from the OneDrive side, they are deleted. If I change something on the OneDrive side, the "new" (changed) file gets deleted, and the "old" (unchanged) file is synced back up in its place. Seems like a working 1-way sync, I'm trying to get 2-way. I've resolved all errors in the logs/reports, and the link seems to be working. Anyone know why this is happening? I have the variables set as following: RCLONE_OPERATION=sync RCLONE_DIRECTION=both
  9. Yeah that's fair enough, I didn't know if there was something else behind your comment. I suppose it is fair enough, I often think out loud as well. The script error does seem to have gone after the recreation, so I think there was a script with an "assumption" somewhere that didn't check if the bridge device existed first. it is a bit strange though. I'm not sure if I'll get to the bottom of that one, but hopefully someone can find this and it might help them in the future. I usually use notepad++ from another machine, which allows for whitespace and non-printable character detection, as I've had that annoyance before. Its a good thing to keep vigilant for, and I will do a deeper look to see if something is occurring. For now, it seems to have confirmed my suspicions that the files were created when the network configuration was modified in the GUI, but that caused a bunch of things to go wrong at the same time. It's quite sad that this doesn't want to behave with a relatively simple configuration.
  10. If the temp improvements are confirmed to be in kernel 5.16, in my opinion it doesn't seem like a good idea to upgrade just to see if it will work if 6.10rc2 is confirmed to have kernel 5.14.15. Seems like a good way to possibly create more issues (Like the share configuration being disabled/modified) where there might not be right now. I've been waiting and considering 6.10rc2 for a while, especially with the first inclusion of swTPM for Windows 11, but still I wouldn't advise upgrade without solid reasoning. Right now, I've been watching and reading to see what the reported experiences are. I know I can potentially roll back, but that's not a great plan for me personally. I need my servers, and I'm still struggling with some other unraid issues around 10Gbit networking and bonding. Honestly, I wish that kernel 5.16 would be used if that includes temp monitor updates for X570 motherboards, but that will come later for other reasons I suppose. Also, my X570-PLUS seems to work quite well. Saying that, I'm not keen to change anything, as I've done that before and lost all of my sensors. ¯\_(ツ)_/¯
  11. These are the sensors I see on the X570-PLUS: These are the sensors I see on the X570-PRO:
  12. Hi, I upgrade both my systems last week to BIOS version 4021 and I've been having the same issues. I still have working temps on the X570-PLUS and not on the X570-PRO. Seeing as they are both using the same chipset, I've been trying to copy the temp configuration from Unraid1 over to Unraid2, but I've not managed to make it work yet. I did this by copying the file /boot/config/plugins/dynamix.system.temp.plg and the contents from /boot/config/plugins/dynamix.system.temp/ to the other server. After a reboot, that didn't seem to work. If anyone has any idea how I can copy a working temp config to another server, I would be grateful.
  13. You mean beside the netboot bios? I haven't seen any delays other than that with the cards coming up, they seem to be recognised and active when Unraid boots on both servers. Yep, I'm using the dual-port SFP+ cards, and only using a single SFP+ on each card, just as you say. I'm not sure why more "ghost" ports would be registered, as I can see all 3 (Including the onboard 1Gb) listed when the system comes online. Is a ghost port something that has been observed in other uses of the Mellanox X-3 cards? Is this known behaviour with dual-port cards? The BIOS on these cards is the latest installed from the Mellanox site, installed using the Mellanox Tools for Unraid, exactly as instructed for the tools (As detailed in the GUI). Also, I have this issue on both servers where there is seemingly a skipped interface. I noticed in the network.cfg that initially there is the line for 'BONDNICS[0]'. Originally, this read as 'BONDNICS[0]="eth0 eth1 eth2 eth3"' But now it reads as 'BONDNICS[0]="eth0 eth1 eth3"' on Unraid1, and 'BONDNICS[0]="eth0 eth2 eth3"' on Unraid2. Unraid1 is where I'm having the issue where it seems to not be able to decide which interface id is being used, and lists 4 in the network-rules.cfg file. Unraid2 has not shown this particular issue. Also, this bootup error seems to have disappeared after I jumped through hoops to remove-then-re-add the br0 interface, that I mentioned above. I suspected that was related to the bridge getting messed up somehow, and that seems to have reset it. I understand that the bridge itself is also listed as a device, as basically everything is in linux. So with it being broken the startup scripts were probably either looking for it or assuming it was there? to setup the bridge and/or bond? Interestingly, this s***show began after I simply set the Interface Description. Changed nothing else. Before that I had wiped the network.cfg and network-rules.cfg files, all settings were running default, and I noted that the network.cfg file was not recreated until I set the Interface Description. As soon as I did that, everything seemed to get weird. Happened on both Unraid systems. ¯\_(ツ)_/¯
  14. So I got the br0 network interface back to a "working" state by essentially: - in settings, disabling Docker - in settings, disabling VMManager - network settings, disable bonding and bridging - reboot - fix "interface rules" duplicates manually again - confirm that everything is in correct order - reboot - fix "interface rules" again, and confirm - network settings, enable bonding and bridging - reboot - confirm settings stuck, fix "interface rules" again - confirm br0 is present and working - enable docker - enable VMManager - verify VMs work again Really not sure why that got broken. Also on Unraid1, the physical interfaces now seem to show up as eth0, eth1 and eth3. I still need to manually modify the network-rules.cfg file after each bootup, otherwise 4 interfaces show up in the "interface rules" GUI. I just encountered the same br0 missing issue on Unraid2, and resolved it following the same process above, but the interfaces are labelled the same afterward. Would really appreciate if anyone has any idea what might be happening?
  15. I started a new thread to investigate some issues I encountered today regarding more networking trouble. I can troubleshoot networking issues well enough, but Unraid configuration I'm not an expert at. Something strange is going on, and I'm really not sure why. I'd really just like to get the bond networking working stable and well so I can not have to mess with it.