Xenor

Members
  • Posts

    11
  • Joined

  • Last visited

Recent Profile Visitors

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

Xenor's Achievements

Noob

Noob (1/14)

4

Reputation

  1. Comments you mentioned are used in many languages but not Ruby https://www.tutorialspoint.com/ruby/ruby_comments.htm, and Ruby is what's used to build GitLab :).
  2. Okay, I've installed 6.11 stable on my secondary server and did the 'turn off docker -> change setting -> change it back -> turn on docker' dance. Pi-hole docker is able to ping server IP and server is able to ping pi-hole, so it looks like it's fixed in stable 6.11. I'm not going to do an update on my main today, might try tomorrow.
  3. I have confirmed the same issue on my second Unraid server that runs rc5. It went unnoticed there, because only secondary DNS server has its own macvlan IP, so it's not as impacting as home-assistant.
  4. The original issue is not fixed tho, DHCP/IP problems were just a 'side quest'. After getting that sorted, I'm still not able to ping my home assitant in a custom docker macvlan network, even tho 'Host access to custom networks' is enabled. After confirming everything DHCP/IP related works and home assistant is still not reachable on rc5, I've gone back to rc4 and home assistant docker is reachable from host, so it must be something to do with the upgrade.
  5. I have a custom docker bridge network, that hosts most of my containers, including swag proxy. I also have a custom macvlan network, that hosts my containers that need a unique IP, like home assistant. With the 'Host access to custom networks' I was able to reach home assistant from Unraid and from swag, but after updating to rc5 this option no longer works. I can ping Unraid host from swag successfuclly, but from home assistant I am unable to ping Unraid host (and vice versa). Pinging from/to other computers from home assistant works fine. This is breaking reverse proxy for me, as well as communication between home assistant and other containers (e.g. zigbee2mqtt). After full server restart I've just stopped getting IP altogether, server sits at 169.**. EDIT: Going back to rc4 didn't fix anything, still sitting at 169.** reporting full connectivity with the switch, everything seems fine in GUI mode, but Unraid ignores (?) DHCP. EDIT2: Somehow, restarting my switch fixed DHCP issue. Weird, cause other Unraid I have is connected to the same switch and it updated yesterday just fine. Original issue with docker accessing host persists. EDIT3: Rolled back to rc4, it fixed the docker <-> host access issue. Something must be up with rc5 not respecting that option.
  6. I have the same thing, since one of the RCs in 6.10.0 unRaid resets my saved fingerprints with each restart and failing Rsync backups remind me about going into console and accepting fingerprint manually. hostfile_replace_entries: link /root/.ssh/known_hosts to /root/.ssh/known_hosts.old: Operation not permitted update_known_hosts: hostfile_replace_entries failed for /root/.ssh/known_hosts: Operation not permitted
  7. I have used 'Unassigned devices' plugin in unsafe mode to delete the partition on my soon-to-be parity drive and formt it as XFS and that's all it took. You can see the state after formatting the drive on the screenshot. So, to sum up - my problem was that the drives were identical, but my designated parity drive had an existing partition that had a different start point, hence it had a lower sector count, and it seems like that confused Unraid, even though the drive would be formatted after assigning it as a parity drive. I guess, there is some room for improvement here in terms of message displayed, but I leave it up to you if it's worth pursuing.
  8. By doing some further digging, I've managed to find a difference between how partitions are made on those disks. I'm not sure why the difference is there though, I mean the array 14 TB drive was formatted in Unraid and the same is done for a parity drive, right? Could that be why I can't assign it as a parity drive?
  9. Hi, Today my LSI card came in, and I wanted to add a parity drive. I have two 14 TB drives - one is already assigned to the array, the second one is intended as a parity drive. Unfortunately, when I try to assign it as a parity, it says that 'Disk in parity slot is not biggest'. As per some very old topic, I've tried looking for HPA in my syslog, but it returned empty: root@Home-unRaid:~# cat /var/log/syslog | grep "HPA" root@Home-unRaid:~# I tried connecting the drives through the LSI card and directly to the motherboard SATA, both return the same problematic result. You can see my disk assignments below: I've also attached diagnostics for both when I connected drives directly to MOBO and when I connected them through the LSI card. I am not sure if this is a bug specific to the pre-release version, I never used any other version than 6.10.0-rc2, and I only got the LSI card allowing me to expand my array. home-unraid-diagnostics-20220119-2229-through-lsi.zip home-unraid-diagnostics-20220119-2216-directly-to-mobo.zip