Unsupported DEB-based OS: /etc/os-release ID ‘kali’

Unsupported DEB-based OS: /etc/os-release ID ‘kali’. You can get the above error if you try to install AMD drivers on Kali Linux. Looks like by default they are looking for a system that is Ubuntu, LinuxMint or Debian.

You can resolve the issue by opening up the “amdgpu-pro-install” file and adding more OS’s that it can check for.

vi ./amdgpu-pro-install

Scroll down to line 147 where is says


and change it to


The code function should look like the following.

142 function os_release() {
143         if [[ -r  /etc/os-release ]]; then
144                 . /etc/os-release
146                 case "$ID" in
147                 ubuntu|linuxmint|debian|kali)
148                         :
149                         ;;
150                 *)
151                         echo "Unsupported DEB-based OS: `
152                                 `/etc/os-release ID '$ID'" | stderr
153                         exit 1
154                         ;;
155                 esac
156         else
157                 echo "Unsupported OS" | stderr
158                 exit 1
159         fi
160 }

Save a close the file and install the AMD drivers

./amdgpu-pro-install -y --opencl=legacy,rocm --headless

Looking at trying to install AMD drivers for mining? Check out the following link
Install RX 580 Mining Drivers on Debian Based Distributions

More info on Stack Exchange

Videos flashing and resizing on Internet Explorer

Had a problem with a NVR not displaying cameras correctly in the web interface in Internet Explorer. The issue appears to be something wrong with how it is interacting with Windows scaling.

To resolve the issue you can set the scaling to 100%


If the monitor is a HDPI, set it to a 1920×1080 resolution with scaling at 100%.

Errors Renewing Lets Encrypt Certificate for UniFi-Video

Had an issue with the Lets Encrypt cert for a UniFi-Video server.  When renewing the cert and reimporting it into the UniFi-Video keystore, the certification was showing out of date.

Issue ended up being something with certbot.

When certbot runs it generates a new cert.pem, chain.pem, fullchain.pem and privkey.pem and puts them in the “/etc/letsencrypt/live/unifi.domain.com/” directory.

The privkey.pem and cert.pem are used to create the keys.p12 file which gets imported into the UniFi-Video keystore.

Apparently the .pem files in “/etc/letsencrypt/live/unifi.domain.com/” are symbolic links to files in “/etc/letsencrypt/archive/unifi.domain.com/”

Upon inspection of the archive directory, multiple cert.pem and privkey.pem files were found with the names cert1.pem, cert2.pem, cert3.pem etc.  Looking at the creation date of the file revealed the symbolic link was referring to an old “cert1.pem” file.

Work around was to stop the unifi-video service and reimport the cert using the latest .pem files in the archive directory.

echo ubiquiti | openssl pkcs12 -export -inkey /etc/letsencrypt/archive/unifi.yourdomain.com/privkey2.pem -in /etc/letsencrypt/archive/unifi.yourdomain.com/cert2.pem -name airvision -out /usr/lib/unifi-video/data/keys.p12 -password stdin
echo y | keytool -importkeystore -srckeystore /etc/letsencrypt/archive/unifi.yourdomain.com/keys.p12 -srcstoretype pkcs12 -destkeystore /usr/lib/unifi-video/data/keystore -storepass ubiquiti -srcstorepass ubiquiti

Remove the old ufv-truststore and start the service.

mv /usr/lib/unifi-video/data/ufv-truststore{,.old}
systemctl start unifi-video

Worked like a charm.