As companion devices I have a Lilygo T-Deck and a WishMesh Tag, both have their unique selling points. 

I also got two solar/battery powered repeaters, the WishMesh Repeater Mini. The latter has had quite a few annoying hurdles. "Annoying" because there are undocumented things which you have to learn via word of mouth. 

Most importantly ...

1. The RAK4631 board will frequently "hang" under normal conditions. The processor itself is still working and you can connect via Bluetooth or USB, but it's no longer sending or receiving any traffic at all. Nothing. The radio goes dead silent. The only fix is to hard reboot the device. I've even had to reflash it a few times. 

The fix? You have to set a processing delay for received traffic. It's a setting that cannot be found in the Meshcore app for iOS, you have to either set it through the USB configurator, or via the command line. Setting a 4ms delay will leave the RAK4631 fully stable for weeks on end. 

2. The RAK461 over-the-air (OTA) update does not work the way you think it does. When you run "start ota" in the command line you can then connect to the repeater using Bluetooth in the "DFU" app. The device will be called "RAK4631_OTA". Selecting the image and device and clicking the upload button will show one green checkmark and three red failures. The boot loader gets enabled, but then the process dies.

I had to learn via-via on Discord today that this is expected. You are now supposed to pick another Bluetooth device, called "4631_OTA" and then repeat the process. This will then complete the upload and the writing to flash storage, after which it reboots. This, again, isn't in most of the manuals I'd found online. At least not in any of the docu included by the official sources. 

3. The OTA update absolutely requires that you first install the "OTAfix bootloader", which improves the implementation of over-the-air storage flashing. You can fetch the required .zip / .uf2 file from the web flasher. Getting it onto your device is another exercise, because they do not include any proper instructions!

I had to piece the instructions together from various sources. I settled on this guide on hackster.io, by following the Linux-instructions (running Python3 on my Mac). On my Mac the RAK4631 was linked to device "/dev/tty.usbmodem1301". With the Python-based instructions I was able to flash the OTAfix bootloader that's compatible with my device. After that, the OTA updates worked as described under item 2.

A frustrating bit of tech this, if you're new.

EDIT:

With thanks to PE1HVH: one article which discusses what I write under item 2 in great detail, is this guide at DOMCA.

At the time I thought it was because I'd forgotten to ensure reboot-readiness of all of my solutions. This morning, while I took the exam, I realized it was probably something else: naming. 

RedHat is very clear about the names that your resources and objects should have. I realized that, when you use Podman / Docker Compose, unless you explicitly specify a name the resource name is a combination of three things:

1. The directory name where your container-compose.yml lives.


2. The object name in the container-compose.yml file.


3. A sequence number.

For example, if I have a compose-file in ~/task5, in which I defined a service called "vote-worker", then the resulting container name will not be "vote-worker"; it will be "task5_vote-worker_1".

That's what got me zero points on the test!. 

So I passed this morning.

My practice exams, which do not break NDA, have been updated.

My Proxmox cluster has always been plagued by network hangs, where my primary network connection unexpectedly dies. Fully stops working. That was not fun, but when I enabled HA clustering it goes worse: now nodes would literally reboot or turn off!

Many threads on Reddit and the Proxmox forums say (for years on end) the issue was with specific performance features and the hand off from CPU to the NIC. I tried all their fixes, but they never helped. Every few days, despite the additional settings, my cluster nodes would die.

Turns out, the problem is with my Ubiquiti gear which has a feature which literally cannot be turned off: Energy Efficient Ethernet, aka Green Ethernet, aka 802.3az.

Ubiquiti themselves are keeping quiet about it and their documentation never mentions it. Chatbots think it's in the UI, but it's not. My Unifi gear forces EEE, which the e1000 in Proxmox doesn't support properly. And thus the network connection glitches, and thus my cluster fails.  

