Guide

Ollama is a runtime for local execution of large language models. Installation and startup are performed with a single command; manual dependency setup and virtual environments are not required. Local machine → Ollama → Model (Llama, Qwen, Mistral...) Advantages: Data never leaves the local machine No internet connection required for inference No subscriptions or limits Works on CPU (with limited performance) Installation NixOS # configuration.nix services.ollama = { enable = true; # Optional: list of models for auto-loading # models = [ "qwen2.5:7b" ]; }; Apply: ...

The system fails to boot, dropping into emergency mode, or throws this error during operation: Structure needs cleaning This indicates critical metadata corruption (superblock, inode table, or journal). The kernel forcibly mounts the root (/) as Read-Only to protect the data. ⚠️ Limitations of In-System Recovery Attempting to fix the root FS from within the running system is a dead end: mount -o remount,ro / returns target is busy because background processes hold files open. Mass-killing processes (killall5, fuser) often causes session hangs or respawns. Using umount -l / (lazy unmount) detaches the root, but instantly makes all binaries unavailable (sudo, e2fsck, mount), as they reside in /nix/store, which is now unmounted. 💡 Conclusion: Fixing the root FS from within itself is impossible. The only reliable path is external intervention. ...

Scrcpy (Screen Copy) is a tool for displaying and controlling Android devices from a computer. Benefits: ✅ No root required ✅ Low latency (35~70 ms) ✅ High quality (up to 1920×1080 or higher) ✅ Works over USB and Wi-Fi ⚠️ Main Issue: “Connection refused” When attempting to start wireless mode directly with: scrcpy --tcpip=192.168.x.x The error occurs: failed to connect to '192.168.x.x:5555': Connection refused. Reason: By default, the Android debugging daemon (adbd) listens only on the USB interface. Port 5555 is closed until the device is explicitly switched to TCP/IP mode. ...

Instead of reformatting the USB for each new image, Ventoy allows copying ISO files as regular files. At boot, a menu appears with all available images. Benefits: ✅ No need to rewrite USB for each image ✅ Support for Windows, Linux, utilities - all on one drive ✅ Regular files accessible from any OS ✅ Flexible configuration via JSON 🗂 Correct USB Structure [First USB partition - exFAT/NTFS] ├── /ventoy/ # ← Must be here! │ ├── ventoy.json # Main config │ ├── revi/ # Windows auto-install │ │ └── autounattend.xml │ └── theme/ # Custom theme │ └── distro/theme.txt │ ├── BACKUP/ # Working files ├── LINUX/ # Linux ISOs │ ├── Archlinux 2025.12.01.iso │ ├── Debian 13.2.0.iso │ └── NixOS 25.11.1734.iso ├── WINDOWS/ # Windows ISOs │ ├── Windows 10 22H2.iso │ ├── Windows 10 Enterprise LTSC 2021.iso │ └── Windows 11 25H2.iso ├── ReviSetup/ # Post-install scripts │ └── setup.cmd └── UTILS/ # Utilities ├── gparted-live.iso └── memtest86+.iso ⚠️ Critical: /ventoy/ must be on the first partition (where ISOs are), NOT in root! ...

📌 This is Part 3 of the series. Part 1: Theory, Part 2: Practice. 🔗 What We’re Integrating Component Purpose Difficulty ONEmesh MQTT Bridge between local mesh and global map + Telegram notifications 🟢 Low Home Assistant Node sensors, device_tracker, automations on mesh messages 🟡 Medium Notifications Alerts for new nodes, lost connection, mentions in chat 🟢 Low 💡 All examples tested on: HA 2026.4.2 (Docker) + Orange Pi 3B + built-in MQTT broker. ...

Home Assistant in Docker doesn’t see Bluetooth devices, even if everything works on the host. Causes: ❌ Container has no direct access to /dev/hci0 ❌ BlueZ inside container conflicts with host daemon ❌ Passive BLE scanning requires --experimental flag in BlueZ Solution: Don’t run Bluetooth stack inside container - passthrough D-Bus from host instead. ✅ Docker Compose Configuration Minimal Setup services: home-assistant: container_name: home-assistant image: ghcr.io/home-assistant/home-assistant:stable volumes: - config:/config - /run/dbus:/run/dbus:ro # ← Critical for Bluetooth cap_add: - NET_ADMIN - NET_RAW - SYS_ADMIN restart: unless-stopped networks: - traefik - prometheus volumes: config: driver: local networks: traefik: external: true name: traefik prometheus: external: true name: prometheus ⚠️ Don’t add devices: - /dev/hci0:/dev/hci0 - not needed with D-Bus passthrough and may cause conflicts. ...

On Orange Pi 3B, the built-in Bluetooth chip Spreadtrum UWE5622 is connected via UART (/dev/ttyBT0). Unlike USB adapters, it requires: Loading firmware and calibration data before initialization Running hciattach_opi with correct flags Correct startup order: chip initialization first, then BlueZ daemon Symptoms: bluetoothctl scan on → No default controller available btmgmt info → Index list with 0 items hciconfig -a shows hci0, but bluetoothctl doesn’t see it Error org.bluez.Error.Busy when trying to power on Cause: The service orangepi3b-sprd-bluetooth.service runs hciattach_opi with the -n flag (no-detach), which holds the device and prevents BlueZ from registering the controller. ...