Tutorials |

Emulating an Old-World LoongArch64 VM with QEMU

Mon, 08 Jun 2026 00:00:00 +0000

LoongArch64 has an awkward bit of history: the ecosystem is often described as split between . For the kind of server images I care about here, especially KylinOS Server and UnionTech OS Server, the practical target is still old-world compatibility.

That is why the firmware file matters. A newer LoongArch64 UEFI build is not automatically better for these guests. For this workflow, QEMU_EFI_7.2.fd is the boringly useful choice: old enough to match the systems being installed, but still aligned with QEMU’s LoongArch64 support era.

I have shared my copy here:

The file I am using is 3,801,088 bytes. Its SHA256 checksum is:

59ab6e18af0ca75ff1556ebb4b6ad640ffbf09499710e655172254f93a2d63ba

You can verify it after downloading:

shasum -a 256 QEMU_EFI_7.2.fd

Note

This post is about full-system emulation, not native virtualisation. On an x86_64 or Apple Silicon host, LoongArch64 can be quite slow. If a guest has not reached the installer or booted system after a long time, the problem may be firmware, guest compatibility, or host QEMU support rather than just patience.

Table of Contents

Install QEMU

On macOS, Homebrew is the easiest way to install QEMU:

brew install qemu
qemu-system-loongarch64 --version
qemu-system-loongarch64 -machine help
qemu-system-loongarch64 -cpu help

On Linux, install the package that provides qemu-system-loongarch64. For example, on a Fedora-like host:

dnf install -y qemu-system-loongarch64 qemu-img

QEMU 7.2 or newer is strongly preferred. QEMU 7.1 introduced initial LoongArch support, and QEMU 7.2 included important updates. In practice, I would not spend time debugging old QEMU builds for this.

UTM is worth knowing about on macOS because it is a pleasant QEMU-based VM manager. It can emulate a LoongArch64 VM, so the point is not that UTM is unavailable. For this old-world cloud-image workflow, though, I still prefer the direct qemu-system-loongarch64 command because the firmware, device, monitor, and forwarding options are easier to reproduce exactly.

Prepare the files

Create a working directory:

mkdir -p ~/VMs/loongarch64
cd ~/VMs/loongarch64

Put these files in that directory:

QEMU_EFI_7.2.fd, downloaded from one of the cloud-drive links above.
A LoongArch64 server ISO, such as KylinOS Server or UnionTech OS Server.
A qcow2 disk created for the VM.

Create the disk with qemu-img:

qemu-img create -f qcow2 KylinOS-Server-loongarch64.qcow2 40G

Adjust the filename and size for your own guest. These systems are Red Hat-like, so a 40 GB disk is a reasonable starting point for a small build or image-preparation VM.

Boot from an ISO

Use this shape when installing a fresh LoongArch64 server guest from an ISO:

qemu-system-loongarch64 \
 -M virt \
 -bios QEMU_EFI_7.2.fd \
 -cdrom KylinOS-Server-loongarch64.iso \
 -chardev socket,id=qemu-ga.0,path=qemu-ga.sock,server=on,wait=off \
 -cpu la464-loongarch-cpu \
 -device nec-usb-xhci,id=xhci,addr=0x1b \
 -device usb-kbd,id=keyboard,bus=xhci.0,port=2 \
 -device usb-tablet,id=tablet,bus=xhci.0,port=1 \
 -device virtio-gpu-pci \
 -device virtio-serial \
 -device virtserialport,chardev=qemu-ga.0,name=org.qemu.guest_agent.0 \
 -hda KylinOS-Server-loongarch64.qcow2 \
 -m 2G \
 -monitor telnet:localhost:5555,server=on,wait=off \
 -net nic,model=virtio \
 -net user,hostfwd=tcp::10000-:22 \
 -smp 2 \
 -vnc 0.0.0.0:1

