DIY on Zwindler's Reflection

OCI Artifacts as LXC Machine Base on Proxmox 9.1, Finally?

Mon, 24 Nov 2025 18:00:00 +0200

Context

A few days ago, the Proxmox VE dev team announced a new version (9.1) whose major new feature is the addition of OCI artifacts support as a base for creating LXC containers.

A long-awaited feature, since in theory it finally opens the door to launching “Docker”-type containers in Proxmox, something the Proxmox devs had always refused.

That’s also why one of my blog articles gets the most traffic on Google (sniff, soon the end of glory):

This article where I explain how to launch Docker containers (via LXC) in Proxmox VE (normally not possible)

Create LXC containers from OCI images

Proxmox VE 9.1 integrates support for Open Container Initiative (OCI) images, a standard format for container distribution. Users can now download widely-adopted OCI images directly from registries or upload them manually to use as templates for LXC containers. Depending on the image, these containers are provisioned as full system containers or lean application containers.

Let’s Test? First the Prerequisites

So, I’m curious, how does it work?

First, you need to pre-download the image you’re interested in to your storage (one that can host “CT Templates”).

Fun thing, there’s a button called “Query tags”, which I imagine retrieves a list of tags. Well, it’s not starting well, it doesn’t work (at least not on docker.io…).

command 'skopeo list-tags docker://docker.io/zwindler/prime-calculator' failed: exit code 1 (500)

EDIT: since then, it works again, on all my nodes. Perhaps a temporary issue.

Note: skopeo is precisely one of the dependencies used in my “proxmox+docker hack” article that allows manipulating (mainly downloading) containers from remote registries.

Creating the LXC Container

Now that the template (the OCI image) is available on our storage, we can create an LXC container as usual. Click on “Create CT”, give a CT ID, a password:

For the template, we choose our OCI artifact:

And validate. Proxmox should create our container:

Even though the terminal tells us that application containers may not work well in the JS console, for all the containers I managed to start (see below), I always had a functional console.

So the bet seems rather successful.

Example with docker.io/python:3.11.14-trixie

When It Wasn’t Working (Yet)

I had 2 issues on a Proxmox VE 9.1 (that had been upgraded and tinkered with a bit, in short, a machine that had seen some use) starting an LXC container on OCI base with Proxmox VE 9.1 because I ran into 2 bugs.

I didn’t reproduce these bugs on a “fresh” install.

First Bug: “from scratch” Image

First, my prime-calculator image wasn’t even created.

TASK ERROR: unable to create CT 106 - Error while extracting OCI image: Unknown layer digest sha256:2bc4d17e1eb16f6b52acbafeb6d86c8f3eaf9588a5e2a7a245b6bb1d85e93396 found in rootfs.diff_ids: Unknown layer digest sha256:2bc4d17e1eb16f6b52acbafeb6d86c8f3eaf9588a5e2a7a245b6bb1d85e93396 found in rootfs.diff_ids

OK, fair enough. My image is a binary “from scratch”, with nothing but the binary, and maybe I made a mistake somewhere…

Still doesn’t work.

Second Bug: Unable to Start

However, even with known images, the container is properly created:

But impossible to start it:

problem with monitor socket, but continuing anyway: got timeout
TASK ERROR: unable to get PID for CT 105 (not running?)

Same error with command line:

pct start 105 --debug
problem with monitor socket, but continuing anyway: got timeout
lxc_start_main: 257 Container is already running
- Read uid map: type u nsid 0 hostid 100000 range 65536
INFO confile - ../src/lxc/confile.c:set_config_idmaps:2295 - Read uid map: type g nsid 0 hostid 100000 range 65536
ERROR lxc_start - ../src/lxc/tools/lxc_start.c:lxc_start_main:257 - Container is already running
unable to get PID for CT 105 (not running?)

After (laborious) investigation, it turns out it’s an AppArmor problem. I don’t know if I caused it with my tinkering or if it’s a more generalized bug for now (probably option 1, but 2 isn’t impossible either…)

Nov 23 10:37:26 node01 systemd[1]: Started pve-container-debug@105.service - PVE LXC Container: 151.
Nov 23 10:37:27 node01 kernel: audit: type=1400 audit(1764067047.008:175): apparmor="DENIED" operation="create" class="net"
Nov 23 10:37:27 node01 kernel: audit: type=1400 audit(1764067047.008:176): apparmor="DENIED" operation="create" class="net"
Nov 23 10:37:27 node01 systemd[1]: pve-container-debug@105.service: Deactivated successfully.
Nov 23 10:37:37 node01 pct[21369]: unable to get PID for CT 105 (not running?)

The temporary (and dirty) workaround is to disable the AppArmor profile for lxc-start, and remove any zombie files/processes.

apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start

ps aux | grep "lxc-start" | grep "105" | awk '{print $2}' | xargs -r kill -9
rm -f /var/lib/lxc/105/config.lock
rm -f /run/lxc/lock/var/lib/lxc/105

Note: You can also disable it permanently, but that’s obviously something you shouldn’t do.

From there, the container is accessible, sometimes in console (depends on the container)

Conclusion

Apparently, the problems I encountered don’t reproduce on a “fresh install”. So it’s probably an issue related to my “old” machines.

As a bonus, another article in English that made me persevere when I understood it worked for some:

Raymii.org blog - Finally, run Docker containers natively in Proxmox 9.1 (OCI images)

Note: this article helped me rediscover the pct enter CTID command that allows you to log into the container.

In the meantime, you still have my hack ;-)

Flash Your Xiaomi Mijia Thermometers to Extend Battery Life by a Year

Sat, 15 Nov 2025 12:00:00 +0200

€2 Thermometers That Become a Financial Drain

From time to time I tell myself I should get into home automation. After an attempt 4 years ago (with Jeedom, I didn’t really get into it in the end), I got back into it with HomeAssistant a little over a year ago.

I’ll detail the setup in another article (spoiler: it’s a VM on my homemade 2024 NAS, with a Bluetooth card with a USB passthrough antenna). For now, know that I started simple with just thermometers in each room.

Note: you can see that one room has run out of batteries, and that Home Assistant had been down for 10 days without me noticing haha.

Like many people who want to graph just about everything, even their house (guilty as charged), I started by buying a pack of Xiaomi Mijia thermometer-hygrometers (reference LYWSD03MMC for those in the know).

The main advantage of these little connected thermometers is that they’re very inexpensive: between €1 and €4 depending on sales on AliExpress. Mainly because these are Bluetooth thermometers, much more widespread (and therefore less costly) than Zigbee, Z-Wave equivalents, etc.

You can very easily pair them with a smartphone (Xiaomi provides an app to make it easier) or integrate them into any home automation platform. But the smartphone app is very limited and requires being at very close range (of course).

