The box is a KAMRUI Pinova P2, a mini PC with a Ryzen 3 and 16 GB of memory I got from Amazon (no affiliate link - just search for it). It came with a 256 GB SATA drive for the system, and I added a 2 TB NVMe drive for data. The plan in the overview depends on two disks, so the first job was getting both of them seen. The box was initially bought for another purpose so its graphic GPU is a little bit of overkill but it does come in handy for transcoding (I’ll write up my media server setup some time in the future)
The Slot That Wasn't
The Pinova has two M.2 slots, and they look the same. They aren't. Only the top one, marked PCIE + SATA on the board, can talk to an NVMe drive. The bottom one is SATA only.
The SATA system drive shipped in the good slot, so I put the NVMe drive in the other one. It didn't show up in lsblk, in lspci, or in dmesg. The drive was fine, but in that slot it had no connection at all.
I swapped the two. A SATA drive works in either slot, so the system drive went to the bottom and the NVMe drive went to the top. The system still booted, because UEFI finds its boot partition by content and fstab mounts by UUID.
The case opens with a spring latch on the side, which the manual doesn't mention. I looked for screws first. The card has the rest, including what the drives are called after the swap.
The two M.2 slots in this mini PC are not the same, and the case opens with a latch the manual doesn't mention.
- NVMe data drive moved to SSD_CON1
- SATA OS drive moved to SSD_CON2
- Case opened by the side latch
Debian on One Disk
The installer only gets to see the first disk. I gave it a small EFI partition, a root filesystem and some swap, and left the data disk alone. If the summary screen had shown changes on both disks, I'd have gone back.
I left out every desktop and kept only the SSH server and the standard utilities. I also left the root password blank, which makes the installer set up sudo for my user. Set one and you get sudo: command not found on first login, and you have to fix it from a root shell.
A minimal Debian install with no desktop, on the OS disk only, leaving the data disk untouched for later.
- Hostname devbox, domain blank
- Root password left blank
- Manual partitioning on disk 1 only
- No desktop environment
- Power on after AC loss, in firmware
The First Login
Before anything interesting, I gave the box current packages, key-only SSH, automatic security updates, and a few tools Debian leaves out. I put tmux, mosh and parted in that first install because later parts need all three.
Two small things here save trouble later. The locale has to be UTF-8, or mosh won't start in part 2. And since I use Ghostty, the box didn't know my terminal type until I copied the terminfo entry over.
When I turned off password logins, I kept my SSH session open and tested a new one in a second window. That way I catch a mistake while I'm still logged in.
Updates, baseline tools, key-only SSH, a UTF-8 locale, and automatic security updates on a fresh Debian box.
- Baseline packages include tmux, mosh and parted
- SSH hardening in a drop-in
- UTF-8 locale confirmed
- Timezone set
- Plain OpenSSH as the way in
The Data Disk
I gave the second disk one partition, an ext4 filesystem, and a mount at /srv by UUID. Everything the rest of the series cares about lives under it: /srv/stacks for compose files, /srv/data for container data, and /srv/backups for the local backup copy.
Two mistakes are easy to make here. Pasting the placeholder into fstab instead of the real UUID gives can't find UUID. And a bad fstab line can stop the box at boot, so I run mount -a before I ever reboot.
The second disk as one ext4 partition, mounted at /srv by UUID, holding stacks, container data and backups.
- Mounted at /srv
- noatime
- Three top-level folders
- The device is nvme0n1
At this point the box boots, takes SSH keys, and has a data disk at /srv. You can only reach it from the home network, though.
Part 2 changes that, and it's out in a few days.
No comments yet