PowerBash eases some discomfort of adjusting to PowerShell for Linux users

Want to use grep or vim from your powershell env? Now you can!

OK, I just stumbled across the coolest thing.

Occasionally I use PowerShell because it’s the easiest way to get batch processes accomplished on a Windows computer, or sometimes the only way to implement a feature (e.g. making folders case-sensitive to avoid naming conflicts when syncing with nix computers).

But it’s always a bit of a pain because I have to look up ways to do basic things I can easily do in a POSIX-style environment without needing a reference (e.g. find, grep, sed, df, vim) and sometimes their implementation is awkward or clunky, or just not easily possible.

Enter Powerbash:

Another way of installing – import the script

From the Github repo, “PowerBash Module allows you to run bash commands and other Linux programs from the Windows Subsystem for Linux directly from PowerShell, with support for piping to and from PowerShell commands.”

Here’s the link to the repo: https://github.com/jimmehc/PowerBash

They recommend getting the script from the repo and importing it using import-module but I just installed it from the Powershell Gallery using:
install-package powerbash
from a PS prompt

(note, I did try installing it from the script using import-module but it points to an older directory structure for WSL than that used in 1809, so it would need some modification for more modern WSL implementations. The PSGallery package works OTB)

Using grep -E with find-package command in PowerShell

To install the PS Gallery and get started with the PowerShell method of package management, check this out:

It does require WSL, as well, and 14316 or higher version of Windows.

It makes using PowerShell a lot easier when you can pull out the random nix command in a pinch!

Looks like VIM works just fine in PowerShell now…

You can still use PowerShell in msys64 (also in “Git Bash”) which gives you some of the same functionality, but PowerShell’s functionality is somewhat impaired when running inside msys64, so it’s not that great of a solution.

PowerBash starts with PowerShell and adds the Linux compatibility layer to it, rather than the other way around, so it’s inherently more friendly to your PS cmdlets. Also nice that it uses WSL for compatibility instead of msys64’s re-compiled utilities. Definitely a two-fer.

PowerBash looks in locations in the Linux Subsystem’s filesystem for programs, equivalent to the following $PATH:


This is currently hardcoded (damn!) but that may be changed in the future (yay!).

Any existing commands available to the current PowerShell session, including EXEs in the PowerShell $env:PATH, cmdlets, functions, and aliases, will not be overridden by Linux programs. If you would like to use a Linux program of the same name instead, remove all functions, cmdlets, and aliases from your session prior to importing the module. For EXEs, you can pass the names of the programs you want over-ridden to the module via -ArgumentList when importing (comma separated).

Add podman controller to cockpit on Ubuntu 20.04 LTS

Podman is the bad-ass contender to docker that uses oci

I am heartened to see podman becoming more comfortable on Ubuntu, since although I’m excited about a lot of the software coming from RHEL’s massive portfolio of acquisitions, I still prefer Ubuntu’s support length and update schedule, and find its commands and structure more familiar.

But what about the accessories that are available for podman? Would installing it on Ubuntu make it like a fish out of water?

Thankfully, no! buildah is also available in the offical podman repo for Ubuntu, and apparently cockpit-podman can be installed fairly easily, too.

cockpit-podman is one of the areas in which Fedora/RHEL has an edge out of the gate, as it’s not available in Ubuntu repos or PPAs. But I thought it might be fairly easy to build since it’s a web application. Naturally, I couldn’t find any instructions on how to do it anywhere, but I managed to figure it out on a new VPS I’m setting up. So I wanted to share how I got it working, since I’m pretty sure the procedure isn’t described anywhere else yet.

Obviously, first you want to install podman and cockpit. Cockpit’s in the Ubuntu 20.04 multiverse repo, it’s a quick:
sudo apt update && sudo apt install -y cockpit

Podman has Ubuntu in the official documentation and only requires a few easy commands – take a trip to their installation instructions and step through them real quick before continuing here: https://podman.io/getting-started/installation.html#ubuntu

Then clone the cockpit-podman repo: https://github.com/cockpit-project/cockpit-podman

Go to your build directory and run this to clone the repo:
git clone https://github.com/cockpit-project/cockpit-podman.git

Install the build requirements (listed in cockpit-podman.spec):
sudo apt update && sudo apt install -y appstream-util
(you need build-essential for this even though it uses node – so add it to the end of that last command string if you haven’t installed it yet)