So, like any self-respecting home automation hobbyist, I connected them to my Home Assistant.

And that’s when the drama started.

As soon as you activate Bluetooth to integrate them with Home Assistant, the CR2032 battery (standard button cell) lasts about 3 months. You very quickly spend more on batteries than on thermometers…

PVVX to the Rescue

Fortunately, the open source community found the solution!

There are two main projects:

The ATC project by atc1441
The PVVX fork (which improves the ATC project)

By flashing your sensors’ firmware with the PVVX version, you can go from a few weeks to over a year of battery life.

I can confirm this: it’s now been about a year (last August) since I migrated all my sensors and I haven’t changed a single battery yet! It’s pretty crazy when you think about it.

Non-negligible bonus: the new firmware uses the BTHome v2 protocol, which drastically simplifies integration with Home Assistant (no more fiddling with HACS and stuff; those who know, know).

Required Hardware

What’s cool about this tutorial is that you don’t need much:

A smartphone (Android or iOS) with Bluetooth
Your Xiaomi thermometers (LYWSD03MMC)
An Internet connection

That’s it! No computer, USB-UART cable, soldering iron, or specialized equipment needed. This is really “flashing for dummies” (myself included).

Flashing Procedure: Simpler Than It Seems

Step 1: Open the Web Flasher

Go to the PVVX flasher site with your smartphone:

https://pvvx.github.io/ATC_MiThermometer/TelinkMiFlasher.html

The flasher works entirely in the browser (not great on Firefox from memory, but 100% OK on Chrome) thanks to the Web Bluetooth API. No app to install, everything happens in the browser. It’s quite magical when you think about it 🤔.

Step 2: Connect the Sensor

Click on the “Connect” button.

Possible confusion: you might think you need to first select the sensor from a dropdown list or something, but no! It’s after clicking “Connect” that a popup opens.

A Bluetooth selection window opens with the list of detected devices nearby.

Select your thermometer (it should be called LYWSD03MMC or something similar with numbers) then click “Pair”.

Step 3: Wait for Connection

Once paired, the sensor information will display on the web page.

From experience, it can take a few seconds, or even require a few attempts. Watch the logs at the bottom of the page to see progress. Bluetooth is finicky sometimes (understatement).

Note: I didn’t really understand if I needed to click “Login” and/or “Activation”. When in doubt, I did both 🤡. It seems to work in all cases, so…

Step 4: Flash the Firmware

Once connected, the list of available firmwares appears.

Leave the default choice: ATC_v47.bin (or the most recent version displayed, at the time I’m writing this draft, it was version v47).

Click on “Start Flashing” and… wait with fingers crossed.

For me, the flash took between 45 and 65 seconds depending on the sensors. Don’t touch anything during this time! Especially don’t leave the web page, otherwise you have to start all over.

Step 5: Verification

Once the flash is complete, the device will temporarily disconnect (a few seconds) then reappear with a new name.

Instead of LYWSD03MMC, it will now be called ATC_XXXXXX (where XXXXXX is a unique identifier based on the MAC address).

Firmware Configuration

Once the sensor is reconnected with its new firmware, you can modify advanced settings if you wish.

The default values are probably optimal in most cases and you can leave them as is. But if you’re like me and you like to tinker, here’s what I personally modified.

Advertising Interval: Save Even More

I reduced the frequency at which the device does its “advertising” (Bluetooth data broadcast).

Default value: ~2.5 seconds
My value: ~7.5 seconds

Advertising Type: BTHome v2 (DON’T TOUCH)

Leave the Advertising Type on BTHome v2 with the AdFlags box checked.

This is the standard protocol promoted by Home Assistant that greatly simplifies communication. With BTHome v2, your sensors will be auto-discovered in Home Assistant without additional configuration.

This wasn’t why I flashed the sensors originally, but it’s really the killer feature!

Beware of Advanced Bluetooth Parameters

Don’t touch BT5+ and LE Long Range options unless you really know what you’re doing.

You risk making your sensor incompatible with your existing installation, and you’ll have to reflash in recovery mode… Not fun.

Integration with Home Assistant

With the PVVX firmware and BTHome v2, integration into Home Assistant is trivial (for once we can say that):

Make sure you have the BTHome integration enabled (it’s native since 2023)
Enable Bluetooth on your Home Assistant server
Your sensors will appear automatically in detected devices

There you go, you can graph the temperature in your house, it’s cool, we’re happy :). As promised, I’ll also (someday) write an article on the more complete configuration on the HomeAssistant side (VM installation, USB passthrough, creating the nice “card”).

In the meantime. Have fun

MicroStack evolves: HP EliteDesk and Lenovo ThinkCentre compatibility for your homelab

Wed, 17 Sep 2025 12:00:00 +0200

A MicroStack update? 😍

Yes! A few months ago, I introduced you to MicroStack, my 3D printed modular rack project for Dell Micro. The project had unexpected success on MakerWorld / Bluesky (and even a bit on Reddit) and I received several requests to extend compatibility…

And since I’m nice (and I like my 3D printing side projects), I decided to respond to community requests!

Promise kept: HP EliteDesk and Lenovo ThinkCentre!

In the original article, I mentioned that “a version compatible with Lenovo ThinkCentre Tiny was planned”. Well… it’s done! And I even made a bonus with HP EliteDesk/ProDesk because… why not?

Now, the MicroStack project officially supports three ranges of mini-PCs:

Dell OptiPlex Micro (all generations) - the pioneer
Lenovo ThinkCentre Tiny
HP EliteDesk/ProDesk

A growing ecosystem

The concept remains the same: stackable and modular modules to neatly organize your homelab. But now, you can mix brands in the same rack if you have a heterogeneous fleet (and we all know how it happens in homelabs… “oh look, this used machine is at a good price!”).

The complete MicroStack collection now includes:

PC Modules:

Dell Micro Module - the original
Lenovo ThinkCentre Module - the requested one (thanks to a loan from someone on LinkedIn! Thanks!)
HP EliteDesk/ProDesk Module - the bonus

Common Modules:

Storage Module - for switch, accessories, etc.
Hat - clean rack finish

All these modules are inter-compatible and use the same stacking system.

Still the same best practices

As with the original, I still recommend printing in PETG (or even ASA or ABS?) rather than PLA for better heat resistance, even though these mini-PCs remain quite cool. The honeycomb floor design ensures good ventilation while saving filament.

The feedback: multi-range modeling

Adapting the original design to new ranges was simpler than expected, thanks to the solid foundation of the initial project. Once the concept was established with the Dell module, you “just” need to:

Take (precise!) measurements of the new models (still need to find them…)
Adapt the chassis dimensions
Do one (or more) test prints and validate stacking (the stress, every time, of having burned 120g of plastic for nothing if you messed up)

Each new module took me about an hour of modeling, much less than the initial 3x2h of the original project. Prototyping (testing incomplete versions to save plastic) took quite a bit of time, which I had forgotten to count in the previous article. Easily a few more hours.

Community feedback

What makes me happiest is seeing that the project found its audience. The feedback on MakerWorld is generally enthusiastic and the evolution requests show that the concept really meets a need.

Some users have already sent me photos of their mixed installations with different brands in the same rack. This is exactly the modular spirit I wanted to bring to the project!

I also had one negative feedback, for which I can’t do much as it stands but which was interesting and allowed me to add a warning. The fact that the back is dedicated to the charger (PSU) blocks some ports, particularly for the Lenovo. The solutions:

Live with only Ethernet (for a lab, personally I think that’s fine)
Move the power supplies to the “storage” module

And now?

With these three ranges covered, my MicroStack project becomes really versatile. If you have suggestions for other mini-PCs to support, don’t hesitate! MinisForum, perhaps?

If this project interests you, feel free to comment, share, provide feedback, or even boost the three models for those who have a MakerWorld account (it’s free, but it’s appreciated :-P).

AppImages on Ubuntu, Example with Bambu Studio

Sun, 04 May 2025 12:00:00 +0200

Bambu Studio and 3D Printing on Linux

For a few months now, as you know, I’ve gotten into 3D printing. And while at the beginning, I started with Klipper (for the 3D printer) and Slic3r (or rather its fork, Artillery Slicer) for slicing, since January I’ve switched to a Bambu Labs printer that I’m very happy with (that comment should upset LinuxFR).

Of course, when I bought the printer, I checked if there was a Linux-compatible slicer, because Windows is fine for gaming (even then) but if I can skip it for 3D printing, that’s good too.

Yes, but…

So yes, it’s “supported” (note the quotes) but it’s not as straightforward as for Windows and MacOS where you just click a button.

A quick visit to the tool’s download site will reveal that we Linux users are indeed second-class nerds for BambuLab.

You can see in tiny text that for Linux, we’ll have to settle for Github releases.

Well, the idea of not bothering and using Wine emulation crossed my mind, but I figured I’d try the official method.

AppImage

There are two options. The first, via AppImages, is the one that’s highlighted but probably not the most “practical”.

Actually, I discovered a bit later that there’s a flatpak available through the flathub repository. The only “downside” is that it requires yet another package manager, but it’s not impossible that you already have it…

So, I’ll stick in this article with the method I used, namely AppImages, because it will allow us to play with Ubuntu’s .desktop files and that’s 2 tutorials in one (and that’s fun).

Download and Launch

This part is the simplest. So we simply go to BambuStudio’s github releases:

github.com/bambulab/BambuStudio/releases

We take the latest one and download it:

Note that AppImages are only available for Ubuntu 22.04 and 24.04 (and Fedora). A few versions earlier, it was 20.04 and 24.04. Since the AppImage is linked to libs (gtk) present on the OS, if you launch the Ubuntu image with the wrong version, it won’t find the lib version and it’s very annoying.

You can cheat by linking the versions so it finds the lib but it’s probably quite risky as a workaround…

sudo ln -sf /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so.0 /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37

Once the archive is downloaded and extracted, you’ll end up with a folder containing the AppImage directly.

If you double-click on it, it should work, Bambu Studio will launch.

Victory?

Yes OK, it works, but it’s still not very practical to go to the Downloads folder and click on the AppImage.

You can obviously move the AppImage to a folder in your PATH (/usr/local/bin) and call it via a terminal, but that’s not great either in terms of user experience (I’m not the only one doing 3D printing at home).

Enter .desktop files. This is a text file that will allow us to add the appImage to Ubuntu’s application list and that’s nice because it’s user friendly.

We’ll move the AppImage to a folder in PATH, and create a symbolic link:

cd /home/zwindler/.local/bin
mv Téléchargements/BambuStudio_ubuntu-24.04_PR-6688/Bambu_Studio_ubuntu-24.04_PR-6688.AppImage .
ln -s Bambu_Studio_ubuntu-24.04_PR-6688.AppImage bambustudio

Why am I creating a symbolic link? 2 reasons.

The first is that if I still want to launch Bambu Studio from my terminal (in case of issues at launch, I want to be able to see the logs), I can do it by simply running the command bambustudio and not Bambu_Studio_ubuntu-24.04_PR-6688.AppImage.

The second is that at the next update, I’ll “just” have to modify the symbolic link to point to the new appImage rather than having to redo all the steps that follow.

By default, all applications in the list are in your .local/share/applications/ folder:

zwindler@normandy:~$ ls .local/share/applications/
appimagekit-openshot-qt.desktop
Bambu_Studio.desktop
chrome-hmjkmjkepdijhoojdojkdfohbdgmmhki-Default.desktop
mimeapps.list
mimeinfo.cache
userapp-Firefox-V48P02.desktop

Here’s what our Bambu_Studio.desktop file should look like:

[Desktop Entry]
Name=Bambu Studio
GenericName=Bambu Studio
Comment=Bambu Studio
Exec=/home/zwindler/.local/bin/bambustudio %F
Icon=/home/zwindler/.local/share/icons/bambustudio.png
Terminal=false
Type=Application

Nothing too extravagant here, we mainly give the application name, a Type, and an execution path (and some additional parameters).

The most observant among you will have noticed that you can also add an icon, it’s true that it’s much nicer to add the Bambu Lab logo than the default icon…

I got the Bambu Lab logo from their Github and placed it in the /home/zwindler/.local/share/icons/ folder:

avatars.githubusercontent.com/u/96461528?s=200&v=4

And here’s the result :)

Addendum

If you REALLY want to do AppImages, there’s a github project with 6k stars, AppImageLauncher, that helps manage AppImages

https://github.com/TheAssassin/AppImageLauncher

makes your Linux desktop AppImage ready™

Basically it’s a launcher for AppImages, which gives you the choice between installing AppImages for you or running them oneshot, deleting and updating images, and a CLI.

Thanks Fabio for the info.

MicroStack - an open source project to 3D print a modular rack for my Dell Micro homelab

Sat, 22 Mar 2025 12:00:00 +0200

AGAIN? Another evolution of your lab???

If you’ve been following the lore of my blog a bit, you know I have as many versions of my homelab as years of experience XD.

2025 will be no exception. In early 2024, I embarked on the construction of a rack based on aluminum profiles and 3D printing (in french), based on a project sent by a friend on Whatsapp!

But in use, I found it massive, not very practical, not very pretty… in short, not adapted to my needs.

