Just a few days ago, I completed a home server build. Today I decided to have a clean OS reinstallation on my development machine due to several reasons:

• Firstly, the root partition on this machine is nearing full capacity (thank you, my past self).
• Secondly, I’m consistently encountering __common_interrupt: 1.55 No irq handler for vector errors during system bootup. There’s a thread in the Arch Forum discussing this issue. Despite my efforts to resolve it through various ombinations of kernel parameters as suggested in the thread, I have not succeeded. It appears that the only viable solution is a BIOS firmware upgrade.
• Finally, there exists a paradoxical issue: I cannot decrypt the root partition without using my bluetooth keyboard, yet I cannot use my bluetooth keyboard until the root partition is decrypted and mounted (because the bluetooth driver sits in the root partition). This presents a typical chicken and egg problem. My current hack around is to use a wired USB keyboard to decrypt the root parition. However, I desperately want to abandon this workaround.

Recently, I came into possession of an old computer. Instead of letting it gather dust in the corner, I thought it would be a good idea to repurpose it as a home server. Primarily, I wanted a Samba Server, but I may go further to run other self-hosted services like NextCloud.

In this article I’ll walk through my home server setup process.

Google Cloud Platform presents two distinct types of service accounts: user-managed service accounts and Google-managed service accounts. The former is typically employed by user applications as an interface with Google Cloud, whereas the latter is utilized internally by Google Cloud. Within the realm of Google-managed service accounts, a specialized subset exists: Google Cloud Service Agents. These service agents are used by Google Cloud services to operate internal processes necessary to fulfill user-requested operations.

A service agent adhers to the following template:

service-PROJECT_NUMBER@SERVICE_NAME.iam.gserviceaccount.com

These service agents are easily identifiable within the IAM section of the Google Cloud Console.

During the management of IAM binding policies via Terraform, these service agents can often become obtrusive. For illustration, consider the following code snippet from one of our Terraform files (where xxxxx substitutes the actual project number).

In the previous article, we explored how to run a raw Linux kernel in QEMU. Another fascinating feature that QEMU provides is to initiate a GDB server. An external GDB debugger can then connect to it. This means that we can suspend the kernel running at any point of the kernel startup. By leveraging this feature, we can construct an efficient environment to debug system kernels and firmware. In this guide, we will explore the process of using this feature to debug the Linux kernel.

In the previous post we learned how to run a packaged Linux distribution in QEMU. This time, let’s explore running a raw Linux kernel in QEMU.

How to run a Linux operating system in QEMU.

I’m using Hugo + Github Pages as my personal blog platform. A Hugo site yields the following directory structure, where the public/ subdirectory stores the generated static pages:

├── archetypes/
├── config.toml
├── content/
├── data/
├── layouts/
├── public/
├── resources/
├── static/
└── themes/

How do I publish the public/ subdirectory, instead of the root directory, to Github Pages?