DEV Community: Musa Nayyer

CachyOS Wouldn't Install and My NVMe Was the Problem (Corrupted GPT + chwd Fix)

Musa Nayyer — Fri, 29 May 2026 11:47:30 +0000

CachyOS Wouldn't Install and My NVMe Was the Problem (Corrupted GPT + chwd Fix)

I was setting up CachyOS on a secondary laptop — i7 11th Gen, NVIDIA mobile GPU, Micron 2210 NVMe. Should've been a clean install. It wasn't. Two specific things broke and both of them looked like my fault until they weren't.

Problem 1: The NVMe with an Identity Crisis

The CachyOS installer (Calamares) failed to create a partition table on the Micron 2210 NVMe. No useful error, just a failure. I dropped into the terminal and ran gdisk:

sudo gdisk /dev/nvme0n1

Three warnings. Then this:

MBR: not present
BSD: not present
APM: not present
GPT: damaged
Found invalid MBR and corrupt GPT.

The drive had a corrupted GPT and ghost MBR headers from a previous install. The Calamares installer couldn't write a clean partition table because it was fighting old metadata it couldn't fully read or overwrite.

The fix is a full zap from inside gdisk:

sudo gdisk /dev/nvme0n1
# at the prompt:
x        # enter expert mode
z        # zap GPT data — confirm with y
         # then zap MBR — confirm with y

Drive came out completely clean. Re-ran the installer, partition table created without issue.

If gdisk can't get there, hit it with wipefs first:

sudo wipefs -a /dev/nvme0n1

Intel VMD note: If you're on an 11th Gen Intel laptop, check your BIOS for Intel VMD (Volume Management Device). If it's enabled, Linux can see the NVMe drive but can't write to it properly. Disable VMD or switch from RAID to AHCI/NVMe mode before trying any of the above.

Problem 2: chwd Killed the Install Mid-Way

After getting past the NVMe issue, the installer failed again — this time at chwd, the CachyOS hardware detection tool. The online installer couldn't pull the driver profiles, likely a mirror timeout.

The fix: switch to the offline installer.

It installs a default desktop from the USB without pulling anything from the network. Once booted into the system, run hardware detection manually:

sudo chwd -a

That scans your hardware and applies the right driver profiles — in my case, the Intel + NVIDIA hybrid (Optimus) setup for the laptop.

TIL

Old partition metadata is silent until it isn't. Before installing anything on a drive that's been used before, zap it manually — don't trust the installer to do it cleanly.

muzasio #til #devlog #techexperiment #linux #cachyos #nvme #archlinux

I Tried Building a Complex Security Tool with a 1.5B Local Model — Here's What Broke

Musa Nayyer — Wed, 27 May 2026 20:06:50 +0000

Problem: I had aider running on Lubuntu, three API keys configured, a detailed architecture diagram, and a clear goal — build a modular forensic data analysis pipeline. What I actually got was token walls, a model that replied "Ok." to everything, and a half-made project directory with nothing inside it.

The Setup

Installed aider via the official shell script on Lubuntu. Connected three models:

OpenAI — failed outright, key didn't authenticate
Grok — worked partially, got some directory scaffolding done before tokens ran out mid-session
Ollama local (Qwen 2.5 Coder 1.5B) — connected fine after setting OLLAMA_API_BASE=http://localhost:11434, but the model kept responding with "Ok." and two tokens flat The architecture I was trying to build had seven layers: data acquisition, integrity hashing, normalization, schema mapping, anomaly detection, explainability, and 3D visualization with Three.js. Ambitious. Too much for a 1.5B model to hold in its head at once.

What I Tried

First I threw the whole diagram at aider and asked it to scaffold everything. Grok started making directories. Tokens ended. Switched to local Ollama. Local model saw the repo map, said "Ok." — twice. No output, no errors, no explanation.

I tried prompting it to list the project structure. Still "Ok." Tried asking it to read what happened in the folder. "Ok." The model wasn't broken — it was overwhelmed. A 1.5B model with a full repo map in context has almost no room left to actually generate code.

Then I realized the real problem: I was treating a small local model like a senior engineer. It's not. It's a fast, cheap code-completer that needs a tight scope and a single task.

What Actually Worked

Three things changed the outcome:

1. One module at a time. Instead of "build the pipeline," I asked for one function in one file. The model went from "Ok." to producing real code.