Except that (I’ve already mentioned it) I’ve since gotten into 3D printing and a bit (by force of circumstance) into 3D modeling (they often go hand in hand). I said to myself: why not create my own project that fits my needs?

So I wanted to explore a homemade solution for my homelab, 3D printed, that would be both modular and stackable. The idea was to offer an adaptable system according to needs, with a simple and effective design.

A design designed for organization

The MicroStack Rack is designed to neatly store several Dell OptiPlex Micro while maximizing space. It consists of three different modules for now:

The PC module, which accommodates a Dell Micro (all generations) and its external power supply at the back for more practicality.

The storage module, an empty compartment for accessories, network switch or other equipment.

The hat, an optional element that covers the rack for a cleaner rendering.

All modules are stackable, allowing you to adapt the configuration according to your number of machines.

Even though I printed the prototype in PLA, I recommend using PETG instead, which resists heat better than PLA. However, these machines remain rather cool at idle and the honeycomb floor improves ventilation (and reduces material consumption). Maybe it works too.

How long does it take to do this kind of project?

A quick note on time spent.

I haven’t done much 3D design in the past (I made a few maps on Unreal Tournament 2004… oh my…, that was 20 years ago!!!). So, I thought it might be interesting to share how long it took me.

The modeling was done in three sessions of 2 hours:

2h to take measurements, make an initial prototype and get familiar with Blender.
2h to create the module dedicated to the Dell Micro.
2h to add the storage module and the hat (it goes faster, I’ve already done part of the work and I’m more efficient in my use of Blender).

We can add an hour or two for handling the 3D printer (launching the print, checking it doesn’t fail a few minutes in, cleaning the plate after printing, etc.) and 3-4 hours for the “social” part (photos, upload to makerworld, writing descriptions and blog post, sharing on social networks).

A nice little side project of about ten hours then.

Files and evolutions

As promised on Bluesky where I teased the project, the files were created under Creative Commons 4.0 BY-SA license (STL formats and Blender sources), but this is incompatible with MakerWorld exclusive policy (obviously) so the 3MF files are in Standard Digital File Licence:

A version compatible with Lenovo ThinkCentre Tiny is planned for the future (I was asked on Bluesky).

If this project interests you, feel free to comment, share, provide feedback, or even boost the three models for those who have a MakerWorld account (it’s free, but it’s appreciated :-P).

Sidero Omni - Talos Linux on Oracle Cloud (free tier)

Sat, 04 Jan 2025 18:00:00 +0200

Fun fact, on January 4th, 2024 (exactly one year ago), my first article of the year was about Maas. Starting 2025, on the same day, with another article about a solution that aims to automate infrastructure, especially bare metal, is funny :)

Context

I won!!!

I occasionally play games on social media (less often now) and I also sometimes enter contests at conferences.

And there, I won a one-year subscription to Sidero Labs’ SaaS (the creators of Talos Linux), Omni.

For those wondering, Omni is a Kubernetes cluster deployment solution that allows you to orchestrate servers running Talos, a minimalist and secure Linux operating system dedicated to Kubernetes. As for Talos, we’ll certainly talk about it in future articles.

What Does This Have to Do with Oracle Cloud?

Winning is great, it’s always nice. But what do I do with this SaaS now?

The first idea that comes to mind is to order a dedicated server somewhere and install Talos on it (with an ISO generated by Omni), or do the same thing but install a hypervisor, then create Talos Linux VMs (again, thanks to Omni).

But I’m ~~cheap~~ eternally frugal and I saw that Oracle Cloud Infrastructure (OCI) is supported by Talos Linux and Omni, so I wanted to try it.

For those who don’t know OCI, I wrote a series of articles in 2023 explaining how to create a free cluster with kubeadm on the (quite generous) free tier:

We’re going to reuse the free tier here, but to deploy and manage clusters with Omni.

Note: you can reread them, but I’ve done better since then because I managed to integrate free tier machines INTO a managed Kubernetes cluster, which is much nicer to use. Stay tuned for the upcoming article ;).

Prerequisites

For Talos Linux on Oracle Cloud Infrastructure (OCI) and more specifically integrating machines with Omni, there are a few necessary configuration steps.

Note: this tutorial is partially based on the official Talos Linux documentation, adapted for Omni and with additional details on Oracle Cloud Infrastructure.

I’m assuming you already have an account on Oracle Cloud Infrastructure, as well as the talosctl binaries and the oci CLI. Otherwise, a quick:

brew update && brew install oci-cli talosctl

Authenticate with the CLI tool:

oci session authenticate

When authentication is requested, choose the region corresponding to your location (for example, eu-paris-1). Once done, you’ll see a confirmation message in the browser and you’ll need to give a cute name to the profile for oci in the terminal and validate.

Retrieving the Compartment ID

One of the interesting concepts of Oracle Cloud Infrastructure (found in other cloud providers in one form or another) is the notion of “compartment”. Basically, resources are stored in “compartments” to organize resources.

You can work in the “root” compartment, but it’s cleaner to create a specific one for the occasion.

Example OCID:

ocid1.compartment.oc1..aaaaaaaayrmiilkb5m2b7never345435gonna345give87978you12upu6ifoh6csihm4awsjq

Preparing the Oracle Cloud Environment

Once we have that, we’ll use the CLI to create all the things we’ll need for our virtual machines to register on Omni’s SaaS.

Creating a VCN (Virtual Cloud Network) and network configuration:

export cidr_block=10.0.0.0/16
export subnet_block=10.0.0.0/24
export compartment_id=<your_ocid_compartment>

Create the VCN and subnet:

export vcn_id=$(oci network vcn create --cidr-block $cidr_block --display-name talos-example --compartment-id $compartment_id --query data.id --raw-output)
export rt_id=$(oci network subnet create --cidr-block $subnet_block --display-name kubernetes --compartment-id $compartment_id --vcn-id $vcn_id --query data.route-table-id --raw-output)

After the 2nd command, we retrieve not the OCID of the subnet (we don’t need it), but that of the “Route Table”, a subcomponent of the subnet, which allows defining the routing table of the subnet we just created.

Configure a gateway (Internet Gateway):

export ig_id=$(oci network internet-gateway create --compartment-id $compartment_id --is-enabled true --vcn-id $vcn_id --query data.id --raw-output)

Add a routing rule (to our route table) to allow Internet access:

oci network route-table update --rt-id $rt_id --route-rules "[{\"cidrBlock\":\"0.0.0.0/0\",\"networkEntityId\":\"$ig_id\"}]" --force

Disable default firewall rules (YOLO):

export sl_id=$(oci network vcn list --compartment-id $compartment_id --query 'data[0]."default-security-list-id"' --raw-output)