The fix for me: in "/etc/network/interfaces", I added the following lines:

    # For network card vmbr0, the bridge for all real traffic
    post-up ethtool -K vmbr0 tso off gso off

      # For "nic0",  the physical network card:
      post-up ethtool --set-eee nic0 eee off
      post-up ethtool -K nic0 tso off gso off

I did that three weeks ago. Since then I have had zero crashes.

Putting that aside: compared to the last time I took EX188 things have both improved and worsened.

The remote exam experience has improved somewhat, insofar that the testing environment works reasonably well on my Asus laptop. Maybe I just got lucky with my hardware selection, because both the laptop, the wifi, the audio and my Razr Kiyo webcam all worked fine. 

There's a few things that still suck: sometimes the full-screen mode gets so big that certain screen elements will just not be visible. The proctor informed me that I can zoom with <ctrl><+> and <ctrl><->. What's even worse: when I'm editing text in vi, pressing the <esc> key will make the exam environment leave full-screen mode. This leaves me working with roughly 50% of my actual screen. 

I'm also not nearly as happy with the exam content as I was last time. I had six assignments, five of which I'd finished in the first hour. The final task sent me on a wild goose chase, until I told myself a stern lesson:

If it feels like the exam has you troubleshooting something that's not on the objectives, then you're looking in the wrong place! If the software or service that you're troubleshooting is not part of EX188, look at the parts that are. Go back to the basics of what makes a running container; inspect the environment you're given.

The first four tasks felt sloppy and contrived, not at all like the way you'd use Podman or containers in real life. 

I know exactly what I did wrong. 

The exam objectives very specifically state:

As with all Red Hat performance-based exams, configurations must persist after reboot without intervention.

Do not take that lightly. Do not. 

My exam consisted of six tasks, and I'm sure that for two of those I forgot to ensure my solutions would survive a reboot. Thus I scored 0 points on the two relevant objectives. 

I'm retaking on Monday and I know exactly what to pay attention to this time. 

Now, I don't know why I scored <100% on the other tasks, so I'll pay extra attention to those as well. I could've sworn it was all bang-on. 

I recently hooked up my Proxmox nodes to JetKVM remote consoles. At the time I couldn't do real power management, but at least I could trigger a remote power-on after a full failure. 

The Wake On LAN and Wake On USB features of the Optiplex Micro 7020 worked perfectly fine with the JetKVM. But, I got those JetKVM DC control modules for a reason! I want the possibility to remove power completely!

As I mentioned last time, those DC control modules aren't compatible with Optiplex Micros out of the box. The DC box has a 5,5x2,5mm barrel plug, while the Optiplex has 4,5x3,0mm.

I decided to make my own cable, to connect the PC to the DC controller. I used:

• Akyga low voltage replacement cable with 4,5x3,0mm and an open end.


• BKL Electronics 5,5x2,5mm barrel plug.

The Akyga cable has three wires: black for ground (outside), red for positive (inside) and white for the ID/sense pin. I trimmed the white wire away as neither the BKL plug nor the JetKVM has it. 

I have to admit: I'm out of practice! I need to solder more often! I'm clumsy and I had to redo the job five times before I had a result I would trust with 60-90W and my fire safety. 

For safety I first did a test with a spare Optiplex and just the DC box and a spare power supply (with the 5,5mm plug). No sparks, no smoke, but the Optiplex didn't turn on either. 

I took a multimeter to the devices and the spare power supply worked fine. But on the  JetKVM DC output I didn't see 19.2V, I saw 1.3V. ... That's not zero! That gave me a hunch.

Since there were no sparks, I decided to actually hook up the JetKVM itself. It turned on! Power is working! And indeed, when used the DC power control extension in the web interface, turning on power sent 19.2V to the output! The Optiplex turns on! It works! :)

But a new challenge appeared!

Alert! A 0W AC power adapter has been detected.
The system can only boot with a 90W power adapter or greater.

Yup that makes sense: because there was no ID / Sense signal on the center pin, the Optiplex cannot recognise the power supply. This is a common issue with replacement power supplies. There's a two solutions.