2. /read instead of /add. Using /read for files the model doesn't need to edit cuts token usage significantly. The model gets context without burning its window on write permissions.

3. Git as memory across models. When Grok's tokens ran out mid-session, I committed whatever it had produced. When I switched to Ollama, I opened with: "The previous model created the acquisition and integrity folders. Look at the current files and continue with the normalization script." The local model picked up cleanly — because git was the real memory, not the chat history.

Result

Got a working acquisition/ module and a schema/event_schema.json with the Canonical Event Schema defined. The hashing layer and normalization parser came from the local model once I stopped giving it too much context at once. The Three.js visualization is still pending — that's a job for Gemini's free tier, which handles frontend/creative code better than a 1.5B coder model.

The pipeline isn't done. But the architecture is solid and every module has a defined input/output contract, which means any model can continue any piece without needing the full history.

TIL

A 1.5B local model isn't bad at coding — it's bad at holding a complex project in context. Split the work into single-function tasks, use git commits as handoff points between models, and let the repo map do the heavy lifting instead of bloating the chat history.

muzasio #til #devlog #techexperiment #aider #ollama #localai #cybersecurity #linux

Signal QR Stuck on Spinner — University Firewall Was the Culprit

Musa Nayyer — Sun, 24 May 2026 06:43:16 +0000

Problem: I tried linking my iPhone as a secondary Signal device. The QR code just spun forever — a loading spinner inside a white box. No error. Just nothing.

My setup: Primary device — Redmi 13C (PTA), Signal registered and working. Secondary device — iPhone (non-PTA). University Wi-Fi. I wasn't doing a full registration or transfer. Just: Settings → Linked Devices → Link New Device on iPhone. Dead silence from Signal.

What I Tried

First assumption: it's the non-PTA iPhone. Maybe Signal's blocking it? Nope — PTA status is a cellular registration thing. It has zero effect on Wi-Fi app behavior.

Second assumption: maybe I need to select "transfer from Android"? Nope — I didn't want a transfer. Just a secondary link. The flow is: iPhone shows QR → Redmi scans it.

I got the flow backwards at first too. Thought Redmi generates QR, iPhone scans. Wrong. iPhone (secondary) generates the QR. Redmi (primary) scans it.

The QR never loaded on iPhone. That's when it clicked — it's not the phone, it's the network.

What Actually Happened

Signal's QR code generation isn't local. The iPhone hits Signal's provisioning API (api.signal.org, storage.signal.org) to create a time-sensitive token before displaying the code. My university network was blocking those endpoints.

Why did Redmi register fine earlier? Probably a different time, different access point, or Android and iOS clients have different TLS fingerprints — and the firewall's application-layer inspection treats them differently. University-grade firewalls (Fortinet, Palo Alto) do this.

The Fix

Proton VPN on both devices, same server location.

Installed Proton VPN (free tier) on both iPhone and Redmi
Connected both to the same server (Netherlands)
On iPhone → Signal → Linked Devices → Link New Device
QR code appeared instantly
Redmi scanned it — linked successfully

6. Redmi got logged out immediately after. That's not a bug — Signal logs out existing sessions when a new device links, by design. Re-registered with the phone number and everything was fine. Message history is local anyway; it doesn't sync across linked devices.

Key Insights

The QR code requires a live API call. If Signal's servers are unreachable, the spinner loops forever with no error message. Signal could honestly show a better error here.
iOS and Android Signal clients behave differently at the network level. A firewall can block one and pass the other.
University networks block more than you think. VoIP, messaging APIs, certain CDN routes — it's not just torrents.
Free VPN is enough for this. Proton VPN free tier worked fine. No speed requirements for a one-time provisioning handshake.

- Both devices need to be on the same network exit. The provisioning token is bound to the originating network context. If iPhone generated it over VPN and Redmi scanned from plain university Wi-Fi, it failed with "QR code not valid."

TIL

Signal's device linking QR is a remote token, not a local code — and if your network blocks Signal's API endpoints, you'll get an endless spinner with zero explanation.

Firefox Profiles Frozen and Corrupted on CachyOS — What Broke and How psd Was the Culprit

Musa Nayyer — Fri, 22 May 2026 12:35:15 +0000

The Problem