From there, we have the functional network part, ready to host our machines!

But It’s Not Over Yet :-/

With Oracle Cloud Infrastructure, it’s possible to boot a list of predefined OSes, but in our case, Talos Linux is not on the list.

Fortunately, Omni will generate a preconfigured virtual disk with our credentials, which will allow us to enroll Talos Linux servers to our Omni SaaS from the first boot. Classy 😎.

So we connect to our Omni interface and download the appropriate Talos Linux image:

Here, I chose version 1.9.1 (the very latest because we like danger), for amd64 architecture. I retrieve the image oracle-amd64-omni-zwindler-v1.9.1.qcow2.xz which I decompress:

xz --decompress ./oracle-amd64-omni-zwindler-v1.9.1.qcow2.xz

Reminder: OCI’s free tier consists of:

2 amd64 machines with 1 oCPU (= vCPU) and 1 GB of RAM each
a flexible combination of arm64 instances having 1 x n oCPU and 6 x n GB, as long as the total doesn’t exceed 4 oCPU (and therefore 6x4 = 24 GB of RAM).

On OCI, there are several formats for importing disks. The simplest is to use OCI’s “homemade” format (the .oci, super original name), which consists of a metadata file and the QCOW2.

Create the metadata file for import, with the VM.Standard.E2.1.Micro shape since we have an amd64 image (otherwise it’s VM.Standard.A1.Flex):

cat > image_metadata.json << EOF
{
 "version": 2,
 "externalLaunchOptions": {
 "firmware": "UEFI_64",
 "networkType": "PARAVIRTUALIZED",
 "bootVolumeType": "PARAVIRTUALIZED",
 "remoteDataVolumeType": "PARAVIRTUALIZED",
 "localDataVolumeType": "PARAVIRTUALIZED",
 "launchOptionsSource": "PARAVIRTUALIZED",
 "pvAttachmentVersion": 2,
 "pvEncryptionInTransitEnabled": true,
 "consistentVolumeNamingEnabled": true
 },
 "imageCapabilityData": null,
 "imageCapsFormatVersion": null,
 "operatingSystem": "Talos",
 "operatingSystemVersion": "1.9.1",
 "additionalMetadata": {
 "shapeCompatibilities": [
 {
 "internalShapeName": "VM.Standard.E2.1.Micro",
 "ocpuConstraints": null,
 "memoryConstraints": null
 }
 ]
 }
}
EOF

And then create the image for import:

qemu-img convert -f raw -O qcow2 oracle-amd64-omni-zwindler-v1.9.1.raw oracle-amd64-omni-zwindler-v1.9.1.qcow2
tar zcf oracle-amd64-omni-zwindler-v1.9.1.oci oracle-amd64-omni-zwindler-v1.9.1.qcow2 image_metadata.json

Importing the Image to Oracle Cloud

We have the file ready to be uploaded… but where do we upload it??

Unfortunately, this step is done in 2 parts. First, you need to upload the .oci file to a bucket. It’s quite simple to do in the UI (we could also do it via CLI):

Create a bucket in the Storage section to upload the compressed image.
Upload the image (oracle-amd64-omni-zwindler-v1.9.1.oci) to this bucket.

Second step, we transform the file into “Custom images” (in the Compute section):

This step is oddly quite long, the image which is only 100 MB took 10 minutes each time I tried so far.

Creating the VM

Once the image is imported, we can now use our Omni-customized image to boot our free tier machines.

I also did this through the OCI interface, but again, we could do it via CLI.

A few seconds after boot, it appears in Omni’s UI and can be added to a cluster.

Have fun!!

Addendum: Is It Really Free?

Yes…-ish.

In theory, the machines are free (forever free as they say). But beware, lots of little things can be paid.

For example, the bucket where we uploaded the QCOW2/.oci is most likely paid. Same for the custom image, which is billed as 1 GB of storage (according to the UI, I don’t have the bill yet LOL).

If you put the VMs behind a load balancer (there’s no reason you’d do that here), be careful, only the “non-flexible” LB capped at 10 Mbps is free (and only one).

And if like me, you already have 4 x 50 GB disks, the OS storage is paid (€1.85 / month).

In short, as you’ve understood, it’s like often in the cloud, nothing is really free and you have to read all the fine print.

Migrating Cilium routing from iptables to eBPF... hot!

Fri, 20 Oct 2023 06:00:00 +0200

Context

It could be that I configured production Kubernetes clusters with cilium in iptables mode and not eBPF mode. But you have no proof…

However, in the highly unlikely hypothesis that I could have made such a blunder, here’s how I would have gone about solving the problem.

#trollface

So let’s imagine that when checking the Cilium configuration, here’s what you found:

kubectl -n cilium exec -it cilium-aaaaa -- cilium status
[...]
Host Routing: Legacy
Masquerading: IPTables [IPv4: Enabled, IPv6: Disabled]
[...]

Damn!

Looking more closely, the cilium-agent containers in your cilium pods are using a lot of CPU and RAM and are starting to clog up your workers…

This is a disaster.

Why?

The first implementations of the Kubernetes imaginary network (the famous CNI plugins) used iptables. However, we’ve known for a very long time, especially in the Kubernetes use case, that iptables is pretty bad at handling large quantities of rules.

In the particular case of Kubernetes, the number of rules tends to increase exponentially with cluster size, and the CPU consumed to route network packets with it…

At some point, traversing the rules list takes all the CPU of a given node and makes it unresponsive.

Hello boss? We’re in trouble.

This is one of the reasons why I really like cilium as a CNI plugin - the developers were among the first to bet on eBPF as a replacement for iptables (although there are other implementations / other technologies that solve this problem).

How did we get here?

To be honest, I just read the docs and trusted them…

We introduced eBPF-based host-routing in Cilium 1.9 to fully bypass iptables and the upper host stack, and to achieve a faster network namespace switch compared to regular veth device operation. This option is automatically enabled if your kernel supports it. To validate whether your installation is running with eBPF host-routing, run cilium status in any of the Cilium pods and look for the line reporting the status for “Host Routing” which should state “BPF”.

Basically, according to the official docs, if you have the right kernel and the right modules, the cilium installation is supposed to automatically enable eBPF mode… Except that we can clearly see above that this isn’t the case, despite a recent kernel (6.2).

Digging a little deeper into the logs, here’s what you can find:

kubectl -n cilium logs cilium-7b5cp
[...]
level=info msg="BPF host routing requires enable-bpf-masquerade. Falling back to legacy host routing (enable-host-legacy-routing=true)." subsys=daemon

Well… apparently, an option is missing in the Helm chart.

[...]
 kubeProxyReplacement: strict