For UnionTech OS Server, keep the same command structure and replace the ISO and qcow2 filenames. The main point is not the exact distribution name; it is the combination of qemu-system-loongarch64, -M virt, QEMU_EFI_7.2.fd, la464-loongarch-cpu, VirtIO devices, VNC, QEMU Guest Agent wiring, and SSH port forwarding.

Connect with a VNC viewer to the host’s display :1, which normally means TCP port 5901. If you add --serial stdio, QEMU will also print serial output in the terminal, which can be useful when the graphical display is quiet.

During installation, treat the guest as a Red Hat-like system:

Use VirtIO-backed disk and network devices.
Install or keep qemu-guest-agent if the image-preparation workflow needs guest-agent operations later.
Ensure SSH is installed and enabled if you want to log in through the forwarded host port.
Keep the firmware file and qcow2 disk together so the boot command stays reproducible.

Boot an installed qcow2

After installation, stop the emulation session and boot from the qcow2 disk without -cdrom:

qemu-system-loongarch64 \
 -M virt \
 -bios QEMU_EFI_7.2.fd \
 -chardev socket,id=qemu-ga.0,path=qemu-ga.sock,server=on,wait=off \
 -cpu la464-loongarch-cpu \
 -device nec-usb-xhci,id=xhci,addr=0x1b \
 -device usb-kbd,id=keyboard,bus=xhci.0,port=2 \
 -device usb-tablet,id=tablet,bus=xhci.0,port=1 \
 -device virtio-gpu-pci \
 -device virtio-serial \
 -device virtserialport,chardev=qemu-ga.0,name=org.qemu.guest_agent.0 \
 -hda KylinOS-Server-loongarch64.qcow2 \
 -m 2G \
 -monitor telnet:localhost:5555,server=on,wait=off \
 -net nic,model=virtio \
 -net user,hostfwd=tcp::10000-:22 \
 -smp 2 \
 -vnc 0.0.0.0:1

Then SSH through the forwarded port:

ssh root@localhost -p 10000

If the guest has no network, first use VNC or serial output to inspect it:

ip addr
systemctl status sshd
systemctl status qemu-guest-agent

On KylinOS Server or UnionTech OS Server, the package-management commands should feel familiar if you have used RHEL-like systems:

dnf install -y openssh-server qemu-guest-agent
systemctl enable --now sshd qemu-guest-agent

Use QEMU Monitor

The -monitor telnet:localhost:5555,server=on,wait=off option opens a QEMU Monitor endpoint. Connect to it from the host:

telnet localhost 5555

Common monitor commands:

info status
info block
system_powerdown
system_reset
quit

system_powerdown is the polite option if the guest supports ACPI shutdown. quit stops QEMU directly and can lose guest data, so I only use it when the VM is disposable or already stuck.

For more monitor commands, see the .

Confirm the architecture

Inside the guest:

uname -m
uname -a

The first command should print:

loongarch64

At that point the VM is ready for the usual Red Hat-like server chores: package updates, qemu-guest-agent checks, image clean-up, kernel clean-up, and whatever build or compatibility work needed a LoongArch64 environment in the first place.

Optional: use UTM on macOS

If you prefer a GUI, UTM can be configured for this kind of VM as well. I would treat it as a convenience path rather than the main recipe, because the command line is easier to copy, audit, and rerun during image work.

The important system settings are:

Architecture: LoongArch64.
System: QEMU LoongArch Virtual Machine (default) (virt).
CPU: Default, or the closest available LoongArch CPU setting exposed by your UTM build.
Memory and CPU cores: choose values that match your host. LoongArch64 emulation is slow, and checking Force Multicore may help sometimes.

Add QEMU_EFI_7.2.fd as a drive with image type BIOS, and keep it read-only.

For display, virtio-ramfb is a useful starting point.

You still need the same guest-side checks after installation: SSH, qemu-guest-agent if required, VirtIO networking, and uname -m showing loongarch64.

Cleaning Up Unused Linux Kernels

Sun, 07 Jun 2026 00:00:00 +0000