appstream-util should automatically install libappstream-glib8 which satisfies libappstream-glib mentioned in the .spec file – other prerequisites mentioned will be installed along with the cockpit meta-package)

Also, you’ll need to have nodejs installed – but don’t use the package maintainer’s version, it’s several major versions behind. Instead, manage your node installations with nvm-sh from here:

The installation’s pretty easy – you have to have curl for nvm to work, so this command is appropriate (install curl if you haven’t already):
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash

Quick side note about choosing a node release with nvm: If you’d rather check to see what the latest available node LTS release is when you perform these operations, it’s:
nvm ls-remote --lts
(I definitely recommend you use an LTS release, as building with a bleeding-edge release of node won’t offer any benefits and is more likely not to work)

Then, required to install node are a few simple commands:
~/.bashrc (reload your env)
nvm install 12.18.1 (as of writing this is latest node LTS)
nvm alias default 12.18.1 (set it to default for later)
Verify it’s working by running node --version
If for some reason it’s not working, try:
nvm use 12.18.1

Now that node is installed, navigate your newly cloned cockpit-podman repo and run make

Then run your sudo make install and it’ll install it to your existing cockpit directory.

Now the next time you log into cockpit you’ll have a super convenient podman controller, just as if you were on a Fedora or RHEL/CentOS machine. (If you’re already logged in, obviously you’ll want to log out and back in again.)

Working example on a VPS running Ubuntu 20.04 LTS

Getting touchpad scroll to work in VMWare Workstation

Shiny new Kubuntu 20.04 dev platform

So, I develop using NodeJS, and I use Windows. Anyone who uses both together and has used Linux as a dev platform has probably realized the Windows version is a little lackluster and has edge configuration issues that make it a pain.

So I was setting up a dev environment on an ESXi host so I could have one place in which I do my development and not have to switch back and forth between Windows and Linux platforms, deal with the painfully slow WSL, Windows ‘git bash’, etc. do everything native.

That was a great idea until I got it all set up and realized my touchpad wouldn’t scroll anymore.

Not just in the new Kubuntu dev VM, but everywhere! My Thinkpad’s touchpad literally would not scroll ANYWHERE, not in Ubuntu, not in Windows, nada.

I had just installed VMWare-tools 10.3.21 which as of June 2020 was still the latest edition at over a year old (surprising). However, there is a KB article in which VMWare recommends using the open-vm-tools package, which I had thought was an open-source knock-off, but through a little digging I found out it is actually an official release from VMWare that appears to have been open-sourced.

Reference: https://github.com/vmware/open-vm-tools

Thinking this might have contributed to my non-scrolling touchpad issue, I promptly uninstalled VMWare-tools and installed the open-vm-tools-desktop package.

To my surprise, my touchpad started scrolling again, both in the VM and in Windows.

So, as a PSA, anyone who’s experiencing this issue (maybe it’s a Synaptics-related thing?) try using the open-vm-tools package instead of VMWare-tools and maybe your touchpad will magically start scrolling again…

Genuine Lenovo Thinkpad T460S T470S Three button Touchpad Clickpad ...
“I feel so alive!”

Building required VMWare Workstation Kernel Modules Ubuntu ** updated for Secure Boot **

Ubuntu Authentic Logo - Ubuntu Linux - Pin | TeePublic
Ubuntu logo

VMWare Workstation on Ubuntu requires another step to run. Sometimes the installer will install the kernel modules it requires in the installer, other times it won’t. There’s another step to the setup after running the installer that might as well be documented as part of the installation process.

It’s compiling kernel extensions for vmmon and vmnet – and Workstation tries to compile them out of the box, but it never works. It’s missing some essential kernel extensions that are only available from GitHub. Get used to it, because every time you upgrade your kernel, you’ll have to do this again (unless you create a hook for apt … I’ll have to put that in a later post).

I had to write a post about it since after doing it for the umpteenth time I realized this might be a problem for a lot of people that isn’t well documented and might be exceedingly confusing for first-time users.

Make sure you have the headers and modules for your kernel – this oneliner will refresh your package cache and install them if you don’t have them:

$ sudo apt update && sudo apt install -y linux-headers-$(uname -r) linux-modules-$(uname -r)

First, you’ll have to download the kernel extensions. Here’s where they’re available:


You’ll see filenames available for download that look like w15.5.5-k5.7 – you want to match the first 3 numbers to your Workstation version, and the last two to your kernel – this example would be for Workstation 15.5.5 and an OS with 5.7 kernel.

