Have you ever heard of the Lindy effect? It basically postulates than the future life expectancy for technologies and ideas is proportional to their current age, and based on that, it is safe to say that it is not too late for anyone to learn vi, which is notorious for being a text editor with vertical learning curve 🙂 Below is a link to my introductory blogpost published on StarWind blog and intended for those who just starting with vi. I recently have an opportunity to start using it and I can confirm it is just about overcoming initial frustration and practice a little bit, and then you can even like it 🙂 and even if you don’t you’ll definitely enjoy the power of being able to make config file changes on any Linux box right away instead of helplessly struggling without missing friendlier text editor(s).
In recent versions of K2 installer team introduced a feature which blocks installation in case of critical failure leaving you no choice but address the issue and perform repair. It basically blocks all the other options leaving you with Recover as an only available option as shown below:
This option is here for a reason and unless you 100% sure that you need to exit out of this mode you should analyze error and perform repair, if necessary involving vendor support. But in case of throw away test box or initial installation you may want to unblock all the other option, let’s say to perform removal and start from scratch. To do that you just need to delete contents of the Setup State folder (default location is “C:\Program Files\K2\Setup\State”) which in this case will contain json files with the state of failed installation. Those files contain sections like “ComponentActions”, “FailedTarget”, “CompletedTargets”, but to the best of my knowledge support will ask you for installer trace to investigate any type of installer failures.
Like I said in case you understand what you are doing and need to exit out of “Recover” mode you can just use folder clear up approach explained above.
I’ve recently updated macOS Big Sur to version 11.2.2, and it seems that after this update I run into issues with running my Python programs from PyCharm, which started to give me the following error on attempt to execute any program:
Error running 'P3-2': Cannot run program "/Users/User_Name/PycharmProjects/Project_Name/venv/bin/python" (in directory "/Users/User_Name/PycharmProjects/Project_Name"): error=2, No such file or directory
I’ve looked into relevant venv directory which contained symbolic link to Python executable which, in turn, by the looks of it in Finder, was broken (path/target cannot be found). I found that strange as Python 3 was installed and working for quite some time, so I tried to run python3 from terminal and saw the following error:
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
Long story short to fix that it was necessary to download and install the Command Line Tools package using the following command:
Not quite sure why it stopped working for me, but possibly installed version got removed during macOS update process.
Recently it was necessary for me to enable XRDP service on Ubuntu 20.04 VM, so I followed the steps outlined in one of my old posts and get it working quickly. Unfortunately I run into some new issue with not being able to reset or shutdown Hyper-V VM for some reason, which I ignored for now, but after couple of power offs I realized that I cannot connect via XRDP until I open session locally. I then decided to check on the service status with sudo systemctl status xrdp command and got the output shown below:
Full error message says: [ERROR] Cannot read private key file /etc/xrdp/key.pem and I’m pretty sure that it didn’t show up when I used the same status command after initial configuration, though people tend to forget and miss things 🙂
Anyhow to clear up this the following command has to be executed:
sudo adduser xrdp ssl-cert
Abovementioned error occurs when the default user for XRDP’s service lacks access to the directory to which /etc/xrdp links, and with the command above you allow the user xrdp access through ssl-cert group membership. I hope that this information may come in handy to some one else 🙂
Seemingly Hyper-V Manager GUI does not show VM generation of already created VMs whereas we do need to check on that sometimes. As usual PowerShell is an answer to this problem:
That command will output name of VMs and generation information as shown on a sample screenshot below:
Command above need to be run in elevated (Run as administrator) PowerShell window and from your Hyper-V host.
That’s it – Just a little note on how to grab VM generation information.