Install Vara on Kali Linux/Rpi4.

A recipe for installing Vara on some unsupported OS’s.

KI7POL devised a script that will install Vara, Vara FM, and if you so choose, RMS Winlink, on to Raspberry Pi’s. You can find it HERE. The hangup for me was it supports a precious few operating systems. I run Kali at the office, at home, on the go, and in my shack. I’ve used it since back when it was still called Backtrack and I was still a guy in his late twenties going back to college because the economy didn’t need home construction managers anymore. I’ve always loved the creators’ simple ethos. Try harder. When I read the notes about the above install script I knew that’s what I would have to do.

The script encourages people to modify it to work for their implementation. But reading it I realized it would be quicker (for me) to fake out the script and make it believe it was installing on an approved system. The script first checks hardware (because the Pi3’s and up are the only ones with the power to run it all) the reads the os-release file in /etc to grab the distro name and it’s kernel. Knowing Kali is built on the Debian-testing branch, and that Debian is approved, I popped open that file to see it’s contents.

└─$ sudo cat /etc/os-release
[sudo] password for k4sbc:
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Kali GNU/Linux"
VERSION="2022.4"
VERSION_ID="2022.4"
VERSION_CODENAME="kali-rolling"
ID=kali
ID_LIKE=debian
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"
ANSI_COLOR="1;31"

Comparing it with the script’s contents it quickly became apparent I needed to update ID_LIKE to read. So backup the file with:

└─$ sudo cp /etc/os-release /etc/os-release.orig

The first was change was easy to identify. The second took a little more effort. When I ran the script after the first edit it got through to the Wine download before choking.

It printed the download target so I go back to script to see how where it came from and follow the link in browser and start dropping directories off the end of the URL until it worked. Kali-rolling wasn’t a valid kernel but Testing was. So back to OS-release file to edit.

https://dl.winehq.org/wine-builds/debian/dists/testing/

└─$ cat /etc/os-release
PRETTY_NAME="Kali GNU/Linux Rolling"
NAME="Debian"
VERSION="2022.4"
VERSION_ID="2022.4"
VERSION_CODENAME="testing"
ID=debian
ID_LIKE=debian
HOME_URL="https://www.kali.org/"
SUPPORT_URL="https://forums.kali.org/"
BUG_REPORT_URL="https://bugs.kali.org/"
ANSI_COLOR="1;31"

Try again. Still failed but this time the download URL contained “testing” instead of “kali-rolling” so I knew I was on the right track. Back to browser. Looking at the script I realize it’s just inserting the codename variable into the URL and also the file to be downloaded. But the files in the testing folder follow a different naming scheme that the other distro’s folders. Bingo. The naming scheme in testing DOES contain the codename it’s based on so back to OS release file to change from testing to bookworm.

Tried script again. Success!! Went all the way through install without another issue. Not sure it works in production yet but I’ve configured Flrig, rigctld, Pat-winlink, and connected my FT-818. Everything works when connected to dummy load. Hope to test live during Winlink Wednesday evening P2P session.