ndfan77

I don't believe there is one other than whether "pkg update -f" should be added to the helper script before the "pkg install ...." statement: echo "Refreshing package databases..." pkg update -f echo "Installing necessary packages..." pkg install -y vm-bhyve edk2-bhyve wget qemu-tools

My issue with pkg (which was doing exactly what @stevesreedquoted above) straightened out immediately after I did the temporary rename of /usr/local/etc/pkg reported here (and has been fine since). Here's the contents of my FreeBSD.conf: P.S. It was only my second (follow-on) post that mistakenly referenced "pkg refresh -f" instead of "pkg update -f". I just corrected it.

He's apparently got the "wonky" pkg repository database problem too (that isn't a communication issue). I'd bet a steak dinner that if he does this it straightens out: sudo bash mv /usr/local/etc/pkg /usr/local/etc/pkg.temp pkg search wget mv /usr/local/etc/pkg.temp /usr/local/etc/pkg pkg search wget exit But it'd be interesting to know if "pkg update -f" has a positive effect first.

That's embarrassing. I'm either losing it or getting a little "command dyslexic". I searched my Eisy command history for "pkg refresh" and came up empty. I searched the command history on my separate sandbox FreeBSD vm and found quite a few: pkg update -f Maybe try that? P.S. Glad I'm not the only one with psuedo communication errors when invoking pkg...!

Michel, I know you have a custom udi repository defined in that folder (along with an additional FreeBSD repository), and I thought I was being pretty clear that I wasn't suggesting anybody else do the same thing (if they were running into the same problem with pkg not installing components), and should instead try issuing a "pkg update -f". There was no communication issue with my Eisy (former lead network engineer [among other things] speaking). The pkg configuration on my (essentially brand new) Eisy was definitely broke (and yes, the Eisy was restarted several times [which I strongly dislike as a 1st response]). To reiterate what I said: Trying to install anything (not currently installed) produced a "No packages available to install matching ..." error, and trying to search for anything that pkg should easily find (e.g. "pkg search wget") produced an empty result every - single - time. Something was clearly "wonky" in the pkg configuration on my new Eisy, so I started comparing it to a fresh FreeBSD 13.2 VM installation (which did correctly return a response for "pkg search wget", even after being installed), and noticed that the clean FreeBSD 13.2 installation didn't have the /usr/local/etc/pkg folder. So the next thing I tried on the Eisy was renaming the custom repository folder to something else (briefly) and viola!: pkg on the Eisy now started returning results for "pkg search wget" (after it automatically rebuilt the repository database). This is not behavior that suggests a communication error was suddenly fixed. This is behavior that suggests that doing something that forcibly causes pkg to rebuild the repository database is what fixed the issue. The /usr/local/etc/pkg folder was shortly renamed back to it's original state (before pkg installed or updated anything), and when another "pkg search wget" was issued again, pkg again rebuilt the repository database (to the correct configuration). I don't have a lot of FreeBSD experience (but do have a lot of enterprise-level Linux administration experience) and I've never seen a package manager downgrade or remove newer packages that came from a repository no longer enabled, unless it was specifically told to. What I'd submit should be of interest (to you) is: Apparently some Eisy's (at least in my case) are starting out in life with a non functioning pkg configuration, because something's wonky with their repository database. That I suspect issuing a "pkg update -f" will fix it (the right way). I say "suspect" because I didn't discover the pkg update command had a -f (force) switch until after my configuration had already been fixed with the custom repository folder rename sequence. (The -f switch is not documented in the FreeBSD pkg man pages.) If others are running into this too (sure seems like there's been a couple already), and refreshing the pkg repository databases with "pkg update -f" fixes it, than you should consider adding that statement before the "pkg install -y vm-bhyve edk2-bhyve wget qemu-tools" statement in the helper script.

