radagast (radagast.critchley.biz) is a separate FreeBSD host whose data lives entirely on a two-disk ZFS mirror (pool zroot). Those two disks are not installed in a machine of their own right now — they're plugged into (USB/SCSI-attached) and mounted on host pomelo, a separate Linux host. Everything below happened on pomelo while working with radagast's disks.
Two SCSI/USB-attached disks on host pomelo (sda, sdb, both WDC WD10EZEX-00MFCA0, 931.5G, HCTL 0:0:0:0 / 0:0:0:1) each contain two ZFS-member partitions:
obj — left untouched.zroot, a two-way mirror (mirror-0: sdb + sda).lsblk -S -o NAME,HCTL,TYPE,TRAN,SIZE,MODEL,SERIAL and confirmed pool membership with sudo zpool import and sudo blkid /dev/sda2 /dev/sda3 /dev/sdb2 /dev/sdb3.sudo mkdir -p /zroot.sudo zpool import -R /zroot zroot, but the pool's dataset mountpoint properties already default to /zroot (inherited from pool name, not explicitly set), so this doubled up to /zroot/zroot.sudo zpool export zroot && sudo zpool import zroot. This mounts the pool's datasets directly under /zroot using their native mountpoint properties.Pool root dataset zroot mounts at /zroot; child datasets mount at /zroot/home, /zroot/p, /zroot/q, /zroot/tmp, /zroot/usr. Dataset zroot/linux has no mountpoint (canmount not set / not mounted). This looks like a FreeBSD-style root filesystem layout (separate /usr, /tmp, /home, /var-style datasets), not this Linux host's own root.
Pool scrub history: last scrub completed 2024-09-08, 0 errors, both mirror members ONLINE.
sudo zpool import zroot) after a reboot.obj pool (on the 4G partitions of the same two disks) was left unimported/untouched; only zroot was mounted, per the task.zpool upgrade was NOT run, to avoid breaking compatibility with whatever system originally created this pool.Goal: boot the existing FreeBSD 10.4-STABLE install directly in a VM so it imports/handles ZFS itself (same as real hardware), upgrade FreeBSD inside the VM, then eventually return the disks to physical hardware. Investigated and confirmed: AMD SVM + /dev/kvm available; disks use legacy BIOS boot (GPT protective MBR, freebsd-boot partition, gptzfsboot) with no EFI partition, so plain QEMU/SeaBIOS works, no OVMF needed. loader.conf has zfs_load=YES, vfs.root.mountfrom=zfs:zroot, bootfs=zroot.
Installed qemu-system-x86 and qemu-utils (8.2.2, apt) on the host. NOT yet run: the pool is still imported/mounted and in active use on the host, so the VM has not been started.
Launch script (manual only, no autostart configured anywhere): /home/john/extdrive/vm/start-freebsd-zroot-vm.sh. It refuses to run if zroot is currently imported on the host, and otherwise passes /dev/sda and /dev/sdb straight through to QEMU as a virtio-scsi controller (so FreeBSD sees them as da0/da1 and imports the mirror itself). Steps to actually use it later: sudo zpool export zroot on the host, then run the script; when finished, export zroot inside the guest, shut down the VM, and re-import on the host (or reinstall the disks in physical hardware) exactly as before — no partition or ZFS on-disk changes are involved.
Guest hostname (from /zroot/etc/rc.conf): radagast.critchley.biz. Guest real user accounts (from /zroot/etc/passwd): john (uid 1001, /home/john, the account to use), plus kathy, isaac, john1, john-m.
None of the hosts current ~/.ssh keys matched any guest authorized_keys. Found /zroot/home/john/.ssh/id_rsa on the guest whose own public key is already listed in that same authorized_keys file (self-trusted, no passphrase, RSA 2048, comment john@banana). Copied it to the host as ~/.ssh/id_rsa_radagast / id_rsa_radagast.pub (named after the guest hostname) for future SSH access into the VM.
VM networking added to /home/john/extdrive/vm/start-freebsd-zroot-vm.sh, mirroring how pomelo itself picks an interface: if enp1s0 (eth) has link, the script bridges the VM onto it via a temporary br-vm0 (real DHCP lease on the LAN, restored/torn down on exit); otherwise (Wi-Fi only, as now, since Wi-Fi cannot be L2-bridged) it falls back to QEMU usermode NAT with SSH forwarded at localhost:2222. Display kept as local GTK only, no VNC. Still not started; zroot remains imported/mounted and in active use on the host.
Searched a full find /zroot listing (/home/john/extdrive/zroot_list.txt, ~4.6M lines) for a scanned PhD certificate for Kathy (maiden name Katherine Louise Hudson). Not found anywhere on the filesystem, in either the live share or old backup copies.
Live directory with the family educational certificate scans: /zroot/p/http/canadaforms/ (same content also exists as older copies at /zroot/q/other/p/kathy/canada/forms/ and /zroot/p/http/tmp/). Contains, for a ~2004 Canada immigration application: Kathy - kathyonc.bmp/kathyonc2.bmp (ONC), kathybeng.bmp (BEng, Coventry Polytechnic, 1991), kathymsc.bmp (MSc, Coventry University, 1992), kathypgd.bmp (Postgraduate Diploma); John - johnbsc.bmp, johnmsc.bmp, johnsfrenchcse.bmp; plus identity photos, passport/birth certs for Isaac/Joshua/Samuel, and immigration forms. No PhD file for either John or Kathy in this set.
Kathys actual PhD thesis drafts/chapters/appendices (not a certificate scan) are at /zroot/q/other/q/home/kathy/thesis/THESIS1/ (sheet-metal-forming/springback research, corrections dated 2003). Likely explanation: the PhD was awarded around/after the 2004 immigration paperwork was assembled, so no certificate scan was ever added to this set. If a physical certificate exists, it will need a fresh scan.
Also checked /zroot/p/http/Deregistration/ (1.png, 2.png, 3.png): not the PhD certificate, but three Swiss Gemeinde Zumikon Wohnsitzbescheinigung (residence deregistration) certificates dated 08.02.2006, for Kathy, Joshua, and Isaac, covering a stay in Zumikon from 11.08.2005-16.11.2005 before moving back to the UK. Kathys is listed as Rufname/Vorname Katherine Louise Dr. (Critchley-Hudson, b. 23.12.1966, Coventry) - confirms she already held the Dr. title by 2005/2006, but is not the certificate scan itself.
Found /zroot/p/mysql/john/worldcitiespop.frm/.MYD/.MYI — a MySQL 5.6 MyISAM table (3,173,959 rows) holding MaxMind's old free worldcitiespop.txt dataset (country/city/region/lat/lon/population), imported ~2017. Analysed non-destructively (copied to a scratch dir on pomelo, loaded into a throwaway MariaDB instance, queried, then deleted the copy and shut the instance down — nothing on /zroot was touched).
Verdict: low value. Only 47,980 of 3.17M rows (1.5%) have a nonzero population; row id=1 is a stray imported CSV header row; the dataset itself is a discontinued, unmaintained MaxMind file from the mid-2000s–2012 era that MaxMind itself stopped updating in favour of GeoNames. It's superseded by location-db/gazetteer's geonames-cities5000 (69,562 rows, global, pop≥5,000) and geonames-GB (109,177 rows) sources, both newer and better-maintained. Not loaded into location-db.
Maybe delete on radagast: these three files (/zroot/p/mysql/john/worldcitiespop.frm/.MYD/.MYI, ~395M total) look like dead weight now that location-db has a better replacement — not deleted here, left for a decision when radagast (or its data) is next actually worked on.
Ongoing project to bring this system's FreeBSD install up to date entirely from source (no binary upgrade, no clean reinstall). Detail, plan, and progress log: hosts/radagast/source-upgrade.
TODO (agreed 2026-09-16, deferred until after the 11.4 hop finishes): give radagast a real routable address instead of QEMU usermode NAT. Today it has 10.0.2.15, private to QEMU's NAT and unreachable from pomelo — so there is no address that can usefully go in /etc/hosts, and it is reached only through the forwarded port (localhost:2222). Interim workaround in place: Host radagast and Host radagast-john entries in pomelo's ~/.ssh/config, so ssh radagast works. Proper fix: a host-only bridge plus tap device, giving the guest a real address on its own subnet, then a genuine /etc/hosts line and updated ssh config. Important: do NOT reuse the stock launch script's bridge path — that bridges onto enp1s0, which now carries the NAS network (192.168.99.1/24 plus a dnsmasq DHCP server) and would cut the NAS off. The new bridge must be a separate, host-only one. Needs a VM restart, hence the deferral.