More ways to help Linux users hate Windows less

Evil Computer Laptop - Openclipart

Ok, so obviously if you hate Windows, you probably just shouldn’t be using it. But what if you love the way Linux operates, but have a plethora of Windows-only applications you have to have at your fingertips at any moment’s notice?

Here are some ways the discerning Linux user who’s stuck by vendor lock-in can make Windows a little more palatable in the command line:

1) Install a package manager.

If you haven’t already, install Chocolatey package manager for Windows https://docs.chocolatey.org/en-us/choco/setup

Don’t even bother reading up on it, just do it. Chocolatey is the most accepted and proliferate package manager for Windows. There’s other options out there, but none that have as many packages, or that have as large of a community.

Almost anything you can imagine has been packaged using it, it can automatically manage their updates (with varying success), and it’ll give you an all-in-one place to install and uninstall software, (almost) just like using a Linux distro.

The basic commands are choco search <packageName>, choco install <packageName> and choco uninstall <packageName>. There’s also choco info <packageName> to read a package’s description, and choco list --local-only to list all the software you’ve installed using it.

Easy, right? You’ll be feeling more at home in no time. If you’re looking for a GUI management tool, there’s one of those, too, but it kind of defeats the purpose: https://community.chocolatey.org/packages/ChocolateyGUI

2) Get git-bash and put its posix tool folders in your %PATH%:

A while back I wrote a post on PowerBash, and while it had some nice features, they were limited, worked with varying success, and you had to be in PowerShell to use them.

Before that, I had written about git-bash and how awesome it is, but using its posix utilities appeared to be relegated to only its terminal.

Well, now I found a way you can use the posix utils in any terminal, regardless of what kind it is!

Now that you have Chocolatey installed, you can install git-bash by invoking the following in an administrative terminal – if you haven’t installed git-bash, you are totally missing out, so do this now:

 choco install -y git

Now that you have git-bash installed, add its primary posix util folders to your path, like this (must be administrative command prompt):

setx /m '%PATH%;C:\Program Files\Git\bin;C:\Program Files\Git\usr;C:\Program Files\Git\usr\bin;C:\Program Files\Git\usr\libexec;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\mingw64\libexec\git-core'

As always, you can check your path in Windows with:

echo %PATH%

Here’s mine as an example from cmd:

C:\>echo %PATH%
C:\Python39\Scripts\;C:\Python39\;C:\Program Files (x86)\VMware\VMware Workstation\bin\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\ProgramData\chocolatey\bin;C:\Program Files\Git\cmd;C:\Program Files\PowerShell\7\;C:\Program Files\Microsoft VS Code\bin;C:\Program Files\OpenSSH-Win64;C:\Program Files\Git\bin;C:\Program Files\Git\usr;C:\Program Files\Git\usr\bin;C:\Program Files\Git\usr\libexec;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\mingw64\libexec\git-core;C:\ProgramData\chocolatey\lib\mpv.install\tools;C:\tools\BCURRAN3;C:\Program Files\Go\bin;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\NodeJs;C:\Program Files\CMake\bin;C:\Program Files (x86)\ClockworkMod\Universal Adb Driver;C:\Users\avery\bin\cmdline-tools\bin;C:\Program Files\Java\jdk1.8.0_211\bin;C:\Android\android-sdk\tools;C:\Android\android-sdk\platform-tools;C:\Android\android-sdk\tools\bin;C:\Program Files (x86)\dotnet\;C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\NodeJs\;%PATH;C:\Program Files (x86)\gedit\bin;C:\Program Files\Microsoft VS Code;C:\Users\avery\.dotnet\tools;C:\ProgramData\chocolatey\lib\psutils\tools\psutils-master\;C:\Users\avery\AppData\Roaming\npm

By putting the posix tools from git-bash in your %PATH%, you can use pretty much all of them the same way as on a Linux machine, in any type of terminal window – cmd.exe, pwsh.exe, bash.exe – and they’ll be available in any current working directory. Most of them work just fine, you just have to remember to use backslashes for directories instead of forward slashes if you’re in cmd or powershell, but git-bash even uses forward slashes for maximum comfort and compatibility.