After installing another Linux kernel version, the old one usually stays installed. This is not a bug. It is a useful rollback path when the new kernel fails to boot, lacks a driver, or behaves strangely.

Once the system has been rebooted and confirmed healthy, though, keeping too many old kernels becomes a quiet kind of clutter. /boot gets noisy, GRUB entries pile up, and small boot partitions can eventually complain.

This is the checklist I would want before touching a real machine: confirm what is running, remove only the obsolete package set, refresh the boot menu, and leave a fallback kernel unless the host is truly disposable.

Caution

Run these commands as root, and do not remove the kernel currently running the system. If the target kernel is shown by uname -r, reboot into another kernel first.

Table of Contents

Confirm the running kernel

Start with the one kernel version that must not be removed.

uname -r

If this prints the version you planned to delete, stop here. Reboot, select a newer or otherwise known-good kernel from GRUB, then check again.

List installed kernel packages

On Red Hat-like systems such as RHEL, CentOS Stream, Rocky Linux, AlmaLinux, or Fedora, query RPM packages:

rpm -aq | grep kernel

On Debian-like systems such as Debian or Ubuntu, query installed linux-* packages:

dpkg -l | grep -Ei 'linux-image|linux-headers|linux-modules' | grep -Ei '^ii' | awk '{ print $2 }'

What you are looking for is the version suffix shared by the packages that belong to the old kernel. For example:

6.8.5-301.fc40.x86_64 on a Fedora-style system.
5.4.0-165-generic on an Ubuntu-style system.

I usually copy the suffix into a variable and print the matched packages before removing anything. It adds one boring step, and boring is excellent here.

Remove an old kernel on Red Hat-like systems

Use the package manager for the package removal itself, then clean the leftover modules directory if it remains.

deprecated_kernel='6.8.5-301.fc40.x86_64'

if [ "$(uname -r)" = "${deprecated_kernel}" ]; then
 echo "Refusing to remove the running kernel: ${deprecated_kernel}" >&2
 exit 1
fi

rpm -aq | grep kernel | grep -F "${deprecated_kernel}"
rpm -aq | grep kernel | grep -F "${deprecated_kernel}" | xargs -r dnf remove -y
rm -rf "/lib/modules/${deprecated_kernel}/"
dnf autoremove

If your system only has yum, use it for the final clean-up step:

yum autoremove

Then refresh GRUB configuration files under /boot:

ls -l /boot/ | grep rescue

find /boot/ -name 'grub.cfg' | while IFS= read -r file; do
 echo
 echo "Updating ${file}:"
 grub2-mkconfig -o "${file}"
done

Some systems also keep Boot Loader Specification entries under /boot/loader/entries/. If the removed kernel still has a stale .conf file there, remove that specific file.

ls -l /boot/loader/entries/

Be picky here. Delete only entries that clearly match the kernel version already removed.

Remove an old kernel on Debian-like systems

Again, set the version suffix first. apt purge removes the matching kernel packages and their package configuration; the separate apt autoremove then lets APT clean up dependencies that are no longer needed.

deprecated_kernel='5.4.0-165-generic'

if [ "$(uname -r)" = "${deprecated_kernel}" ]; then
 echo "Refusing to remove the running kernel: ${deprecated_kernel}" >&2
 exit 1
fi

dpkg -l | grep -Ei 'linux-image|linux-headers|linux-modules' | grep -Ei '^ii' | awk '{ print $2 }' | grep -E "${deprecated_kernel}$"
dpkg -l | grep -Ei 'linux-image|linux-headers|linux-modules' | grep -Ei '^ii' | awk '{ print $2 }' | grep -E "${deprecated_kernel}$" | xargs -r apt purge -y
rm -rf "/lib/modules/${deprecated_kernel}/"
apt autoremove
update-grub

On older Ubuntu releases, this pattern is especially handy after a manual kernel update: headers, image packages, modules, and modules-extra packages may all share the same version suffix.

Do a final sanity check

After clean-up, inspect what remains:

uname -r

