May 2026

Systemd – Failed to reload daemon: Refusing to reload, not enough space available on /run/systemd

While configuring a Debian 11 virtual machine with 128M memory, I ran into an error when reloading systemd service configuration. The error message was as described in the title. After investigation, I found that Debian by default allocates /run space proportional to system memory. With only 128M memory, the default /run size was 16M. When executing systemctl daemon-reload, the error appeared, along with a message like:

Currently, XX.XM are free, but a safety buffer of 16.0M is enforced.

The solution is simply to increase the /run size. Modify /etc/fstab and add the following line:

none /run tmpfs defaults,size=64M 0 0

This specifies 64M space for /run. According to online sources, this should be sufficient for most cases. Then execute:

mount -o remount /run

to remount /run. After completion, use df -hT to confirm the current size of /run. Once increased, running daemon-reload works normally again.

A record of fixing an Altium Designer Health Check issue

As shown in the screenshot, while learning PCB design in AD recently, I discovered that besides DRC checks, AD also has a Health Check feature (the version used when writing this was 25.8.1). Several warnings appeared: Self-Intersecting Regions、Micro-Segments (Board)、Micro-Segments (Copper). This record mainly focuses on a strange issue encountered while fixing the first and third problems.

First, by clicking the issues listed:

You can locate the PCB area where the problem was detected. In my board, it pointed to this location:

Continue reading…

Altium Designer 24 PCB DRC Solder Mask Sliver constraint floating point precision issue

While learning AD24 recently, I discovered an issue:

As shown in the screenshot, AD’s DRC check reported a violation:
“[Minimum Solder Mask Sliver Constraint Violation] IP2369_EVM.PcbDoc Advanced PCB Minimum Solder Mask Sliver Constraint: (0.0998mm (3.929mil) < 0.1mm (3.937mil)) Between Pad U1-21 (52.014mm, 25.561mm) on Top Layer And Pad U1-22 (52.014mm, 25.961mm) on Top Layer [Top Solder] Mask Sliver [0.1mm]”

After investigating and manually calculating pad size, solder mask expansion, and pad spacing:

Continue reading…

W801 (W80X_SDK_v1.00.10) https request mbedtls error 0x7780 issue and solution record

The issue started when I wanted to use the W801 to detect a GPIO level change and then send a bot notification message through Telegram. However, when calling my own Telegram API reverse proxy (caddy v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=), the serial log showed the SSL handshake error 0x7780 mentioned in the title.

The code was directly copied from the SDK example demo wm_https_demo.c. The error occurred during the handshake, specifically when calling HTTPWrapperSSLConnect, as shown:

wm_printf("step 1: ssl connect to...\r\n");
ret = HTTPWrapperSSLConnect(&ssl_p, fd, (const struct sockaddr *)&server, sizeof(server), HTTPS_DEMO_SERVER);
if (ret < 0)
{
    wm_printf("https connect error\r\n");
    close(fd);
    break;
}

At first, the serial output only showed step 1: ssl connect to…, then immediately the 0x7780 error, followed by https connect error and request failure. After studying the mbedtls library used internally, I found that more detailed debug logs were available. You need to enable the macro define MBEDTLS_DEBUG_C in SDK src/app/mbedtls/include/mbedtls/config.h (and make sure the makefile project rebuilds the lib target. If using my previous CLion IDE setup, select the lib configuration and rebuild). After enabling it, you can see error messages similar to those mentioned here: https://forums.mbed.com/t/error-0x7780-during-handshake/6883

Continue reading…

One cause of GitLab built‑in CI runner submodule initialization error

First, the background: a GitLab project that references other projects within the same GitLab instance using submodules. The .gitmodules file looks something like this:

[submodule "lib1"]
	path = lib1
	url = http://gitlab.xxx.xxx/group1/lib1.git
[submodule "lib2"]
	path = lib2
	url = http://gitlab.xxx.xxx/group2/lib2.git
[submodule "lib3"]
	path = lib3
	url = http://gitlab.xxx.xxx/group3/lib3.git

This structure works fine during local development. Of course, the local GitLab account has access permissions to the dependent submodule repositories. When setting up the CI build environment, using GitLab’s docker runner on Linux works without issues. However, on macOS using the shell runner, I encountered errors when initializing submodules:

Continue reading…

Correct reset method for Xiaomi Mijia Temperature and Humidity Sensor 2 (reset, factory restore, contacts not pressable)

