Linux Security

Why /boot/efi Fails After a Kernel Upgrade

When you pull a new kernel into the system, the initramfs gets rebuilt and the bootloader is updated. On UEFI machines that keep the EFI system partition in its own /boot/efi, the kernel mounts that partition right after booting to read EFI variables and the boot‑loader configuration. A mis‑configured /etc/fstab, a missing vfat module, or a stale initramfs can bite you early, dropping you into an emergency shell before the kernel even gets a chance to run. You’ll usually see something like:

When a new NVMe sticks, the boot can stall at “Loading initramfs”

Adding a second NVMe drive to an existing Ubuntu 24.04 installation is a quick way to get more storage or carve out a dedicated data partition.
Most of the time the kernel pulls the NVMe driver on its own, but a handful of mis‑configurations can make the system hang in the initramfs shell.
Typical symptoms:

• The screen shows “Loading initramfs …” and then stops.
• The prompt switches to a root shell (root@hostname:/#).
• Nothing else happens until you manually exit or reboot.

Below is a hands‑on walk‑through of the most common culprits and how to fix them. I’ll assume you have a working Ubuntu 24.04 install and a spare NVMe device that you just plugged in.

Run a single command as root with systemd‑run

When you just need to fire up one command as root and then drop back, sudo is the go‑to.
But if your distro already runs systemd, systemd‑run can be a leaner, more isolated way to do it—especially for short‑lived tasks.

What systemd‑run actually does

systemd‑run spawns a transient unit (either a scope or a service) that inherits the caller’s privileges and then elevates them to root when you add --user or --scope with --user.
Unlike sudo, the unit vanishes as soon as the command finishes, and you can sprinkle a handful of systemd properties on it to tighten the environment.

When you fire up a heavy build, a data‑scraping job, or a local web server inside a tmux session, the usual pattern is to detach and log out. tmux will happily keep the session alive as long as your login shell stays around, but as soon as you hit logout or PAM times you out, the whole tree dies. Wrapping tmux in a systemd unit makes it immune to those surprises and gives you the same tooling you already use for other services—logging, restart policies, limits, and isolation.

Why pull a single file from a Borg archive?

When a configuration file or a database dump is corrupted, you often need only that one file, not the whole archive. Extracting the entire archive just to get a single file wastes bandwidth, CPU, and disk space—especially when the archive lives on a remote server or in a cloud bucket.

Because Borg keeps the archive compressed and deduplicated, the cost of pulling a single file is proportional to the file’s size and the number of blocks it occupies. Below is a quick walk‑through for retrieving a single file efficiently, both locally and remotely, and piping the data through other tools for immediate processing or secure transfer.

Why JSON‑friendly syslog matters

Syslog is the default source for almost every Linux service. When an error happens, the kernel or a daemon writes a line that looks like this:

Oct  6 12:34:56 myhost kernel: [12345.678901] EXT4-fs error (device sda1): ext4_find_entry:1073: inode #123456: comm: myapp: file name too long

Grafana loves structured data. A plain text file is hard to query, filter, or aggregate. By converting the error lines to JSON you can:

Why SSH Still Asks for a Password After Adding a Key

Adding a public key to ~/.ssh/authorized_keys is the first step toward password‑less login, but the SSH daemon can still fall back to password authentication for a handful of reasons. The most common culprit is a mis‑configured PubkeyAuthentication setting in /etc/ssh/sshd_config or a permissions problem that causes the server to ignore the key file.

1. Verify the Key Is Accepted by the Server

# On the client
ssh -vvv user@host

The -vvv flag prints the entire authentication dance. Look for lines like:

The “Host key verification failed” error after renaming a jump host

When you rename a jump host (or any SSH‑accessible machine) the client still keeps the old hostname in its ~/.ssh/known_hosts. On the next connection the client pulls the key presented by the renamed host and compares it with the stored key for the old name. The mismatch triggers the classic

Host key verification failed.

It’s a safety net against man‑in‑the‑middle attacks, but it can be a nuisance when you legitimately change the hostname. Below is a practical, step‑by‑step fix, a few automation tricks, and some security notes I’ve learned after 20 years on the grind.

Why the $USER Variable Matters for Systemd Timers

Systemd timers are the go‑to replacement for cron on almost every distro. They’re declarative, mesh cleanly with the unit graph, and bring a bunch of goodies—persistent timers, calendar syntax, and dependency handling. The catch? If your timer’s service unit runs a script that relies on $USER, you’ll see a silent failure after a reboot. Systemd doesn’t set $USER for system‑wide units; it only populates it for user‑specific units that run in a logged‑in session.