# Red Hat-like
rpm -aq | grep kernel

# Debian-like
dpkg -l | grep -Ei 'linux-image|linux-headers|linux-modules' | grep -Ei '^ii' | awk '{ print $2 }'

The result I want is simple:

The running kernel is still installed.
At least one known-good fallback kernel remains, unless this is a tightly controlled image-building environment.
GRUB no longer shows entries for kernel packages that were already removed.
/lib/modules/ does not contain a directory for the removed kernel.

Limit future build-up

On Fedora/RHEL-like systems, DNF normally keeps only a small number of install-only packages, including kernels. If the host keeps too many kernels, check the configured limit:

grep -E '^installonly_limit=' /etc/dnf/dnf.conf

For most ordinary hosts, installonly_limit=3 is a reasonable balance: current kernel, one fallback, and one extra slot during updates. I would avoid setting it below 2.

On Debian/Ubuntu, old automatically installed kernels are often handled by:

apt autoremove

If a kernel package was manually marked as installed, APT may keep it. In that case, inspect the package names first and only then adjust the manual/auto mark or purge the exact old packages.

Keep the habit conservative

Kernel clean-up is not about being tidy for its own sake. It is about keeping the boot path understandable while preserving a rollback option.

For normal servers, I prefer keeping the current kernel and one previous known-good kernel. For disposable build hosts or image-making VMs, I may be more aggressive, but only after the new kernel has booted and the important workload has actually run.

Disabling FaceFusion's NSFW Filter from Source Code

Sun, 07 Jun 2026 00:00:00 +0000

FaceFusion 3.7.0 has a built-in content analyser. In the source I checked, image and video workflows call it before doing the main processing work. If the analyser says the target is NSFW, the workflow returns early.

This blog records a tiny local patch to disable that gate from source code.

Caution

I only do this for research on local model behaviour and source-code analysis, not for anything illegal, non-consensual, or prohibited for anyone under 18. In short: lab coat on, age gate on, common sense on. The lab coat may be imaginary; the age gate is not. 🧪

Note

The examples below are based on FaceFusion 3.7.0, from a master checkout at b8f8046 last minute change to frame distribution. I have decided not to chase every upstream change here, but the same idea should theoretically apply to FaceFusion 3.5.x through 3.8.x; at the time of writing, the latest release I checked is 3.8.2. If you prefer a more detailed guide, see .

Table of Contents

Find where FaceFusion checks content

In the image workflow, setup calls analyse_image() before creating temporary files:

def setup() -> ErrorCode:
 if analyse_image(state_manager.get_item('target_path')):
 return 3

The video workflow does the same with analyse_video():

def setup() -> ErrorCode:
 trim_frame_start, trim_frame_end = restrict_trim_frame(state_manager.get_item('target_path'), state_manager.get_item('trim_frame_start'), state_manager.get_item('trim_frame_end'))

 if analyse_video(state_manager.get_item('target_path'), trim_frame_start, trim_frame_end):
 return 3

Both paths eventually land in facefusion/content_analyser.py. For a single frame, the call chain is short:

def analyse_frame(vision_frame : VisionFrame) -> bool:
 return detect_nsfw(vision_frame)

So the practical switch is detect_nsfw().

Make `detect_nsfw()` always return `False`

Originally, detect_nsfw() combined three detector results and returned true when at least two detectors agreed:

def detect_nsfw(vision_frame : VisionFrame) -> bool:
 is_nsfw_1 = detect_with_nsfw_1(vision_frame)
 is_nsfw_2 = detect_with_nsfw_2(vision_frame)
 is_nsfw_3 = detect_with_nsfw_3(vision_frame)

 return is_nsfw_1 and is_nsfw_2 or is_nsfw_1 and is_nsfw_3 or is_nsfw_2 and is_nsfw_3

For my local research checkout, I changed it to:

def detect_nsfw(vision_frame : VisionFrame) -> bool:
 return False