Yep, I'm running FreeBSD 13.2 on the free version of ESXi (along with quite a few other Linux and Windows VM's) on a PowerEdge T140 down in the basement. It works fine. I didn't start with the FreeBSD vmdk image though (since I prefer to know exactly how an OS is configured from the start). Instead I started with a new vSphere VM with unformatted storage, mounted the FreeBSD amd64 installation ISO as a virtual DVD, and let it install like it was installing on bare metal, and then used pkg to install open-vm-tools when it finished. My interest at this point isn't in doing a P2V of IoX/PG3 to ESXi, but rather just to have a FreeBSD 13.2 playground with snapshot/restore capability separate from the Eisy (before doing something I'm not sure of on the Eisy). I'd much rather be able to use that Eisy hardware to run a couple other small footprint critical infrastructure services (such as Ubiquiti's UniFi controller) since I can keep the Eisy up a lot longer on UPS/generator during a power outage. Eventually I may fool around with trying to run the UniFi controller in a separate Bhyve VM on Eisy.

I ran into these errors as well while stepping through the Helper Script line by line as root on a brand new Eisy. Issuing: pkg install <xyz> would produce the "No packages available to install matching ..." error no matter which (currently uninstalled) package I was trying to install. And issuing: pkg search <xyz> wouldn't return any results (for packages like wget that are definitely in the base repository). What straightened pkg out on Eisy for me was temporarily renaming the /usr/local/etc/pkg folder to something else and then issuing a pkg command (e.g. "pkg search wget") and then pkg recognized it needed to rebuild the repository databases, and then started to work correctly. Then I renamed the /usr/local/etc/pkg folder back to its proper name and pkg rebuilt the repository databases again (for any type of pkg search) -- and worked fine after that. BUT, I suspect that if I had just issued: pkg update -f (Which also rebuilds the repository databases.) It probably would have fixed my issue without temporarily renaming /usr/local/etc/pkg. So my suggestion to UDI would be to consider including "pkg update -f" before the "pkg install ..." in the helper script: echo "Refreshing package databases..." pkg update -f echo "Installing necessary packages..." pkg install -y vm-bhyve edk2-bhyve wget qemu-tools

Ah, and so it does. Thanks!

I'm trying to setup a Caddy reverse proxy (which does automatic certificates) in front Polyglot. What's the right/supported method to configure Polyglot to use http instead of https? TIA...

I don't want to appear to discount or under appreciate the significant R&D effort UD has invested in the ISY/Polisy/EISY/IoX/PGx platforms (and I'm probably missing something). But yeah, I couldn't help but think it would have been perfect if: 1) EISY was running Alpine Linux with Docker (this combination is very small, very fast, and very stable). 2) IoX and PG3 were running in a Docker container (FreeBSD or ported to Alpine), and 3) we could easily run additional containers. But, I have zero expectation anything like that would be anywhere close to getting on UD's radar anytime soon! (But #2, I'd actually be willing to donate time to help with that if it ever did...)

Didn't see that coming. This thread and this thread seems to be echoing just that (but I have to say that overall the tone doesn't seem like it reflects well on FreeBSD). Well, so much for the brief notion that I might also be able to move my UniFi controller (and a few other light-duty containers) over to the EISY!

In addition to running HA as a VM with bhyve on EISY I think I'd also like to try running HA as a Docker container on EISY. (I already have Docker running on several ESX Alpine VMs, and on a bare metal Fedora box -- but I can see some advantages to having Docker running on the EISY, and I suspect HA would be easier to manage/upgrade/downgrade as a container than as a VM.) I've done a lot of enterprise network and system administration with Cisco, Red Hat, CentOS, Alpine Linux, Windows Server (MCSE), Active Directory (MCSE), vSphere/VMware/ESX, and Docker, along with quite a few other types of system/network administration. (And before all that, back "in the DOS days" I wrote a lot of systems level code in x86 protected mode assembly language, including a TCP/IP stack from scratch, routing and firewall code, and multi-threaded smtp/http/dns/etc servers.) FreeBSD is one of the *NIX's I haven't messed a lot with (but that never stopped me before). I know there's some Docker on FreeBSD documentation already out there, and I'll be fine on my own, but I suspect I may want to "reflash" a few times along the way. It'd be great if you could share (privately if necessary) the reflash steps. If Docker seems like a viable approach I'll be happy to share my documentation.

This, is a very interesting development. (And I appreciate the willingness of UD to wander off the beaten support path a little.) I need to get smarter with HA specifics (something I've been meaning to focus on for awhile if only there were more hours in the day) and, I've had a new EISY sitting on my bench for a couple months now waiting to start taking over home automation duties from the ISY994i (which I was planning to do manually, when those additional hours in the day showed up) -- when I stumbled on this. If we somehow manage to bork or brick our EISY's, are the steps to restore it to a factory image documented somewhere? (Sorry if I missed an obvious link or reference.) Also, is there a folder structure we can save/restore to an external location (with scp or rsync -- I'll figure that part out) that will allow a quick save/restore of the running IoX configuration?