Linux – Page 2 – Arcane Science Lab

Executive Summary

I came across a post on Jeff Geerling’s blog about how to install Windows 11 as a VM on a Raspberry Pi. Being retired and with plenty of “leisure” time on my hands, I decided to follow along and see what it was like, so I set out to install the same tools using the same essential process he did. I got it to work (barely), but I wasn’t impressed with the results. It took me an entire day to get it all installed and running, only to eventually fail. In the end I deleted everything.

Installation and Setup

Before I get started, let me document my Raspberry Pi 5 setup, because it’s a little different than stock.

Raspberry Pi 5 Model B Rev 1.0 with up-to-date firmware
8 GiB memory
Raspberry Pi official active cooling fan
Raspberry Pi M.2 HAT+
Timetec 512GB M.2 2242 NVMe PCIe Gen3x4 SSD
Ubuntu 24.04.2 for Raspberry Pi booting off the SSD

The Geerling post links to the creator and developer of the system for installing the ARM version of Windows 11, Botspot Virtual Machine, or BVM, on GitHub. While the directions for installing this is on GitHub, Geerling’s post links to a YouTube video he produced of him installing the software and getting Windows 11 running. I think that video is a bit deceptive concerning how much time it takes to get everything installed. In my case, just getting the ISO downloaded took over seven hours. Here’s a screenshot showing my desktop with System Monitor and a terminal with BVM doing its thing.

The amount of time to download Windows 11 ARM64 can be seen in the middle of the terminal, in the text section beneath “Downloading Windows 11…” There are four consecutive lines of text, with the time it took each operation timed on the far right. Totaled up, it took over seven hours to download the ISO. The download speeds are in the low hundreds of kilobytes. I’ve never seen anything that slow before, even on an old Raspberry Pi 2 or 3. Downloading the virtio drivers took another two hours. And then there was the step installing Windows 11 itself.

Even BVM warned “This will take several hours,” and it wasn’t wrong. It took several hours.

Operation

After a period of nearly 12 hours, from early in the morning until late in the evening, I managed to bring up a small Windows 11 640 x 480 window on the desktop.

I briefly tried to expand that resolution to something more useful, but this version of Windows wouldn’t allow me to change the screen resolution. You’ll note from System Monitor that I nearly exhausted swap. I closed the Windows VM at this point and increased local swap from 1 GiB to 4 GiB. One other notable difference, on Ubuntu at least you need to run bvm boot-gtk instead of bvm boot.

I did follow the BVM README and restarted the Windows 11 VM as headless in one terminal, then ran bvm connect in a second terminal. This produced the screen you see above. Desktop performance was greatly improved and the screen is a little bigger, but I don’t know what the resolution is. Unfortunately I can neither resize nor move it. That window is right smack in the middle of the desktop. I should note once again on System Monitor that swap usage is now at 1.4 GiB. It might be best to run this on a Raspberry Pi with 16 GB. I should also note that even with active cooling running (and the fan did kick in) the CPU temperatures hovered between 60° and 65° C.

Summary

I’m glad I gave this a try. But after these experiences I’m not so certain I’ll keep it on my Raspberry Pi.

Update

I let Windows 11 finish downloading its updates (see the last screenshot above), then I rebooted the Windows 11 VM. After that, headless operation no longer worked. Even bvm boot-gtk no longer worked. So the whole conglomeration was deleted from my Raspberry Pi and all used disk space (in the tens of gigabytes) was recovered. My advice: If you need to get Real Work done, instead of just “bragging rights,” then go shopping on Amazon and pick up one of the current micro PCs with Windows 11 Pro installed for around $300 and use that for your Windows 11 needs.

Links

Windows 11 Arm VMs on a Raspberry Pi, with BVM — https://www.jeffgeerling.com/blog/2025/windows-11-arm-vms-on-raspberry-pi-bvm

Botspot Virtual Machine – Windows 11 QEMU KVM on ARM Linux — https://github.com/Botspot/bvm

migrating to an nvme drive on a raspberry pi 5 — part 2

