Kaldek

Members
  • Posts

    55
  • Joined

  • Last visited

Everything posted by Kaldek

  1. Perhaps the better question is whether Limetech are aware they are actively being probed to find a way in. It happened to Solarwinds, it can happen here. It's just way too easy to do this stuff and is asymmetric warfare. We get one chance to detect the breach whilst the attacker has unlimited time to perfect it by finding even the remotest weakness and using that as the beachhead.
  2. As someone whose full time job is InfoSec for a multinational, I need to reply here. Saying not to expose stuff to the Internet is obvious but it doesn't remove the problem. The biggest concern I have with unRAID is a supply chain attack, and unRAID is popular enough now that e-Crime actors will already be looking at targeting the platform. The question is this: who validates all the plugins etc to make sure they don't have malicious code in them or the ability to subsequently download malicious payloads? Never mind Docker or VMs, those are the responsibility of the end user - period. The risk is going to come from the commonly used plugins that everyone uses: Unassigned Devices Nvidia Fix Common Problems Nerd Tools Preclear disks etc So, what's Limetech's response? Better to get ahead of this before it actually happens. if the risk lies with the end user for 3rd party plugins the link to this in customer agreements need to be pointed out.
  3. My server using an Intel dual-port 10Gb XFP NIC is routinely removing the driver with the following syslog message which removes all network connectivity. Mar 17 08:18:19 MU-TH-UR kernel: ixgbe 0000:03:00.0: Adapter removed Mar 17 08:18:19 MU-TH-UR kernel: ixgbe 0000:03:00.0: Warning firmware error detected FWSM: 0xFFFFFFFF I have serial console and local access so I am at least able to bounce the server to bring it back. Diagnostics file attached. Not sure what to do here as I cannot find any references to firmware error 0xFFFFFFFF and can only find references to error 0x0118801B and 0x00000000. I note the driver used in 6.9.1 is Intel version 5.10.21 and there is a 5.11.3 available which mentions "bug fixes" (no details provided). mu-th-ur-diagnostics-20210317-0927.zip
  4. If @ich777 is responsible for this part of unRAID I'd say they'll be working on a fix ASAP. They already provided a permanent fix for Nvidia drivers.
  5. That's what the "modprobe i915" does - it loads the module.
  6. @ich777 I can confirm this update fixes the issue for me. For anyone who's rebooting their server remotely, you can tell if the permanent fix (the update to the nvidia plugin) worked just by running "nvidia-smi" at a terminal prompt. If it's working you will see Xorg running as a process on the GPU:
  7. @ich777 I have confirmed this works. Thanks, I'll happily wait for the fix.
  8. Removing nvidia-plugin made mine work. Reinstalling it however just brought back the issue.
  9. Small amount of progress here. I removed the nvidia plugin and rebooted and was greeted with a Local GUI. Re-installed the Nvidia plugin and rebooted, only to lose the local GUI again.
  10. I tried using "nomodeset" with the append command at boot, it had no effect. For what it's worth I'm running an Nvidia Quadro P400 on a system with no on board video. (EVGA X99 Micro2 and Xeon E5-2630L). Also updated to 6.9.1, no effect.
  11. That's great but how do we find out which plugin? I mean, I was running 6.9.0-rc2 for months without issue and suddenly 6.9.0 has a problem. It's not like I've added some wacky plugin that behaves badly. I'm used to being able to diagnosing stuff in Linux log files. I've searched syslog and can't find anything, and I'm not sure where else I can look.
  12. No. I use IOMMU groups and pass through devices to VMs so I use legacy boot.
  13. OK I've now also tried rolling back to an earlier nvidia driver, and disabling driver patching for multiple streams. No effect, still no local GUI.
  14. Safe mode GUI boot brought it back for me. Tried some additional things to see if they affected it when not in Safe mode: Disabled all VMs Disabled all Docker Containers None of those affected the behaviour. I can try rolling back to an older Nvidia driver too. What would you like next, a list of plugins?
  15. I have the same problem. Upgraded from 6.9.0-rc2 to 6.9.0 and no local GUI with just a flashing cursor. No X environment loaded as best I can tell. My own diagnostics attached: mu-th-ur-diagnostics-20210307-2214.zip
  16. That's literally the reason I'm setting it up. The rest of unRAID is fine - I just have the occasional OVA that refuses to run as a KVM VM.
  17. So folks I'm also trying to do this on ESXi v7.0.0 and for some reason I cannot for the life of me send any kind of large data transfer to the ESXi server. Anything at high speed just dies. I can open SSH sessions, I can browse to the server, but as soon as I try to push a VMDK file or anything big the write speeds just halt and the network disconnects me. Anyone got any ideas here? This is using vmxnet3 NIC for management. It is definitely not a storage issue as I have tried multiple datastores - some are virtual images on the unRAID cache drive, some are virtual images on the array. So, it's definitely a network issue. Update: So, I can push data via IPv6 but not IPv4? Huh? More investigation required...
  18. I agree with this. I recently went back to unBALANCE and went to move half of my videos folder (just movies) from my current Videos drive to the other three, with an expectation it would do what unRAID shares does - try to balance how much of a disk is used (depending on settings of course). It is, really, a "fill up each disk in sequence" effort rather than a re-balance. So, now I'm gathering everything back onto my Videos drive and will have to manually balance my existing content by creating a new share and copying everything to the new share to let unRAID manage the disk usage balancing. When finished, I'll have to rename the shares.
  19. OK, yeah I think I'm just lacking in caffeine this morning. It's no different in functionality to if I had a two drive array (one parity, one data). It's still "parity" even though it might be conceptually similar to RAID1 (in that only two disks are taking part in the resiliency for this particular data). I don't think I'd ever recommend that anyone visualised it that way. It's just helped me wrap my head around what I saw.
  20. It took me a while to wrap my head around that but I think I get it. What I think you're saying is: All disks are involved in parity calculations for the first 4TB Only the parity drive and 8TB drive are involved in parity calculations for the last 4TB. Does that therefore mean that for the last 4TB of the 8TB drive, it's not technically parity but rather a bit mirror? And that if I added another 8TB drive to my array it would switch from a bit mirror to actual parity? I think I might be mentally barking up the wrong tree here
  21. Hi folks, I am hoping someone to clarify the behaviour of my parity check behaviour. My setup is as follows: Parity: WD 8TB CMR Disks 1-3: WD 4TB CMR Most shares. All shares use Disks 1-3 only and Disk 4 is excluded for these shares. Disk 4: Seagate 8TB SMR Video Share (only the Video share, no other shares. Disks 1-3 are excluded for this share) I split Disk 4 off for Videos because it's slower and I don't mind if this disk is the one which is mostly spun up (the other shares aren't used as much) because it reduces power consumption by only having one disk spinning. Anyway when the parity check is running it starts out like the first image here where all disks are being checked: Then it changes to the following behaviour for the last 40% or so where only the 8TB disk is being checked: I'm sure this is normal, but why?
  22. Ohhhhhhh. Yeah that will mess stuff up. Ouch. I'm actually really curious what the polarity/voltage differences were between the two cables to find out whether it was a reverse polarity issue or a 12v into 5v issue.
  23. I'm sorry, I'm scratching my head here a bit. You say you replaced the PSU, and before turning it on you also used the new power cables that came with the new PSU, and then it nuked everything even when using the right cables?
  24. To update this topic for those using USB serial adapters (which I assume is realistically most of us), so far I have not managed to get kernel boot and shutdown messages to show but you can at least get the ability to login via the USB serial port. Essentially, you don't need the "SERIAL 0 115200" line, nor the changes to the "append" line" at all to get the ability to login via the USB serial adapter. Getting the ability to login via the USB to serial adapter only requires the addition to the /boot/config/go file as follows: sed -i -e "/^#s1/ i s1:12345:respawn:/sbin/agetty -L ttyUSB0 115200 vt102" /etc/inittab Note that my device is ttyUSB0 and it's set to 115200 baud rate as I'm connecting from a Mikrotik router. This will allow you to login via serial. What it won't do is let you see kernel messages via the serial port. There's a couple of issues with even trying to do this, including the fact that the USB driver loads quite late in the boot order and so you won't see a whole bunch of boot messages anyway. I am still looking into whether I can get kernel events posted to the USB serial console but for now this should help anyone who would like to restart their unRAID server even if network connectivity gets lost due to a NIC module errors or macvlan callbacks that kill the network stack. You may ask "what is the point since you can just walk up to the monitor and login via keyboard" but if I'm away from home and my unRAID server barfs, the ability to connect to it via serial through my Mikrotik router using Serial Terminal means I can kick it in the pants even without fancy stuff like an iLO card. My Mikrotik gear is the most reliable stuff in the house, so it makes sense to use this as the pivot point (I even use this for my VPN rather than a VPN container in unRAID). It may ultimately be that because USB is loaded so late in the kernel boot process, anything more than just basic login capability is a lost cause. I haven't given up yet, but it's very possible this is the case. For those of us that are desperate, I recommend a dedicated serial port as a hardware UART serial port will be loaded very early by the Linux kernel. There are a bunch of PCI-e serial port cards you can buy for this purpose.