That is intentionally blunt. analyse_image() and analyse_video() still run, but the underlying frame result is always “not NSFW”, so the early return 3 branch is not triggered by this analyser.

Remove the content analyser hash guard

There is one more check in facefusion/core.py. During common_pre_check(), FaceFusion hashes the source of the content_analyser module:

content_analyser_content = inspect.getsource(content_analyser).encode()

return hash_helper.create_hash(content_analyser_content) == '975d67d6'

After editing content_analyser.py, that hash no longer matches. So the second local change is to stop enforcing the original hash:

return True

The result is deliberately small: common_pre_check() becomes a plain pass-through for this local checkout. If I were maintaining a long-lived fork, I would replace this with a proper configuration flag.

Review the final diff

The whole patch is small:

diff --git a/facefusion/content_analyser.py b/facefusion/content_analyser.py
@@
 def detect_nsfw(vision_frame : VisionFrame) -> bool:
- is_nsfw_1 = detect_with_nsfw_1(vision_frame)
- is_nsfw_2 = detect_with_nsfw_2(vision_frame)
- is_nsfw_3 = detect_with_nsfw_3(vision_frame)
-
- return is_nsfw_1 and is_nsfw_2 or is_nsfw_1 and is_nsfw_3 or is_nsfw_2 and is_nsfw_3
+ return False

diff --git a/facefusion/core.py b/facefusion/core.py
@@
- content_analyser_content = inspect.getsource(content_analyser).encode()
-
- return hash_helper.create_hash(content_analyser_content) == '975d67d6'
+ return True

Verify the patch locally

First, confirm only the intended files changed:

git -C /path/to/facefusion diff --stat
git -C /path/to/facefusion diff -- facefusion/content_analyser.py facefusion/core.py

Then run FaceFusion from that modified checkout and retry the input that previously stopped at the content analyser gate.

For a quick source-level sanity check, I also like searching the call sites:

rg -n "analyse_image|analyse_video|detect_nsfw|common_pre_check" facefusion

If rg is not available, use plain grep instead:

grep -RInE "analyse_image|analyse_video|detect_nsfw|common_pre_check" facefusion

In my checkout, the important shape is:

image_to_image.py calls analyse_image() during setup.
image_to_video.py calls analyse_video() during setup.
analyse_frame() delegates to detect_nsfw().
common_pre_check() returns True instead of rejecting the edited analyser source by hash.

Keep the patch local

This is the kind of modification I would keep as a local research patch, not something to casually publish as a default behaviour change. Filters can be annoying when they block legitimate experiments, but they also exist because image-generation and face-processing tools can be abused very easily.

So yes, this is how I disabled the gate in source code. No, this is not a permission slip for creepy things. If the target is non-consensual, illegal, or involves anyone under 18, the correct patch is not in Python. It is in the user’s judgement. Please upgrade that dependency first. 🧠

Building PyPy 3 from Source on a LoongArch64 Platform

Sun, 23 Feb 2025 00:00:00 +0000

provides general guidance on building from source. Since PyPy does not officially support Linux LoongArch64, I would like to share my own process for building a binary for this relatively new architecture.

Note

The following is demonstrated as the root user in a LoongArch64 VM running Kylin Server V10 SP3. Adjustments may be required to match your environment.
PyPy 3.11 v7.3.18 is used. Other PyPy 3 versions should follow a similar process.

In particular, I should stress that this OS version leverages old-world¹ technologies.

Table of Contents

Prerequisites: Python 2.7 and at least 6 GB memory for translation

As the official documentation states, the translation process is indeed RAM-hungry. So please take it seriously.

The documentation also mentions that CPython/PyPy 2.7 is required. Building PyPy 2.7 for LoongArch64 is probably not worth the effort here, so I’ll just install Python 2.7 in my VM.

dnf install -y python2
# command -v python2

Get the source

wget https://downloads.python.org/pypy/pypy3.11-v7.3.18-src.tar.bz2
tar -xvf pypy3.11-v7.3.18-src.tar.bz2
# rm -f pypy3.11-v7.3.18-src.tar.bz2