So after the first rather unsatisfying attempt to restore a Raspberry Pi 3 Model B Revision 1.2, I tried again, and this time found more satisfying results. The first thing I did on this second attempt was to create a new boot micro SDXC card using the Raspberry Pi OS 32-bit “legacy” version. This version is based on Debian bullseye, a.k.a. Debian 11. Current releases are based on Debian bookworm, a.k.a. Debian 12. I use the Raspberry Pi Imager these days to create boot cards for all my Raspberry Pi devices because it’s process flow is so simple to use. Pick the Raspberry Pi you’re working with, then select an OS, then select the boot device to flash the boot image to and wait for it to finish. The problem occurs with the recommendation for certain Raspberry Pis. As you’ll note in the screen capture, the Imager is recommending the current 64-bit version of Raspberry Pi OS. For a ten-year-old device with 1 MiB of on-board DRAM, that is a poor recommendation. Instead boot such Raspberry Pis with the third entry, the “legacy” release.

Once all that was done and the RPi 3 was booted, I did a bit of housekeeping to tweak things to my personal tastes. I was quite happy with the much snappier performance of the RPi 3 under the 32-bit bullseye-based version. I tried to install fastfetch, but it wasn’t in the legacy repo, so I fired up chromium and downloaded a version compiled for the arm7l architecture which the RPi 3 was running as.

I always create a bin directory in my home folder to hold tools I will only run when I’m logged in. I add that local bin to my path as well. That’s where I unpacked fastfetch to. You’ll note that we are indeed running under Raspbian based on Debian bullseye. This is far more advanced than the version on the board when I put it away years ago; Raspbian based on Debian stretch. You’ll also note I bumped the swap space from the default 100 MiB to 2 GiB. Here’s an image of why that’s so important.

With the system booted and running, with three open terminals of which one was running htop, and Chromium up with only one tab pointed at the Raspberry Pi Sense HAT documentation, swap had already hit 139 MiB. Exhausting swap is a guarantee to crashed applications and a system that is so sluggish as to be for all practical purposes locked up. I’ve already documented how to fix this in the first attempt to resurrect this board, link at the bottom. I decided to only expand swap to 2 GiB instead of 4, just to see if I actually needed to. Turns out I didn’t need 4 GiB, and I probably could have even defined even less, such as 1 GiB.

Once the RPi 3 was up and stable I added a few things to the environment to make it more to my liking. I added the Nerd Hack fonts, and set the shell to use them, then I installed the Rust compiler and tool chain. From there I used cargo to install eza, a more sophisticated ls, and bat, a much better cat alternative. The shell above shows the results of using the Nerd Font and eza via an alias for ls. I show this because one of the first major tasks was to get the Sense HAT operational, and for that I installed the sense-hat package.

I point this out because if you follow the instructions for the Sense HAT documentation, the instructions have you install the sense-hat package, then Octave, then go through the steps of calibrating the sense hat. This left me with the erroneous assumption that the calibration software was a part of Octave, which it is not. You do not have to install Octave to work with the Sense HAT. The instructional also state that the result of the calibration, the file RTIMULib.ini, is in two locations, one of which is under ~/.config/sense_hat. There is no ~/.config/sense_hat folder created.

The RPi 3 is now operational enough I can begin to seriously think about using it for headless and unattended operation somewhere around the house. I’ve yet to determine a specific task, but it’s ready for the next step. I intend to install Cockpit on it, as I have with several other Raspberry Pis in my household. If you want to see Cockpit in action, just a teensy bit, here’s two screen captures of it in operation using Chromium on my Raspberry Pi 5 to look at the remote Raspberry Pi 4.

I have a Raspberry Pi 4, 2 GiB, running unattended and headless running Pi-hole. Rather than have to ssh into the system, I installed Cockpit with its much better web-based interface. Most of the time I live in the console.

Right now I have disabled Pi-hole because an update came down the pipes and caused all sorts of screwy issues. That was sometime last year, and I haven’t felt the need to go in and sort it out, including (possibly) a complete re-installation of Pi-hole itself. Of note is the low memory footprint of bookworm, which is what you can get when you’re not running the graphical desktop. That is basically what I’ll do with the RPi 3, which is disable the graphical desktop and install Cockpit on it to manage it remotely.

The final question that needs to be asked is why? Because I have all this incredibly capable computing resources that are literally sitting in a corner doing nothing. I turned 71 last December, and I need to add as much automation to my household as I possibly can to help me and my wife live independent quality lives. I want a household automation system that I control and doesn’t depend on the “cloud.” I don’t want to wake up one day and read that my home devices will no longer work because the company that sold me those devices is going out of business and bricking all my expensive devices. I just won’t put up with that.