+ bpf:
+ masquerade: true
[...]

Problem solved, end of article?

Problem

Yes, of course, we can modify the chart like a bull in a china shop and end of story.

But let’s say we don’t want to cut production traffic… How do we do it?

The cleanest solution that comes to mind is the following:

we drain a node
we change its configuration
we uncordon it to put some traffic back on it
we check that the new configuration works AND
we check that nodes can talk to each other between those with iptables and those with eBPF

Because yeah, it would be a shame to have half the cluster unable to communicate with the other half…

Checking connectivity

What’s cool about cilium (did I tell you I love cilium?) is that we already have tooling to test everything.

The cilium CLI has a cilium connectivity test subcommand that launches dozens of internal/external tests to check that everything is OK.

➜ ~ cilium -n cilium connectivity test
ℹ️ Monitor aggregation detected, will skip some flow validation steps
✨ [node] Deploying echo-same-node service...
✨ [node] Deploying DNS test server configmap...
✨ [node] Deploying same-node deployment...
✨ [node] Deploying client deployment...
[...]
✅ All 32 tests (265 actions) successful, 2 tests skipped, 0 scenarios skipped.

There’s also a cilium-health command, embedded in the cilium-agent container, which allows you to get periodic latency statistics between all the cluster nodes. Useful!

kubectl -n cilium exec -it cilium-ccccc -c cilium-agent -- cilium-health status
Probe time: 2023-09-12T14:47:03Z
Nodes:
 node-02 (localhost):
 Host connectivity to 172.31.0.152:
 ICMP to stack: OK, RTT=860.424µs
 HTTP to agent: OK, RTT=110.142µs
 Endpoint connectivity to 10.0.2.56:
 ICMP to stack: OK, RTT=783.861µs
 HTTP to agent: OK, RTT=256.419µs
 node-01:
 Host connectivity to 172.31.0.151:
 ICMP to stack: OK, RTT=813.324µs
 HTTP to agent: OK, RTT=553.445µs
 Endpoint connectivity to 10.0.1.53:
 ICMP to stack: OK, RTT=865.976µs
 HTTP to agent: OK, RTT=3.440655ms
[...]

And finally, we can just look at the cilium status command which tells us who is “reachable” (again, in the cilium-agent container)

➜ kubectl -n cilium exec -ti cilium-ddddd -- cilium status
[...]
Host Routing: Legacy
Masquerading: IPTables [IPv4: Enabled, IPv6: Disabled]
[...]
Cluster health: 5/5 reachable (2023-09-14T12:01:51Z)

Changing a node’s configuration

We’re in luck, because since cilium version 1.13 (the latest to date is 1.14), it’s possible to apply different configurations to a subset of nodes (official documentation for Per-node configuration).

Note: before that, it was still possible, temporarily, by manually editing the cilium ConfigMap, then restarting the concerned pods for it to take effect.

There’s now a CRD to do this, called CiliumNodeConfig. The only things we have to do are add a label to a node (io.cilium.enable-ebpf: “true”) and add the following manifest to our cluster:

cat > cilium-fix.yaml << EOF
apiVersion: cilium.io/v2alpha1
kind: CiliumNodeConfig
metadata:
 namespace: cilium
 name: cilium-switch-from-iptables-ebpf
spec:
 nodeSelector:
 matchLabels:
 io.cilium.enable-ebpf: "true"
 defaults:
 enable-bpf-masquerade: "true"
EOF

kubectl apply -f cilium-fix.yaml

kubectl label node node-05 --overwrite 'io.cilium.enable-ebpf=true'

If you’re in production, the cleanest approach is to kubectl drain the Node beforehand.

Out of curiosity, I still tried to do it “hot”, for fun.

I deployed a daemonset containing a V(lang) app that simply returns the container name in a web page:

cat > vhelloworld-daemonset.yaml << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: vhelloworld-daemonset
spec:
 selector:
 matchLabels:
 app: vhelloworld
 template:
 metadata:
 labels:
 app: vhelloworld
 spec:
 containers:
 - name: vhelloworld
 image: zwindler/vhelloworld:latest
 ports:
 - containerPort: 8081
 imagePullPolicy: Always
EOF

kubectl apply -f vhelloworld-daemonset.yaml

kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
vhelloworld-daemonset-q4h44 1/1 Running 0 3m31s 10.0.4.87 nodekube-05 <none> <none>
vhelloworld-daemonset-w97pv 1/1 Running 0 3m31s 10.0.3.85 nodekube-04 <none> <none>

Then I created containers with a shell and curl to periodically check from multiple nodes that the containers were accessible:

kubectl run -it --image curlimages/curl:latest curler -- /bin/sh
If you don't see a command prompt, try pressing enter.
~ $ curl http://10.0.4.87:8081
hello from vhelloworld-daemonset-g2zdw
~ $ curl http://10.0.3.85:8081
hello from vhelloworld-daemonset-65k2n

~ $ while true; do
 date
 curl http://10.0.4.87:8081
 curl http://10.0.3.85:8081
 echo
 sleep 1
done

Once the label was applied to a node and its cilium pod killed (via kubectl delete), the pods remained accessible:

Fri Sep 15 14:05:34 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

Fri Sep 15 14:05:35 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

Fri Sep 15 14:05:36 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

At some point, cilium restarted, noticed the presence of existing pods, and took over with eBPF!

evel=info msg="Rewrote endpoint BPF program" containerID=8b7be1b032 datapathPolicyRevision=0 desiredPolicyRevision=1 endpointID=1018 identity=4773 ipv4=10.0.3.85 ipv6= k8sPodName=default/vhelloworld-daemonset-w97pv subsys=endpoint
level=info msg="Restored endpoint" endpointID=1018 ipAddr="[10.0.3.85 ]" subsys=endpoint

Does it work, but is it better in terms of resource consumption?

That was the good news. I was expecting gains because the cluster was really close to the dreaded death by iptables.

The cilium containers were using 10% of my nodes’ CPU, and several GB of RAM in iptables mode. It could quickly have gone much higher if I had grown the cluster beyond 50 nodes / 2000 pods.

Switching to eBPF mode allowed us to return to totally painless levels (1% CPU per node, 1-2% RAM) compared to my machines’ configurations.

Not bad, huh?

Bonus

A really hairy tutorial to fully migrate CNI hot (from flannel to cilium)

Run AIDungeon 2 on Ubuntu 18.04

Wed, 08 Jan 2020 11:30:00 +0000

AIDungeon 2

A few weeks ago, I stumbled upon AIDungeon 2, a hilarious project mixing Text based adventure, (heavy) machine learning and big (big BIG) CUDA GPUs.