I have three Xiaomi Temperature and Humidity Sensor 2 devices at home, connected to the Xiaomi Smart Plug 2 Bluetooth gateway. They are small and convenient, allowing me to check home temperature and humidity anytime on my phone. Recently, after replacing the battery in one of them, a strange problem appeared: the device could be seen in the Mi Home app, and it showed as connected to the Bluetooth gateway, but no temperature or humidity data could be retrieved. Entering the device details page gave no response, only prompting “Turn on Bluetooth.” If I enabled phone Bluetooth, it would connect very slowly to the device and eventually retrieve data, but the process was sluggish, unlike before when the gateway connection was instant. This also meant that when away from home, I could no longer see real‑time data from this sensor (the gateway page in the app still showed the sensor connected with full signal). Later I checked the firmware and found it could be upgraded to the latest “0130.” I upgraded (the process was also very slow, probably due to Bluetooth transfer), but the problem remained! Searching online, I found people suggesting a reset, which brings us to today’s topic. The reset design of this Xiaomi sensor is rather unusual. Most online reset methods say this:

Continue reading…

A strange reason for QRhiGraphicsPipeline create failure

Recently while learning the Qt RHI graphics rendering framework I encountered a strange problem: QRhiGraphicsPipeline inexplicably returned false on create! During the time this problem appeared, I was debugging the fragment shader, specifically studying HDR display shaders, and frequently toggling Windows HDR on and off. At one point I thought it was a system issue, so I tried switching to SDR, but the error persisted.

Later, after spending some time reverting modifications, I finally isolated the cause…

First, note that the program framework was basically copied from the Qt official documentation example: https://doc.qt.io/qt-6/qtgui-rhiwindow-example.html. The error occurs at the following code location:

Continue reading…

Cherry MX2.0S RGB keyboard LED failure repair log again

Following the first repair of my Cherry MX2.0S RGB keyboard LED failure last October (Repair log of Cherry MX2.0S RGB keyboard lighting failure after more than 3 years), I recently found another group of keys (numeric keypad 9, 6, 3, DEL) showing the same fault:

This time my hand didn’t shake 😂, and I removed the keycaps and shot a video, the fault phenomenon is crystal clear!

Since I already had experience repairing this fault last time, this time I prepared to optimize the repair process and record the simplified steps.

Continue reading…

Repair log of Cherry MX2.0S RGB keyboard lighting failure after more than 3 years

This Cherry keyboard was bought by the blogger in April 2022 during a flash sale on JD.com, a red‑switch RGB keyboard, and has been used at the office ever since. In today’s era of domestic mechanical keyboards flooding the market, the MX2.0S doesn’t seem to have much special apart from the “Cherry” name. However, after using it for years I still feel it’s quite good, especially the layout. The shortcut keys in the upper right corner—calculator, media play, previous track, next track—are very practical. By comparison, the layout of the Durgod K310 RGB at home (which I bought earlier than the Cherry) is not as convenient.

Recently I noticed that the backlight of the PAUSE, PAGE UP, and C keys stayed constantly red. At first I thought it was a misconfigured lighting effect, so I tried installing the driver (yes, I had never installed Cherry’s driver in all these years), and also tried FN+PAUSE reset. None of this worked, so I realized it might be a hardware fault (the photo below is blurry but you can barely see the three keys stuck on red 😂).

On April 26, 2026, another group of LEDs showed the same fault, so I added a clearer photo of the symptom (the durability of MX2.0S LEDs is really poor):

During the October holiday, I took the keyboard home to disassemble and study it (and cleaned it up—after 3 years the ABS keycaps of frequently used keys are shiny with wear, and the inside was full of “treasures” accumulated over the years 😂).

Continue reading…

FFmpeg native script building Windows debug version debugging and tracing issues

This time I want to record what feels like a rather hardcore problem. Due to the title length limit, it’s impossible to accurately express all the issues. For example, when debugging FFmpeg code with breakpoints and single‑stepping, the code does not execute in order, jumps around unpredictably, and when checking local variables near a breakpoint, their values cannot be displayed correctly, such as this:

The local variable “offset” cannot show its current value and instead displays “Variable is optimized away and not available.” From the literal meaning, we can guess that the compiler optimized the code, such as inlining and removing intermediate variables, so they can no longer be seen.

However, FFmpeg’s configure parameters for building the debug version do include:

–disable-optimizations –enable-debug –disable-stripping

These officially documented debug build parameters. So why do we still encounter all the debugging obstacles described above, which look like the result of compiler optimizations?

Continue reading…