# Apply patches here.

Important

Patches must be applied to support LoongArch64. See for an example.

Install build-time dependencies

dnf install -y bzip2-devel expat-devel gc-devel gcc gdbm-devel libffi-devel make ncurses-devel openssl-devel pkgconfig python2-pip sqlite-devel tk-devel xz-devel zlib-devel

CFFI is required. I suggest using a Python 2.7 virtual environment.

# python2 -m pip -V
python2 -m pip install virtualenv
python2 -m virtualenv venv_2
source venv_2/bin/activate
# command -v python
# python -m pip -V
python -m pip install cffi

Translate without JIT

cd pypy3.11-v7.3.18-src/pypy/goal
python ../../rpython/bin/rpython --opt=2
deactivate

It can be time-consuming. Please be patient. A successful build should end with output like this.

After a successful build, you can also play with the compiled binary.

./pypy3.11-c -V
./pypy3.11-c -c 'print("Hello World!")'
./pypy3.11-c -m pip -V

Packaging

I will use the compiled binary directly for packaging.

# ./pypy3.11-c ../../pypy/tool/release/package.py --help
./pypy3.11-c ../../pypy/tool/release/package.py --archive-name=pypy3.11-v7.3.18-loongarch64

This creates a clean and prepared hierarchy, as well as a .tar.bz2 with the same content; the directory to find these will be printed out.

See for a brief intro on the so-called old/new world. ↩︎

A Starter for Python 2 Code Formatting with Black

Sun, 09 Feb 2025 00:00:00 +0000

Caution

Python 2.7 is the last major version in the 2.x series and . Please upgrade your Python if possible.

Some of the projects I work on still use Python 2.7. Installing Black for that case can take a little fiddling, so I’d like to show the steps that worked for me.

Note

, even for formatting Python 2 code.
The following assumes you have admin/root privileges and use pip as your package installer. Adjustments may be required to match your environment.

Table of Contents

Prerequisites: Python 3.6+ with a package installer

I am not going to cover how to install Python 3 or set up a package installer such as pip. You may need to search the web if your environment does not meet the prerequisites.

command -v python3
python3 -m pip -V

Install a specific Black version

python3 -m pip install 'black[python2]==21.12b0' click==8.0.4

V21.12b0 is the last Black version with support for formatting Python 2 code. As defined in , click >= 7.1.2 is a must.

click <= 8.0.4 is also required. Otherwise, you may encounter an error saying ImportError: cannot import name '_unicodefun' from 'click' when running Black.

The python2 extra for Black installs the optional dependency typed-ast, which . If there is no matching pre-built binary package for your environment, building it can fail with a Clang or GCC error. My suggestion is to remove [python2] as shown below. It generally works fine.

python3 -m pip install black==21.12b0 click==8.0.4

Verify installation

python3 -m black --version

Tutorials |

Emulating an Old-World LoongArch64 VM with QEMU

Install QEMU

Prepare the files

Boot from an ISO

Boot an installed qcow2

Use QEMU Monitor

Confirm the architecture

Optional: use UTM on macOS

Cleaning Up Unused Linux Kernels

Confirm the running kernel

List installed kernel packages

Remove an old kernel on Red Hat-like systems

Remove an old kernel on Debian-like systems

Do a final sanity check

Limit future build-up

Keep the habit conservative

Disabling FaceFusion's NSFW Filter from Source Code

Find where FaceFusion checks content

Make detect_nsfw() always return False

Remove the content analyser hash guard

Review the final diff

Verify the patch locally

Keep the patch local

Building PyPy 3 from Source on a LoongArch64 Platform

Prerequisites: Python 2.7 and at least 6 GB memory for translation

Get the source

Install build-time dependencies

Translate without JIT

Packaging

A Starter for Python 2 Code Formatting with Black

Prerequisites: Python 3.6+ with a package installer

Install a specific Black version

Verify installation

Make `detect_nsfw()` always return `False`