All your favs are there – ssh scp sed sha256sum grep which sort cat cut awk gawk vim nano ls rm wc du df less more etc. The only one I can think of that doesn’t work correctly is the find command – probably because it creates a command conflict with the MS-DOS equivalent (here’s proof):

C:\>which find
/c/Windows/system32/find

If you want to install tree, that’s not included, but now you can install it with:

C:\>choco install tree

And if you were discerning enough to search for sudo, you’d notice that was there, too, allowing you to install software from a non-administrative prompt (requires UAC administrative privileges).

Here’s the tree of the git-bash usr/bin dir – check it out, it’s pretty comprehensive!:

$ tree usr/bin | grep .exe

$ tree usr/bin | grep .exe
|-- [.exe
|-- arch.exe
|-- awk.exe
|-- b2sum.exe
|-- base32.exe
|-- base64.exe
|-- basename.exe
|-- basenc.exe
|-- bash.exe
|-- bunzip2.exe
|-- bzcat.exe
|-- bzip2.exe
|-- bzip2recover.exe
|-- captoinfo.exe
|-- cat.exe
|-- chattr.exe
|-- chcon.exe
|-- chgrp.exe
|-- chmod.exe
|-- chown.exe
|-- chroot.exe
|-- cksum.exe
|-- clear.exe
|-- cmp.exe
|-- column.exe
|-- comm.exe
|-- cp.exe
|-- csplit.exe
|-- cut.exe
|-- cygcheck.exe
|-- cygpath.exe
|-- cygwin-console-helper.exe
|-- d2u.exe
|-- dash.exe
|-- date.exe
|-- dd.exe
|-- df.exe
|-- diff.exe
|-- diff3.exe
|-- dir.exe
|-- dircolors.exe
|-- dirmngr-client.exe
|-- dirmngr.exe
|-- dirname.exe
|-- dos2unix.exe
|-- du.exe
|-- dumpsexp.exe
|-- echo.exe
|-- env.exe
|-- envsubst.exe
|-- ex.exe
|-- expand.exe
|-- expr.exe
|-- factor.exe
|-- false.exe
|-- fido2-assert.exe
|-- fido2-cred.exe
|-- fido2-token.exe
|-- file.exe
|-- find.exe
|-- fmt.exe
|-- fold.exe
|-- funzip.exe
|-- gapplication.exe
|-- gawk-5.0.0.exe
|-- gawk.exe
|-- gdbus.exe
|-- gencat.exe
|-- getconf.exe
|-- getfacl.exe
|-- getopt.exe
|-- gettext.exe
|-- gio-querymodules.exe
|-- gkill.exe
|-- glib-compile-schemas.exe
|-- gobject-query.exe
|-- gpg-agent.exe
|-- gpg-connect-agent.exe
|-- gpg-error.exe
|-- gpg-wks-server.exe
|-- gpg.exe
|-- gpgconf.exe
|-- gpgparsemail.exe
|-- gpgscm.exe
|-- gpgsm.exe
|-- gpgsplit.exe
|-- gpgtar.exe
|-- gpgv.exe
|-- grep.exe
|-- groups.exe
|-- gsettings.exe
|-- gzexe
|-- gzip.exe
|-- head.exe
|-- hmac256.exe
|-- hostid.exe
|-- hostname.exe
|-- iconv.exe
|-- id.exe
|-- infocmp.exe
|-- infotocap.exe
|-- install.exe
|-- join.exe
|-- kbxutil.exe
|-- kill.exe
|-- ldd.exe
|-- ldh.exe
|-- less.exe
|-- lessecho.exe
|-- lesskey.exe
|-- link.exe
|-- ln.exe
|-- locale.exe
|-- locate.exe
|-- logname.exe
|-- ls.exe
|-- lsattr.exe
|-- mac2unix.exe
|-- md5sum.exe
|-- minidumper.exe
|-- mintty.exe
|-- mkdir.exe
|-- mkfifo.exe
|-- mkgroup.exe
|-- mknod.exe
|-- mkpasswd.exe
|-- mktemp.exe
|-- mount.exe
|-- mpicalc.exe
|-- msgattrib.exe
|-- msgcat.exe
|-- msgcmp.exe
|-- msgcomm.exe
|-- msgconv.exe
|-- msgen.exe
|-- msgexec.exe
|-- msgfilter.exe
|-- msgfmt.exe
|-- msggrep.exe
|-- msginit.exe
|-- msgmerge.exe
|-- msgunfmt.exe
|-- msguniq.exe
|-- mv.exe
|-- nano.exe
|-- nettle-hash.exe
|-- nettle-lfib-stream.exe
|-- nettle-pbkdf2.exe
|-- ngettext.exe
|-- nice.exe
|-- nl.exe
|-- nohup.exe
|-- nproc.exe
|-- numfmt.exe
|-- od.exe
|-- openssl.exe
|-- p11-kit.exe
|-- passwd.exe
|-- paste.exe
|-- patch.exe
|-- pathchk.exe
|-- perl.exe
|-- perl5.32.1.exe
|-- pinentry-w32.exe
|-- pinentry.exe
|-- pinky.exe
|-- pkcs1-conv.exe
|-- pldd.exe
|-- pluginviewer.exe
|-- pr.exe
|-- printenv.exe
|-- printf.exe
|-- ps.exe
|-- psl.exe
|-- ptx.exe
|-- pwd.exe
|-- readlink.exe
|-- realpath.exe
|-- rebase.exe
|-- recode-sr-latin.exe
|-- regtool.exe
|-- reset.exe
|-- rm.exe
|-- rmdir.exe
|-- rnano.exe
|-- runcon.exe
|-- rview.exe
|-- rvim.exe
|-- scp.exe
|-- sdiff.exe
|-- sed.exe
|-- seq.exe
|-- setfacl.exe
|-- setmetamode.exe
|-- sexp-conv.exe
|-- sftp.exe
|-- sh.exe
|-- sha1sum.exe
|-- sha224sum.exe
|-- sha256sum.exe
|-- sha384sum.exe
|-- sha512sum.exe
|-- shred.exe
|-- shuf.exe
|-- sleep.exe
|-- sort.exe
|-- split.exe
|-- ssh-add.exe
|-- ssh-agent.exe
|-- ssh-keygen.exe
|-- ssh-keyscan.exe
|-- ssh-pageant.exe
|-- ssh.exe
|-- sshd.exe
|-- ssp.exe
|-- stat.exe
|-- strace.exe
|-- stty.exe
|-- sum.exe
|-- sync.exe
|-- tabs.exe
|-- tac.exe
|-- tail.exe
|-- tar.exe
|-- tclsh.exe
|-- tclsh8.6.exe
|-- tee.exe
|-- test.exe
|-- tic.exe
|-- tig.exe
|-- timeout.exe
|-- toe.exe
|-- touch.exe
|-- tput.exe
|-- tr.exe
|-- true.exe
|-- truncate.exe
|-- trust.exe
|-- tset.exe
|-- tsort.exe
|-- tty.exe
|-- tzset.exe
|-- u2d.exe
|-- umount.exe
|-- uname.exe
|-- unexpand.exe
|-- uniq.exe
|-- unix2dos.exe
|-- unix2mac.exe
|-- unlink.exe
|-- unzip.exe
|-- unzipsfx.exe
|-- users.exe
|-- vdir.exe
|-- view.exe
|-- vim.exe
|-- vimdiff.exe
|-- watchgnupg.exe
|-- wc.exe
|-- which.exe
|-- who.exe
|-- whoami.exe
|-- winpty-agent.exe
|-- winpty-debugserver.exe
|-- winpty.exe
|-- xargs.exe
|-- xgettext.exe
|-- xxd.exe
|-- yat2m.exe
|-- yes.exe
|-- zipinfo.exe

There’s even this cute little df replacement called dfc I like to use in Linux for a more graphical representation of hard drive usage – it’s called duf in Windows (slightly truncated for formatting purposes):

Or htop which is called ntop in Windows:

See, now Windows isn’t so bad after all, is it?

The GRUB prompt: Demystified

Frustrated Computer User Cartoon - Free Transparent PNG Clipart Images  Download

OK, so practically everyone who uses Linux has come to this menacing prompt at least once or twice. Typically, unless you’re a seasoned sysadmin, it’s a harbinger of death of your ability to use the computer like you were hoping that day.

But if you know how to navigate the GRUB prompt, you can get back to work just like you were hoping.

If you’re scared of new prompts, and would rather just re-install GRUB, please see my sister post for restoring GRUB on Ubuntu: <coming soon>

These two skills are extremely useful to have in your arsenal of command-line fu, because if you can knowledgably tackle a GRUB prompt in a reasonable amount of time, it can save you hours of headaches and hassle.

So don’t be afraid, embrace the unknown and learn how to navigate GRUB!

First of all, what’s a GRUB prompt?

             GNU GRUB Version 2.04~beta2-36ubuntu3.15
Minimal BASH-like line editing is supported. For the first word, TAB lists possible for device or command completion.

grub>

It’s a black screen that has a prompt like this, instead of the list of OS you were hoping to boot.

What do you need to know to boot from a GRUB prompt?

You should have…

  1. A decent understanding of what disk-type devices you have in your computer
  2. A working memory of which partition is used for what purpose
  3. The ability to differentiate between which root GRUB is asking you for at which time

I’ll explain what #3 means more in a minute, but first let’s start with #1 – building a decent understanding of what disk-type devices you have in your computer:

Unix-like operating systems locate all system devices in a folder hierarchy, starting with /dev

Where * denotes a number or letter for ordering, typical disk-type endpoints in the /dev folder are /dev/sd** and /dev/nvme*n*p* in Linux, /dev/da* and /dev/ada* in FreeBSD, or /dev/dsk/c*t*d* and /dev/rdsk/c*t*d* in Solaris-like OS.

While not all these OS use GRUB by default, all of these OS are potential consumers of the GRUB bootloader, and all must have a bootloader of some kind, so understanding what to look for might become useful even if not specifically troubleshooting GRUB.

But, back to GRUB specifically, the only reason you need to know which /dev your disk is is so you can point GRUB to which partiton to ultimately boot from.

That’s because the GRUB prompt throws the standard heirarchy for disk devices and partitions out the window, and instead presents you with an ordering system that looks like this:

grub> ls
(hd0) (hd0,gpt1) (hd0,gpt2) (hd0, gpt3) (hd0,gpt4) (hd1) (hd1,gpt1) (hd1,gpt9)
grub>

This is an actual scenario of a computer with two hard drives, (hd0) and (hd1), the first drive is configured to boot using UEFI. (hd0) is a typical partition structure created by default using an Ubuntu installer. (hd1) looks like what you might see when looking at a volume formatted using ZFS (which is beyond the scope of this article).

Which brings me to topic #2: You need to be able to remember which partition is responsible for what function

Say (hd0,gpt1) is your installer-created EFI partition. That is very common, so it’s an easy guess that’s likely to be correct. But which partition holds your vmlinuz or initrd.img? Is it on the EFI partition, as required by systemd-boot? Or the second partition which is standard for many automated GRUB installations?

Which partition holds your root directory, is it (hd0,gpt3) or (hd0,gpt4)? Do you remember which one is swap? Because you can’t boot to that…

If you hadn’t noticed the correlation of the GRUB partition ordering scheme to a standard Linux /dev ordinal, here’s a chart on how it breaks down:

GRUB OrdinalsSATA/SAS OrdinalsSCSI OrdinalsNVME Ordinals
(hd0,gpt1)/dev/sda1/dev/sga1/dev/nvme0n1p1
(hd0,gpt2)/dev/sda2/dev/sga2/dev/nvme0n1p2
(hd0,gpt3)/dev/sda3/dev/sga3/dev/nvme0n1p3
(hd0,gpt4)/dev/sda4/dev/sga4/dev/nvme0n1p4
Note: This is an example of a typical Ubuntu installation, but not everyone’s partitions are ordered the same way, so learn what signs to look for that indicate which one is which

If you remember your root partition is /dev/sda4, and your boot partition is /dev/sda2, it will come in handy for this process. So look for the signs while your computer is working so you can remember how to get yourself out of the potential mess that is the inevitable, eventual greeting by the dreaded GRUB prompt!

Here’s a real world example of some partition structures using lsblk:

$ lsblk -pf
 NAME FSTYPE LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT
 /dev/sda
 │
 ├─/dev/sda1
 │    vfat         D76E-7DEB                             807.3M    19% /boot/efi
 ├─/dev/sda2
 │    ext4         b1cfa7fa-cd24-469a-87fb-d28f0062fb65  692.7M    22% /boot
 ├─/dev/sda3
 │    xfs    root  31aad6f4-98bf-4ae1-a00c-cfa43be07840   12.2G    66% /
 └─/dev/sda4
      swap         d07bf51d-1ef9-4d07-bc86-450945e83a93                [SWAP]
 /dev/sdb
 │
 └─/dev/sdb1
 /dev/sdc
 │
 ├─/dev/sdc1
 │    zfs_me epool 11659485700310844622
 └─/dev/sdc9
 /dev/sdd
 │
 ├─/dev/sdd1
 │    zfs_me epool 11659485700310844622
 └─/dev/sdd9

You can see the first drive, /dev/sda , is the drive used to boot from. It has an EFI partition, a /boot partition, a / (root) partition, and a swap partition. Get to know these and remember which one’s what.

These would subsequently correspond to the following:

in GRUBin LinuxPurpose
(hd0,gpt1)/dev/sda1efi
(hd0,gpt2)/dev/sda2vmlinuz, initrd
(hd0,gpt3)/dev/sda3root
(hd0,gpt4)/dev/sda4swap
The breakdown of how these partition ordinals correspond to one another, depending on which interface you are interacting with. This is a good thing to remember!

Issue #3: Say you can remember these, you know what each of them do. Can you figure out what the GRUB prompt is asking you for?

GRUB prompt will ask you for root. This has two different meanings in the context of the GRUB prompt.

The first root is which partition you will be browsing, loading files from, etc. The second one will be the one that you will be booting from.

Try it – here’s how the first root works (the one that’s only relevant in GRUB):

grub> set root=(hd0,gpt3)
grub> ls /
 bin   etc   lib32   media  proc  sbin        srv  usr
 boot  home  lib64   mnt    root  selections  sys  var
 dev   lib   libx32  opt    run   snap        tmp

Structure look familiar? This is your root partiton.

grub> set root=(hd0,gpt2)
grub> ls /
config-5.10.0-1013-oem   lost+found
 config-5.4.0-26-generic  System.map-5.10.0-1013-oem
 config-5.4.97            System.map-5.4.0-26-generic
 config-5.4.98.zfs        System.map-5.4.97
 efi                      System.map-5.4.98.zfs
 grub                     vmlinuz
 initrd.img               vmlinuz-5.4.97
 initrd.img-5.4.97        vmlinuz-5.4.98.zfs
 initrd.img-5.4.98.zfs    vmlinuz.old
 initrd.img.old

Now GRUB’s root is set to your boot partition…

It’s important to know what the EFI partition looks like, too, so here is an example of an EFI partition with both GRUB and systemd-boot:

grub> set root=(hd0,gpt1)
grub> ls /
b0993a91342e4baea30901c5d7533f4d  EFI  loader  ubuntu
grub> ls /EFI
BOOT  Linux  systemd
grub> ls /EFI/BOOT
BOOTX64.EFI

That BOOTX64.EFI file is what you’re interfacing with right now – that’s the binary responsible for the GRUB prompt.

You can use this navigation feature in conjunction with TAB completion to try and figure out which partition is which – if you recognize what kind of files are located in the root of these partitions and what they are used for.

To boot, you need both a vmlinuz and an initrd.img file. On most machines installed with GRUB as the primary bootloader, these will be located on your second partition when configured with UEFI.

TL;DR

Now you’re going to set the GRUB root to the partition you want to boot from, then tell Linux which partition you want to be the root once it boots (!) (got that?)

Here’s the whole command sequence to initiate the boot process:

grub> set root=(hd0,gpt2)
grub> linux /vmlinuz-5.4.98.zfs root=/dev/sda3
grub> initrd /initrd.img-5.4.98.zfs
grub> boot

So, see, when setting the location of the Linux kernel executable, the root you’re supplying there is not the root for GRUB, but the root for Linux (once you’ve booted). It’s confusing, so I figured I’d repeat it.

And, this might be obvious, but I’ll mention it just to be thorough: Choose the corresponding vmlinuz and initrd.img files from the same initramfs compression process – don’t use vmlinuz from 5.10.0-1013-oem and initrd from 5.4.0-26-generic, for example.

Let’s break these aforementioned commands down into each part:

grub> set root=(hd0,gpt2)

Set the partition GRUB will be looking at to your boot partition (if it’s /dev/sda2, for example)

grub> linux /vmlinuz-5.4.98.zfs root=/dev/sda3

Set vmlinuz-5.4.98.zfs as your Linux kernel executable (don’t forget the / to signify it’s position located in the root you set in the first step). While setting the root Linux will be using once you’re all booted up (in this case, root=/dev/sda3) (can’t say that enough times)

grub> initrd /initrd.img-5.4.98.zfs

Set initrd.img-5.4.98.zfs as your initramfs archive (again, don’t forget the leading / )

grub> boot

Start the boot process using the two variables you just set in the last two steps

IF YOU GET STUCK: Try browsing the other partitions to see if you’re setting GRUB root properly, try a different vmlinuz and initrd.img (maybe the one you first tried was hosed?), you can get a list of commands using help at the prompt…

And if all else fails, boot to a live installer USB and rebuild GRUB from chroot

If you make it through this, I know you’ll be loving your computer again in no time…

hot…

Easing pain of migration from Google Hangouts to Google Voice (as much as humanly possible)

Parting Hangouts is not sweet sorrow…

Some of us have been using Hangouts for ages. Essentially since Google recommended we switch from texting with Google Voice way back May of 2013.

Well, now they’ve dropped the hammer again, and said we have to switch back to Google Voice, since for whatever reason they’ve decided to terminate Hangouts altogether.

What gives? I’d been enjoying Hangouts quite a bit, as it fits my workflow perfectly, and had adapted to it in every minute detail through years of experience in daily life.

And now you want to make that all go away?

Unlike many other things, for which I’m an eager participant for early adoption, I was determined that Hangouts would have to be depreciated out of my cold, dead fingers.

That day appears to have come today, when suddenly my Hangouts window ala Chrome Extension’s box for entering text just disappeared.

Sure, my phone had been bugging me that I should “check out Google Voice” for over a month now, so I knew this day was coming, but I didn’t anticipate it would be like this – while in the middle of a project for a time-sensitive client I suddenly couldn’t text back to (!).

So I set out to see how much I could make Google Voice’s window look like Hangouts. Here’s what I came up with:

Start with an empty Chrome window

Navigate to https://voice.google.com – if you don’t have an account, sign up for one and set up your phone preferences (For instance, I like how it can ring all my numbers, but would never opt to get even more email… perhaps you feel differently?)

Go to the 3 dots menu in the top right hand side of the Chrome window and select More Tools -> Create Shortcut

Give your shortcut a fancy name, like "Voice" (look, it’s even done for you)

Desktop shortcut for Google Voice

If you look on your desktop, you should have the shortcut now. Open it! Ooopen iiiitt…

Then go to the text message menu and scrunch it up until it starts to look like Hangouts! Looks similar enough… 🤷‍♀️

It’ll take some getting used to. One thing that really upsets me is I can’t directly copy + paste images straight into the text box like I could in Hangouts – I had just gotten good at finding pertinent GIFs in Google Image Search! 😥

The best you can do is drag an image you have already saved to your computer 😕

You can save images from this odd view it does inside the scrunched-up window. Unlike Hangouts, it takes an additional step to view the full-size image in another browser Window (gee, Google, all this extra work, I thought this was supposed to be better?)

But all in all, I suppose I’ll live now that I was able to eliminate that gawd-awful bar at the top of the Window.

Life continues apace

PSA: Menus not staying open in Supermicro IPMI? Here’s how to fix it:

I’ve noticed this a couple times in the last week – I had an iKVM window open on my Supermicro host, trying to control the ESXi DCUI, and the menu wouldn’t stay open. It’s very frustrating.

I don’t have a physical monitor hooked up to any of my hosts, so this is a pretty important thing to have working in the event I need to change a setting only available on the “physical” host’s menu.

Say you have two ways to interface with the IPMI firmware – like, iced-tea javaws and Supermicro’s IPMIview:

$ ls /opt/IPMIView_2.17.0_200505 

account.properties  IPMIView20_User_Guide.pdf           libSharedLibrary64.so
BMCSecurity         IPMIView_MicroBlade_User_Guide.pdf  libSharedLibrary_v11_32.so
email.properties    IPMIView.properties                 libSharedLibrary_v11_64.jnilib
iKVM                IPMIView_SuperBlade_User_Guide.pdf  libSharedLibrary_v11_64.so
iKVM32.dll          jre                                 PMingLiU-02.ttf
iKVM64.dll          JViewerX9                           ReleaseNotes.txt
iKVM.jar            JViewerX9.jar                       SharedLibrary32.dll
iKVM.lax            JViewerX9.lax                       SharedLibrary64.dll
iKVMMicroBlade.jar  lax.jar                             SharedLibrary_v11_32.dll
iKVM_precheck.jar   libiKVM32.so                        SharedLibrary_v11_64.dll
iKVM.properties     libiKVM64.jnilib                    sort.properties
iKVM_ssl.jar        libiKVM64.so                        stunnel.properties
iKVM_v11_32.dll     libiKVM_v11_32.so                   timeout.properties
iKVM_v11_64.dll     libiKVM_v11_64.jnilib               TrapReceiver
IPMIView20          libiKVM_v11_64.so                   TrapReceiver.lax
IPMIView20.jar      libSharedLibrary32.so               TrapView.jar
IPMIView20.lax      libSharedLibrary64.jnilib


— VS —

 $ javaws launch.jnlp 
 
selected jre: /usr/lib/jvm/default-java
Codebase matches codebase manifest attribute, and application is signed. Continuing. See: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/no_redeploy.html for details.
Starting application [tw.com.aten.ikvm.KVMMain] ...
Buf size:425984
a singal 17 is raised
doris getscreen ui lang
doris 0 0

The first time this happened, I am pretty sure it’s because another instance of the iKVM window was open (I was unwittingly trying to use a 2nd iKVM – for example, launching launch.jnlp with IcedTea when an IPMIview instance is open – windows get lost sometimes!). This presumably could happen between using two separate remote machines at once, although I cannot confirm from experience.

The menus won’t stay open. It launches, it looks like it should work, but none of the menus will open and none of the keys will respond.

The second time this happened to me, there was no explaination – no other open instances. So I’m here to say:

Just reset your IPMI.

To do that, go to the IPMI’s web portal, log in, and navigate to Maintenance –> iKVM Reset.

Getting your IPMI iKVM menus to open again…

Then if there was any instance that wasn’t terminated properly, it will terminate them and allow your menus to work again – which is why I think the 2nd time it wasn’t working, since there was no other instances open at the time.

Best wishes!

Automate kernel module installations for VMware Workstation on your Linux distro

VMWare Archives - The CloudStack Company
VMware Robot does a little dance

In reference to this post I made earlier: https://develmonk.com/2020/10/20/solve-the-system-cannot-find-the-file-specified-error-in-vmware-workstation/

I found the most helpful script, just drop this in a text file called /etc/kernel/install.d/vmmodules.install

#!/usr/bin/bash

export LANG=C

COMMAND="$1"
KERNEL_VERSION="$2"
BOOT_DIR_ABS="$3"
KERNEL_IMAGE="$4"

ret=0

case "$COMMAND" in
    add)
       VMWARE_VERSION=$(cat /etc/vmware/config | grep player.product.version | sed '/.*\"\(.*\)\".*/ s//\1/g')

       [ -z VMWARE_VERSION ] && exit 0

       mkdir -p /tmp/git; cd /tmp/git
       git clone -b workstation-${VMWARE_VERSION} https://github.com/mkubecek/vmware-host-modules.git
       cd vmware-host-modules
       make VM_UNAME=${KERNEL_VERSION}
       make install VM_UNAME=${KERNEL_VERSION}

       ((ret+=$?))
       ;;
    remove)
        exit 0
        ;;
    *)
        usage
        ret=1;;