Opened Firefox one morning and the profile picker showed up. Clicked my main profile — nothing happened. Hover worked, tooltips appeared, but clicks registered nowhere. Profile 1 was already dead the day before. Only the third profile (sss) responded. Main profile had six accounts in it.

What I Tried

Keyboard navigation — nothing. Tab and Enter didn't work either.

Checked the Firefox profile directory and found this:

lrwxrwxrwx  lbjm2hpz.Profile 2 -> /run/user/1000/psd/user-firefox-lbjm2hpz.Profile 2
lrwxrwxrwx  xcpk3xfu.default   -> /run/user/1000/psd/user-firefox-xcpk3xfu.default

Symlinks. Not real directories. psd (profile-sync-daemon) moves Firefox profiles to RAM and replaces them with symlinks. The RAM targets were either empty or broken.

Ran psd preview — confirmed psd was managing both profiles. xcpk3xfu.default showed profile size 0. That profile was already gone.

Tried psd resync — ran without errors but didn't fix the picker clicks.

Tried launching directly from terminal:

firefox --profile "/home/user/.config/mozilla/firefox/lbjm2hpz.Profile 2"
firefox -P "default-release" --no-remote
MOZ_ENABLE_WAYLAND=0 firefox --profile "/home/user/.config/mozilla/firefox/lbjm2hpz.Profile 2"

All three kept opening the sss profile instead. The --no-remote attempts threw repeated channel errors because Firefox was already running.

Checked about:profiles — confirmed the current window was actually running default-release (the main profile), but it was completely empty. No accounts, no history, nothing. The 49M of data was somewhere but Firefox wasn't seeing it.

Stopped psd, deleted the broken profile directory, tried restoring from the -backup folder — backup had disappeared when psd stopped (psd overwrites it on shutdown with whatever is in RAM). Only a crashrecovery folder from earlier that morning survived with 49M of actual data.

Restored from crashrecovery, started psd again — psd immediately created a new symlink pointing to RAM and the profile went missing again. psd was overwriting the restore on every start.

The GUI click issue turned out to be a separate Wayland input problem with the Firefox profile picker — unrelated to psd but compounding the mess.

Root Cause

psd syncs browser profiles to RAM for speed. On unclean shutdowns or crashes, the sync back to disk fails. The -backup folder gets overwritten on the next psd start with whatever empty state is in RAM. Over time this had been happening repeatedly — the profile directory had 64 crash recovery folders going back months, all showing the same pattern.

xcpk3xfu.default was already fully gone. lbjm2hpz.Profile 2 survived only because a crashrecovery snapshot existed from earlier that same day.

The Fix

Disabled Firefox in psd by adding this to ~/.config/psd/psd.conf:

BROWSERS=(google-chrome)

Restarted psd. Firefox now reads directly from disk. No more symlinks, no more RAM sync, no more silent corruption on shutdown.

Also ran psd clean to delete the accumulated crash recovery folders and reclaim disk space.

TIL

psd is a silent data risk on systems that crash or suspend frequently — it will eat your browser profiles and leave behind only empty backup folders.

How I got out of dependency hell with Docker (SpiderFoot OSINT lab)

Musa Nayyer — Mon, 20 Apr 2026 20:47:23 +0000

I wanted to try SpiderFoot – an OSINT tool. Thought it would be a simple pip install.

Nope.

It crashed on lxml. Something about headers and versions. Classic dependency hell on Arch.

I didn't want to mess up my main system. So I gave up on virtual environments and used Docker instead.

Here's what worked.
Set this up so you don't need sudo for every command.

1. Docker permissions

sudo usermod -aG docker $USER
newgrp docker
sudo systemctl restart docker

2. Clone and build

Grab the source and build the image locally.

git clone https://github.com/smicallef/spiderfoot.git
cd spiderfoot
docker build -t spiderfoot .

3. Run it (the easy way)

I used the VS Code Docker extension. Built the image, then ran the container from the UI. The extension shows all running containers on my system, so I could start/stop it with one click.

If you prefer the command line, this works too:

docker run -d -p 5001:5001 --name spiderfoot-app spiderfoot
Either way, open http://localhost:5001 and SpiderFoot is there.

Why I'm doing this
I'm a beginner in cybersecurity. I don't want to install random tools directly on my laptop. With Docker, I can try anything and delete it later without breaking stuff.

This worked for me. Might work for you too.