One is a filthy dirty hack where you break open the power supply to move the ID chip into the computer, or you talk to it in some other way. 

The much better way is to just disable the warning. In the Optiplex MFF UEFI you'll find it under Pre-boot Behavior > Adapter Warnings.

Now the Optiplex boots perfectly fine! And I can fully cut, or turn on, power remotely.

It would only work with one out of all of the laptops in our home, the old gaming laptop I inherited from Dick. It wouldn't even work with my then-new Asus Zenbook! It also wouldn't work with my Razr webcam either, so I had to use an ancient 720p Logitech cam. 

Red Hat have since then worked on improving their kiosk exam bootable USB. With the latest 2026 ISO it does work on my Asus and my Razr cam also works. There's still two final nags I have with it:

1. Once you finish setting up your hardware and reach the exam / compatibility test screen, you cannot go back to reconfigure things. If your networking isn't great or you forgot to setup something else, you'll have to fully reboot. 


2. Multiple people are getting network connection test errors during the compatibility test, while streaming and downloading does work. According to one Red Hat employee this is a known issue and they're working on it. It's not a breaker, your exam will work fine. 

That link will stop working in two days, because in a very strange move Red Hat are killing their learn.redhat.com forums. The one place where students and test takers could communicate and share experiences will go away. :(

Those fora are also where Red Hat would inform us about new ISO images for the remote testing solution. So I wonder how they're gonna do that per April 1st.

I have tried quite a few things, both from the Proxmox and the Debian / Ubuntu forums, to deal with the e1000 hang issues. So far, no dice.

Every few days, maybe after a week, the Proxmox node running my VMs will experience a hang on the e1000 causing it to lose its network link. And because it loses its link, the Proxmox HA watchdog will fence it off by shutting the node down. The other node in the cluster takes over just fine, with a max of 5 minutes data loss.

That's well and good, but I'm stuck with a problem: I couldn't get the failed node back up without actually visiting the office. 

I bought two JetKVM network KVM devices so I could remote control the keyboard, video and mouse of the two Dell Optiplex 7020 MFF that run my cluster. They work reasonably well, despite some HDMI signal issues from time to time. But because they are powered by USB from the Optiplex, if the PC is off, so is the JetKVM. 

With the Jets, I also bought the JetKVM DC Power Control Extensions. The engineering is nice and they should work perfectly fine, except for one thing: the coaxial plugs on the DC PCE is much bigger (5.5x2.5mm) than the one on the 7020 MFF (3.5x1.3mm). They are grossly incompatible. Using these DC PCEs would be great because the JetKVM would always be powered on, but to use these with the power adapters from the 7020 would mean either soldering, or getting conversion plugs.

In the long run I will still need to get these to work, because the Unifi UPS Tower I bought does not have a feature which allows you to power cycle one specific outlet. 

The good news

I've found a few UEFI options on the 7020 MFF which will let me use the JetKVMs exactly how I want them: to remotely power on a Proxmox node which had shutdown. 

You need the following:

1. The JetKVM must be connected to the "Smart PowerOn" USB port on the back. There is only one. In this manual page it is indicated with number 4.


2. In the UEFI settings for the 7020 MFF you must enable "Wake on USB".


3. In the UEFI settings for the 7020 MFF you must also enable "Wake on LAN". 


4. In the UEFI settings ensure that the 7020 will automatically default to "power on" after power is restored if it failed.


5. In the UEFI power settings you must fully disable deep sleep.


6. Take a note of the MAC adres for the 7020; it will be called "LOM MAC" or something like that in the system overview page. 


7. In the JetKVM web UI, add this MAC address in the Wake On LAN section. 


8. Once you've done all this, power down the 7020 and power it back on. 

From now on, the JetKVM will always be on; it will only power off once power is actively cut from the 7020. Once power is restored, the 7020 will automatically power on. If the OS is shutdown, the JetKVM will stay powered on! And you can wake up the computer again using the Wake On Lan button in the JetKVM UI. 

Marvelous!