esac

exit $ret

It’s so exciting! That should download, compile, and install the proper vmmon and vmnet kernel extensions required for Workstation every time a new kernel is installed (!!).

Now I just have to work out a way to get the MOKutil key submission in there for secure boot, but it’s definite a good start to making the installation of new kernels less painful for Workstation users on Linux.

Tested in: Ubuntu 20.10

Reference:
https://docs.fedoraproject.org/en-US/quick-docs/how-to-use-vmware/

Solve “The system cannot find the file specified” error in VMware Workstation

If you’ve ever run into this, it’s a real bummer. I encountered it after using rsync to clone a vm.

At the outset, I want to say either using vm -> manage -> clone or file -> export to OVF are both easier options, but if you’ve already copied a vm by hand, you can try this out:

After I rsynced my VM, I wanted to rename the files to differentiate it from the old VM.

For the example, let’s say my old VM’s name was Windows Ent EFI and I wanted to rename it to winInsiders

I use this one-liner just to rename the .vmdk files:

for f in *.vmdk; do mv "$f" "$(echo "$f" | sed s/"Windows Ent EFI"/winInsiders/)"; done

and renamed the remaining files {$f.nvram, $f.vmds, $f.vmx, $f.vmxf} by hand (wanted to be careful)

At first, I had forgotten about references in the winInsiders.vmx to old filenames, so when I tried to re-add the hard drive, I ran into the “cannot find the file specified” error

