Ancalagon

Members
  • Posts

    12
  • Joined

  • Last visited

Recent Profile Visitors

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

Ancalagon's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. It looks like the NVRAM is not being cleared, as I can still see the legacy NVRAM variable with the old OpenCore version: 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version = REL-064-2020-11-13. I've tried with the Reset NVRAM option in the boot menu as well as sudo nvram -c from the terminal. Apparently neither worked to delete that variable. I finally got it to delete explicitly with nvram -d 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version from the terminal. Rebooting it now shows the correct OpenCore version in OpenCore Configurator and Hackintool.
  2. I installed a macOS Big Sur VM using the latest macinabox. After installing OpenCore Configurator 2.39.0.0, it warned about the old version of OpenCore installed (0.6.4) and only supporting the latest 0.6.9 version. I followed the documentation for updating OpenCore by copying over all the files from the 0.6.9 package to the EFI partition, overwriting existing files and keeping all the files in the existing EFI that aren't in the 0.6.9 package. But when I reboot, it still says OpenCore 0.6.4 is booted. I found there was a bug updating to 0.6.7 that required clearing the nvram. But even after clearing the nvram, it still says 0.6.4 is booted. It does say the correct version on the boot menu though: (REL-069-2021-05-03). Are there any additional steps required to update OpenCore for the macinabox VM?
  3. I have a similar setup with ASUS ROG Crosshair VIII Dark Hero, Ryzen 9 5950x, and AMD Radeon RX 6800 XT (reference), running Unraid 6.9.2 with a Windows 10 VM. I found that adding "video=efifb:off" was required in the Syslinux configurations: append initrd=/bzroot video=efifb:off Binding the 4 IOMMU groups to VFIO at boot wasn't enough apparently. I'm using Q35-5.1 and also have Smart Access Memory enabled in the BIOS, although it's set to AUTO (there is only DISABLED and AUTO). I found I had to reinstall the Radeon driver after getting it to boot. I also found that it failed to work with the GPU as the secondary graphics, with VNC graphics as primary. I had to remove the VNC graphics.
  4. Ah, yes, this did the trick! I was thinking along these lines, needing to reprovision the certificate possibly, but it just needed the updated DNS was all. Thanks for the help.
  5. I can access the SMB shares and the files on them. I can also ssh into the server. So this really seems to be specific to the nginx web server for the admin GUI.
  6. Here are the rest of the diagnostics, if that's helpful. hobbes-diagnostics-20210507-0934.zip
  7. I just tested each NIC separately, disabling the other one in the BIOS. Same thing, neither worked still on its own.
  8. Here are the system logs. The end looks like this: May 7 09:34:04 Hobbes root: Starting Nginx server daemon... May 7 09:34:04 Hobbes avahi-daemon[4904]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. May 7 09:34:04 Hobbes avahi-daemon[4904]: New relevant interface virbr0.IPv4 for mDNS. May 7 09:34:04 Hobbes avahi-daemon[4904]: Registering new address record for 192.168.122.1 on virbr0.IPv4. May 7 09:34:04 Hobbes kernel: virbr0: port 1(virbr0-nic) entered blocking state May 7 09:34:04 Hobbes kernel: virbr0: port 1(virbr0-nic) entered listening state May 7 09:34:04 Hobbes dnsmasq[6099]: started, version 2.84rc2 cachesize 150 May 7 09:34:04 Hobbes dnsmasq[6099]: compile time options: IPv6 GNU-getopt no-DBus no-UBus i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-cryptohash no-DNSSEC loop-detect inotify dumpfile May 7 09:34:04 Hobbes dnsmasq-dhcp[6099]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h May 7 09:34:04 Hobbes dnsmasq-dhcp[6099]: DHCP, sockets bound exclusively to interface virbr0 May 7 09:34:04 Hobbes dnsmasq[6099]: reading /etc/resolv.conf May 7 09:34:04 Hobbes dnsmasq[6099]: using nameserver 208.67.222.123#53 May 7 09:34:04 Hobbes dnsmasq[6099]: using nameserver 208.67.220.123#53 May 7 09:34:04 Hobbes dnsmasq[6099]: read /etc/hosts - 2 addresses May 7 09:34:04 Hobbes dnsmasq[6099]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses May 7 09:34:04 Hobbes dnsmasq-dhcp[6099]: read /var/lib/libvirt/dnsmasq/default.hostsfile May 7 09:34:04 Hobbes kernel: virbr0: port 1(virbr0-nic) entered disabled state The last line doesn't look right, "entered disabled state". Nothing else stood out from the logs higher up. Both NICs seemed to initialize and bind together successfully. syslog.txt
  9. It's a x570 motherboard, ASUS ROG Crosshair VIII Dark Hero, plugged into the Intel 1 Gbps NIC. I only have a 1 Gbps network switch, so reserving the Realtek 2.5 Gbps for now, but I could try plugging into that NIC as well. I'll grab the diagnostics.
  10. I just built a new computer, moving all the hard drives from my previous Unraid computer, all except the SSD cache drive, which I replaced with two new M.2 drives. I booted to my Unraid flash drive and all appears to have booted normally, ending on the login prompt as expected. But the Unraid web GUI is not accessible. The .local hostname resolves correctly to my unraid.net TLS domain. Going to the IP address directly also resolves to the unraid.net TLS domain. But the page fails to load: This site can’t be reached https://XXXXX.unraid.net/ is unreachable. ERR_ADDRESS_UNREACHABLE I can login at the terminal login prompt successfully. Pressing the power button signals the OS to shutdown gracefully. I tried rebooting and selecting Unraid OS GUI Mode. But when it finishes booting it goes to a black screen.