Thankfully there’s plenty of releases to find one that’ll work for your setup. At the time of writing there is nearly 700 releases to choose from (indicating that this has probably been a major issue for a long, long time… )

After downloading the release, unzip or untar it and it’ll create a folder called:

vmware-host-modules-<release version>

cd into this folder and try making the .ko files:

$ cd vmmon-only && make && cd ..
$ cd vmnet-only && make && cd ..

Create two .tars:

$ tar -cf vmmon.tar vmmon-only
$ tar -cf vmnet.tar vmnet-only

Then copy them to the modules source directory for Workstation (as root):

$ sudo cp -v vmmon.tar vmnet.tar /usr/lib/vmware/modules/source/

After copying the .tar files to /usr/lib/vmware/modules/source/ run this command:

$ sudo vmware-modconfig --console --install-all

If all goes as planned, you should be able to run Workstation now.

If you notice vmware-modconfig complaining about errors / failing, you’re probably booted under secureboot. You can disable secureboot if you’d like to make this process easier for next time, but if not – here’s some additional steps you’ll have the pleasure of performing over and over.

Note: Keep in mind that if you upgrade your kernel you’ll absolutely have to go through this process all over again. Sometimes, but not always, updates to Workstation will require it, too.

You’re sure to get just as familiar with the process as I am before long.

For systems using secure boot, regarding the additional steps, they may only be necessary when changing release version of kernel, but not point version – so 5.8.0-19 to 5.8.0-21 might not need a mokutil update, but 5.6.2 to 5.8.0 definitely would.

Generate a key pair using the openssl to sign vmmon and vmnet modules:

$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=VMware/

Sign the modules using the generated key:

$ sudo /usr/src/linux-headers-`uname -r`/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmmon)

$ sudo /usr/src/linux-headers-`uname -r`/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmnet)

Import the public key to the system’s MOK list:

$ sudo mokutil --import MOK.der

Choose a password you’ll remember for the MOK key enrollment, since the next step is rebooting and enrolling it in your UEFI firmware.

Reboot your machine. Follow the instructions to enroll the MOK key in your firmware from the UEFI console, and go back to your Ubuntu terminal and run:

$ sudo vmware-modconfig --console --install-all

That should take care of it for you.

Now just make sure you bookmark this page and the Github releases page so you can come back when you upgrade your kernel and do this all over again!

Good luck!





ESXi 6.7 – Forcefully Removing a Phantom NFS Share

Link Broken Icon - Paper Style - Iconfu

Interesting thing happened to me today. I had to do some work on one of my ESXi 6.7 hosts, so I powered it off (which is something I rarely ever do). I had just done some static configuration of ipv6 on my domain controllers, provisioned DNSSEC, etc. so I was playing with a relatively recently modified network.

Well, it must have been a little too different for my ESXi configuration to handle, because when I powered up my ESXi host again, two out 5 of my NFS datastores couldn’t reconnect. It was a little perplexing because ESXi doesn’t give you much of a sense of what’s going on – just a message saying:

Can’t mount NFS share – Operation failed, diagnostics report: Unable to get console path for volume

There’s some logs you can check, like hostd.log, vmkernel.log, etc. but they didn’t tell me much, either. (If you want to check these they’re in /var/log and the most convenient way I’ve found is to use:
# tail -n <number of lines> <name of log file>

But here’s the thing – no matter how many times I tried to reconnect, I was unable. I could, however, reconnect the datastore as long as I gave it a different name

Finally after a while it dawned on me that the share still existed (although it did not show up in):
# esxcli storage nfs list

That was the whole reason I couldn’t re-create it – ESXi thought it was still there although it wasn’t giving me any real indication (only the failed attempt to manually re-connect)

Tl;dr – to Fix the issue,

  1. Remove any references to your phanton NFS datastore – remove any HDDs that reference it, any ISO files (connected or not), remove VMs from your inventory that are imported from it.
  2. Remove the NFS share link from SSH using the command:
    # esxcli storage nfs remove -v <phantom datastore name>
    (note, the -v will give you a little more feedback)
  3. At this point I decided to reboot, but if you can probably just restart the agents from the DCUI: https://kb.vmware.com/s/article/1003490
  4. Now you should be able to re-connect your NFS datastore, with the same name and everything.

If you have any VMs on the datastore, ISOs, vHDDs, etc. you need to re-connect, now you should be able to without any problem.