AIDungeon2 is a first of its kind AI generated text adventure. Using a 1.5B parameter machine learning model called GPT-2 AIDungeon2 generates the story and results of your actions as you play in this virtual world. Unlike virtually every other game in existence, you are not limited by the imagination of the developer in what you can do. Any thing you can express in language can be your action and the AI dungeon master will decide how the world responds to your actions. https://www.aidungeon.io/

So, if you haven’t heard of it yet, it’s a machine learning project created by Nick Walton, a college student. It’s based on the GPT-2 text model from OpenAI that you may already seen in other fun projects and was trained to predict the next word using 40 GB of Internet text (you can also check TalkTotransformer by Adam D King).

So… What does it do ?

That’s where the fun begins. Like the TalkTotransformer generator, from a simple semi random generated background, the machine learning model builds the start of a new story, different every time. And your actions stear the story in one way or the other.

I won’t lie, it’s far from perfect. The model tends to run in circles, or forgets what the other characters did just a line before, which can be really annoying.

But… aside from this, the possibilities seem to be limitless, and that’s REALLY impressive.

After all, that’s not really surprising. You’re only limited by the knowledge and writing style of 40 GB of Internet text! If you need examples, I invite you to take a look at Nick Walton’s twitter feed or AIDungeon subreddit to find out the most hilarious adventures the AIDungeon community came upon.

In this example, my inputs are the 2 lines preceded by the « > » symbol, the machine did the rest

What’s the catch ?

I’ve already said it.

That game is probably the most GPU intensive game you’ve run in your life. For a text based adventure, even that is already ironically fun.

The game requires nearly 9 GB of GPU VRAM and a lot of CUDA cores, ruling out all AMD cards and nearly every NVidia cards costing less than 1500$.

Bummer…

Community to the rescue

Hopefully, the community enthusiasm was so intense that Nick Walton and his brother have decided to drop everything else to improve it. During december, they built mobile Apps and now a web based one to play on every device.

Of course, these apps run on AWS servers featuring Tegra GPUs and cost around 65k$ a month in hosting. They have managed to raise nearly 15k$/month on their Patreon Account but there may come a day (probably very soon) where they won’t be able to provide free access for everyone.

So, after you read the article, if you like the game, don’t forget to support them!

So what now?

It also turns out that, Nick Walton published the game as an open source project. That’s where I became the most interested in this game, in fact. And you can find the sources on the Github AIDungeons project.

Starting from there, I asked myself:

Hey! Wouldn’t it be nice to run it on a cloud instance on a random cloud provider GPU powered VM?

So I decided to try it.

For my test, I chose to run AIDungeon on a NC6 virtual machine (6 vcpus, 56 GiB memory, Tegra K80) on Microsoft Azure on a free test account. This machine costs approximatly 0.43€ per hour (or even 0,21€ if you use preemtible VMs) so even if you don’t use a free credit, it won’t cost you too much.

Side note: Of course, if you have a GTX 1080 Ti, GTX 2080 Ti or GTX 2080ti super (or a K80), you can also run it on your own machine…

On my NC6, I deployed a Ubuntu 18.04.

And that’s where this tutorial begins ;-)

Side note: If you follow this guide and start on a fresh Ubuntu 18.04, the installation process should take 30 minutes to 45 minutes.

Install updates and prerequisites

Once connected on the machine, update and upgrade the OS.

sudo apt-get update
sudo apt-get upgrade

Then, install prerequisites packages for AI

sudo apt-get install git aria2 unzip python3-pip

Dependancy hellscape

Now, the real fun begins. AIDungeon uses TensorFlow and CUDA drivers to run. But here’s the catch: not every versions will work!

To run AIDungeons, you have to install specifically tensorflow 1.15 (no more, no less). And tensorflow==1.15 specifically requires cuda10.0 (not cuda10.1 nor cuda10.2) and Python 3.4 to 3.7!

The dependancy nightmare begins…

Install NVidia drivers and Cuda and machine learning modules

Add the cuda10.0 repos:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/cuda-repo-ubuntu1804_10.0.130-1_amd64.deb
sudo dpkg -i cuda-repo-ubuntu1804_10.0.130-1_amd64.deb
sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/7fa2af80.pub
sudo apt-get update
wget http://developer.download.nvidia.com/compute/machine-learning/repos/ubuntu1804/x86_64/nvidia-machine-learning-repo-ubuntu1804_1.0.0-1_amd64.deb
sudo apt install ./nvidia-machine-learning-repo-ubuntu1804_1.0.0-1_amd64.deb
sudo apt-get update

Now, we can install nvidia-driver, and reboot:

sudo apt-get install --no-install-recommends nvidia-driver-440 xserver-xorg-video-nvidia-440
sudo reboot

After reboot, install cuda10.0 libs

sudo apt-get install --no-install-recommends \
cuda-10-0 cuda-runtime-10-0 cuda-demo-suite-10-0 cuda-drivers \
libcudnn7=7.6.2.24-1+cuda10.0 libcudnn7-dev=7.6.2.24-1+cuda10.0
sudo apt-get install -y --no-install-recommends libnvinfer5=5.1.5-1+cuda10.0 \
libnvinfer-dev=5.1.5-1+cuda10.0

Get the sources

Download the source from Github and hop-in in the directory:

git clone https://github.com/AIDungeon/AIDungeon/
cd AIDungeon/

Install python dependancies through pip

Sadly, installation time not yet over. Now that we have the python project on deck, we need to install the Python dependancies… By default, Ubuntu 18.04 still serves Python 2 as default Python interpreter, which is now deprecated since 1st january. Hopefully Python 3 is easily available (not like on CentOS 7).

Also, the pip (python package manager) installed should be updated as pip installed by Ubuntu is not compatible with tensorflow 1.15.

Upgrading pip in place can be tedious as this often lead to “pip ImportError: cannot import name ‘main’ after update” error message. To work around this, use the script given in upgrading pip official page and you should be fine.

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
sudo python3 get-pip.py

Install AIDungeon for good

Since I wrote the draft of the article a few weeks ago, there was a dependancy missing (gsutil) and the install script was not perfect. But now it seems to be working better and even uses venvs for a clean Python dependancies install.

sudo ./install.sh

If it doesn’t work, you can install it yourself with the following commands:

python3 -m pip install -r requirements.txt --user

The next script allows you to download the AIDungeon machine learning model through a torrent file (at first, Nick had a terrifying GDrive bill due to enormous egress traffic).

./download_model.sh
[...]
Status Legend:
(OK):download completed.
Download Complete!

Run AIDungeon 2

Finally, you can now sit back and enjoy the game!

If you used the install.sh script, use the following command (with venv):

source ./venv/bin/activate
./play.py

If not, skip the venv step:

cd ~/AIDungeon/
python3 play.py

The initialisation should take a few minutes (don’t panic, it’s “normal”), depending of your setup. In december, initialization took 5-10 minutes but there seem to have been optimisation now as it took only a minute or two last time I checked.

Bonus: Useful command to check GPU consumption

Install gpustat to check if GPU usage is working

pip3 install gpustat --user
gpustat
gpustat -cp
aidungeon2 Mon Dec 9 13:22:24 2019 430.50
[0] Tesla K80 | 69'C, 17 % | 0 / 11441 MB |

Or use integrated nvidia tool (a little crude)

nvidia-smi --loop=1

Bonus: Check that GPU is working with tensorflow

See Tensorflow GPU guide

python3
from __future__ import absolute_import, division, print_function, unicode_literals
import tensorflow as tf
print("Num GPUs Available: ", len(tf.config.experimental.list_physical_devices('GPU')))

Example working GPU setup

2019-12-10 16:25:39.714605: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcuda.so.1
2019-12-10 16:25:39.743758: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1618] Found device 0 with properties:
name: Tesla K80 major: 3 minor: 7 memoryClockRate(GHz): 0.8235
pciBusID: 81c7:00:00.0
2019-12-10 16:25:39.744001: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcudart.so.10.0
[...]
2019-12-10 16:25:39.754396: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1746] Adding visible gpu devices: 0
Num GPUs Available: 1

Example of non working GPU setup

[...]
Num GPUs Available: 0

If you have this, game will be very slow (waiting 1-2 minutes between each answer) but will not crash. Check that Cuda and tensorFlow are proprely installed.

Bonus: gsutil and tensorflow errors

If you forgot or failed to upgrade pip, you will get this error :

Collecting tensorflow==1.15 (from -r requirements.txt (line 6))
Could not find a version that satisfies the requirement tensorflow==1.15 (from -r requirements.txt (line 6)) (from versions: 0.12.1, 1.0.0, 1.0.1, 1.1.0rc0, 1.1.0rc1, 1.1.0rc2, 1.1.0, 1.2.0rc0, 1.2.0rc1, 1.2.0rc2, 1.2.0, 1.2.1, 1.3.0rc0, 1.3.0rc1, 1.3.0rc2, 1.3.0, 1.4.0rc0, 1.4.0rc1, 1.4.0, 1.4.1, 1.5.0rc0, 1.5.0rc1, 1.5.0, 1.5.1, 1.6.0rc0, 1.6.0rc1, 1.6.0, 1.7.0rc0, 1.7.0rc1, 1.7.0, 1.7.1, 1.8.0rc0, 1.8.0rc1, 1.8.0, 1.9.0rc0, 1.9.0rc1, 1.9.0rc2, 1.9.0, 1.10.0rc0, 1.10.0rc1, 1.10.0, 1.10.1, 1.11.0rc0, 1.11.0rc1, 1.11.0rc2, 1.11.0, 1.12.0rc0, 1.12.0rc1, 1.12.0rc2, 1.12.0, 1.12.2, 1.12.3, 1.13.0rc0, 1.13.0rc1, 1.13.0rc2, 1.13.1, 1.13.2, 1.14.0rc0, 1.14.0rc1, 1.14.0, 2.0.0a0, 2.0.0b0, 2.0.0b1)
No matching distribution found for tensorflow==1.15 (from -r requirements.txt (line 6))

You should not come across this anymore now, but if you get this error you should install gsutil python module to avoid stacktrace when saving / exiting

> ^C
Traceback (most recent call last):
File "play.py", line 211, in <module>
play_aidungeon_2()
File "play.py", line 97, in play_aidungeon_2
action = input("> ")
KeyboardInterrupt
Exception ignored in: <bound method Story.__del__ of <story.story_manager.Story object at 0x7f797f4af0f0>>
Traceback (most recent call last):
File "/home/zwindler/AIDungeon/story/story_manager.py", line 35, in __del__
self.save_to_storage()
File "/home/zwindler/AIDungeon/story/story_manager.py", line 131, in save_to_storage
p = Popen(['gsutil', 'cp', file_name, 'gs://aidungeonstories'], stdout=FNULL, stderr=subprocess.STDOUT)
File "/usr/lib/python3.6/subprocess.py", line 729, in __init__
restore_signals, start_new_session)
File "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'gsutil': 'gsutil'

DIY on Zwindler's Reflection

OCI Artifacts as LXC Machine Base on Proxmox 9.1, Finally?

Context

Let’s Test? First the Prerequisites

Creating the LXC Container

When It Wasn’t Working (Yet)

First Bug: “from scratch” Image

Second Bug: Unable to Start

Conclusion

Flash Your Xiaomi Mijia Thermometers to Extend Battery Life by a Year

€2 Thermometers That Become a Financial Drain

PVVX to the Rescue

Required Hardware

Flashing Procedure: Simpler Than It Seems

Firmware Configuration

Integration with Home Assistant

MicroStack evolves: HP EliteDesk and Lenovo ThinkCentre compatibility for your homelab

A MicroStack update? 😍

Promise kept: HP EliteDesk and Lenovo ThinkCentre!

A growing ecosystem

PC Modules:

Common Modules:

Still the same best practices

The feedback: multi-range modeling

Community feedback

And now?

AppImages on Ubuntu, Example with Bambu Studio

Bambu Studio and 3D Printing on Linux

Yes, but…

AppImage

Download and Launch

Victory?

Addendum

MicroStack - an open source project to 3D print a modular rack for my Dell Micro homelab

AGAIN? Another evolution of your lab???

A design designed for organization

How long does it take to do this kind of project?

Files and evolutions

Sidero Omni - Talos Linux on Oracle Cloud (free tier)

Context

What Does This Have to Do with Oracle Cloud?

Prerequisites

Retrieving the Compartment ID

Preparing the Oracle Cloud Environment

But It’s Not Over Yet :-/

Importing the Image to Oracle Cloud

Creating the VM

Addendum: Is It Really Free?

Migrating Cilium routing from iptables to eBPF... hot!

Context

Why?

How did we get here?

Problem

Checking connectivity

Changing a node’s configuration

Does it work, but is it better in terms of resource consumption?

Bonus

Run AIDungeon 2 on Ubuntu 18.04

AIDungeon 2

So… What does it do ?

What’s the catch ?

Community to the rescue

So what now?

Install updates and prerequisites

Dependancy hellscape

Install NVidia drivers and Cuda and machine learning modules

Get the sources

Install python dependancies through pip

Install AIDungeon for good

Run AIDungeon 2

Bonus: Useful command to check GPU consumption

Bonus: Check that GPU is working with tensorflow

Bonus: gsutil and tensorflow errors

Sources