codefaux

Members
  • Content Count

    114
  • Joined

  • Last visited

  • Days Won

    1

codefaux last won the day on April 29

codefaux had the most liked content!

Community Reputation

9 Neutral

1 Follower

About codefaux

  • Rank
    Member

Converted

  • Gender
    Male
  • ICQ
    was shut down lol
  • AIM
    also sunlit
  • YIM
    doesn't even exist bro
  • MSN Messenger
    also dead. srsly?

Recent Profile Visitors

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

  1. Yes, I am well aware of the significance of VLAN 0. I'm also well aware that it happens when VLANs are enabled for an interface. However, upon reading my message, the following things stand out as unusual -- which may be why I wrote them in detail, and provided screenshots -- 1 -- There are no currently enabled interfaces with VLANs enabled so..."perfectly normal when" goes right out the window, yeah? 2 -- Before (when I was crashing) I did not have VLAN 0 messages in my log 3 -- After (now that I'm NOT crashing) I DO have VLAN 0 messages in my log
  2. That's unfortunate, I'm still stable and I really would love to help figure out how. Normally, within twenty four hours (I check my logs like ten times a day during unstable periods) I'd have one non-fatal panic attributed to the nf_nat or contrack or similar, later (several hours) followed by a metadata checksum error on a random Docker-active volume (assuming a container touched a file, kernel panic caused the thread to drop before metadata was updated, etc?) which would worsen (checksum logspam) until I got another nf_nat or similar subsystem panic which would actually be fatal
  3. I FINALLY have something I'm fully confident posting. It's been over two weeks since my last crash. I haven't seen a single panic in over a week and a half, but I DID reboot once during that time for an unrelated issue. Host Access to networks was disabled throughout; this did not improve the situation. My previous configuration used eth0 and eth1 in an Active 802.3AD bond, with Bridging enabled as well. This suffered the kernel panics described in this post. Docker containers were on dedicated IPs on interface br0. My CURRENT configuration uses eth0, Bonding off, Bridg
  4. While I understand that they are harmless and related to the Docker engine, we're also having an nf_conntrack related crash, with the Docker engine. Some of us, at least, in another thread which the devs recently mentioned that they can't reproduce. Maybe this should be looked into instead of dismissed? What is the actual location of the misconfiguration? How would one go about setting it to conform, despite it being harmless? Is this within the reach of an experienced Linux user, or is this developer land? Kernel parameters? Module parameters? Sysctl pokes? I cannot find refe
  5. @SimonF For what it's worth, my bug report is about SMART settings in smart-one.cfg being erased by a badly written config handler, any potential relation here is that my RAID controllers (and MOST RAID controllers) don't pass most SCSI Generic commands through (that's the invalid opcode stuff) and block the spindown requests. Looking at your logs, it took me about two seconds to notice that your diagnostic is absolutely massive. Syslog is bloated with messages from Docker regarding renaming interfaces, which it does on start/stop. Further inspection from your docker.txt log
  6. If your board has a dedicated management port (and you're using it) the disappearing IPMI access means the BMC died too -- BMC should run sans RAM, on most systems. Hell, the BMC in some systems will run without a CPU. The only thing I can imagine faulting the BMC and shutting down a system would be failing hardware (CPUs, motherboard, RAM, power supply, cooling) -- but even with an overheat situation, the BMC will normally stay up. I've never heard of this "3.3v electrical tape trick" and it horrifies me. Electrical tape is awful and frankly I would petition distributors to stop s
  7. Being able to connect to your domain from within the LAN but reaching your Unifi WebGUI (which I'm left to infer is what you're using for a router..? I've only ever used Unifi for Wireless AP management, so I'm left to assume A WHOLE LOT here) that means your router is not appling port forwarding to your request. This is normal behavior - you're trying to connect to your external IP from behind its router, and many, many routers handle this case exactly as they should, which is to say they silently ignore the request. Picture it like throwing a package through a window -- it shouldn't come fly
  8. This was my solution also, due to both this and a bug which eats SMART config files. 6.8.3 -- still saw one trace for nf_xxxxx but it was non-fatal and I've been stable for a week and a half ish, for the first time in kinda a while.
  9. Fair, I wasn't specific enough in that statement. Yes, that socket is only disabled when using PCIe based M.2 storage in M2_2 -- I left that unsaid since, as you also pointed out, it was already on the screen and I felt no need to handhold the information out any further. Thank you for adding to my specificity, which does not address my original point in that yours was still lacking. And perhaps it was overstated, but it's pretty clear that my point was that there is no more accurate definition of a vendor's specific implementation than their own documentation, providing the
  10. @John_M That may be factually accurate, but specifically I was quoting the breakdown the motherboard manual indicates actually reaches the PCIe slots, not hypothetically edu-guessing based on what lanes should/can be available to a chipset vendor. Implementation-derived specs are always better than application-derived specs because while any vendor can use an X470 chipset, some vendors might choose to implement PCIe lane distribution, weighting, switching, and layout in very different manners, due to differing choices in included/supported peripherals, as well as how widely they wish to implem
  11. I agree -- get your important data off. After that, even if you had to start from scratch, you didn't lose anything really painful. Regarding what's next; Parity only needs to be as large as the largest disk in your array. If you intend to step up a size in disks, Parity should/has to be increased first, but having an extra-large parity drive has no specific benefit otherwise. I suspect you knew that but I just wanted to be sure.
  12. @John_M I reviewed specification of their motherboard before I made the post. Its contents are factual for this exact context. Depending on which CPU they're using it either gets x8/x8, x8/x0 or x4/x0 depending on what CPU they have installed. If their CPU allows it, simply loading the board should have allowed it to function if it was going to. No configuration should be required within the UEFI setup. Also I didn't mention it but on this board PCIE_6 is a PCIE 2.0 x4 interface despite having an x16 physical connector, I wouldn't suggest using it for your GPU regardless of
  13. Sorry for disappearing, life has been a lot lately. I'm gonna be honest - I don't use the Unraid webUI all that much for system admin -- I'm a terminal guy. It would appear that there is no "user-facing" location to find those logs, but I could be mistaken. Samba's logs are stored in the filesystem at /var/log/samba Unbalance stored them, I believe, in /boot/logs I'm not sure where any of the other relevant logs would be kept. You mentioned using Secure for a specific folder, and that Cache is set to Yes for it. Impulsively, a part of me suspects that t
  14. It's important to understand what the options are and why. Turbo Write updates parity by reading the block from every disk in your array, doing math, then writing to parity. This requires all of your disks to be spun up. Some people run spun 24/7, some drive models will refuse to spin down, etc etc -- Turbo Write is faster but only if it doesn't have to wait for a disk to spin up. The non-Turbo write updates parity by reading the block from parity, doing math to change it to what it should be, and writing it back. This works even if most of your drives are spun down, bu
  15. Looking at your kernel logs, neither syslog nor lspci output indicate that the Linux kernel can see both devices at the same time. The output of lspci.txt shows only one GPU or the other -- not both. This means the PCI subsystem itself cannot see both devices, which points to hardware. Even using vfio hardware passthrough, lspci should still show the hardware as present. This also means something changed aside from just installing the drivers, between those boots. Drivers cannot mask hardware from the kernel. Your problem seems to be motherboard device support, physical installatio