I deleted any .lck directories first (not sure if this is necessary, but it seemed like a good idea)

Then I looked inside the .vmx file with a text editor, and found a few keys that needed new values, because they referenced the old names.

They were:

nvram
extendedConfigFile
scsi0:0.fileName

There could always be more, that’s why instead of editing it by hand, run sed on the .vmx file, as it is faster and far less error-prone (just like the renaming command above, but with the -i flag, meaning inside the file):

sed -i s/"Windows Ent EFI"/winInsiders/g winInsiders.vmx

Then do the same for the .vmxf and first .vmdk file (the first .vmdk in a split virtual disk is just a file descriptor, plain text):

sed -i s/"Windows Ent EFI"/winInsiders/g winInsiders.vmxf
sed -i s/"Windows Ent EFI"/winInsiders/g winInsiders.vmdk

It should work now (at least, it did for me).

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:
https://copdips.com/2018/05/setting-up-powershell-gallery-and-nuget-gallery-for-powershell.html

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:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/gcc/x86_64-linux-gnu/4.8:/usr/games

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

Scripting Containers With No Daemons using Podman - DEV Community

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:
https://github.com/nvm-sh/nvm

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:

https://github.com/mkubecek/vmware-host-modules/releases

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!

References:

https://github.com/mkubecek/vmware-host-modules/releases

https://askubuntu.com/questions/1135343/ubuntu-19-04-vmware-kernel-modules-updater

https://kb.vmware.com/s/article/2146460