19f4958fb5
Two related gaps in how WROLPi serves Kiwix content: 1. A fresh WROLPi (or one whose zims are all corrupt/absent) showed a blank Kiwix. Every image now ships a small built-in default Zim that Kiwix falls back to, telling the user to download real Zim files. 2. The startup scripts hardcoded the `/zims` directory, ignoring wrolpi.yaml's `zims_destination` (which the Python side already honors). Changes: - New wrolpi/scripts/read_config_value.sh: a zero-dependency (awk) reader so non-Python scripts can reliably read top-level wrolpi.yaml scalars. Also a config_value() wrapper in wrolpi/scripts/lib.sh. - New wrolpi/scripts/default_zim/: HTML source + a reproducible builder (ghcr.io/openzim/zim-tools) that outputs the committed wrolpi/blobs/default.zim. - New wrolpi/blobs/: any committed blob here is copied to /opt/wrolpi-blobs by the pi-gen and debian-live builds; the Docker zim image bakes it in. - start_kiwix_serve.sh honors zims_destination and falls back to the default Zim when no functioning zim is found. - docker/zim/entrypoint.sh gains the same default-Zim fallback. It needs no config read: it already scans the whole mounted media dir, and zims_destination is always a subdirectory of that mount. - Changing zims_destination via the settings API now restarts Kiwix so it serves the new directory without a reboot. Tests: new test_read_config_value.py, extended test_start_kiwix_serve.py (configured dir + default-Zim fallback), and a root_api test for the restart. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| config | ||
| files | ||
| build.sh | ||
| README.md | ||
Debian Live Config
Build a bootable amd64 ISO that boots into a full WROLPi system on any x86 PC. Users can run WROLPi directly off the USB (a persistence partition is created on the first boot so the database and media directory survive reboots) or install to disk via the Calamares launcher on the desktop.
The chroot-phase build is identical for both modes; the resulting squashfs is what runs in live mode AND what Calamares copies onto the target disk.
See https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html
Build
sudo ./build.sh # build from 'release' branch
sudo ./build.sh -b master # build from a specific branch
Requires Debian / Ubuntu with live-build installed. The resulting ISO is
written to this directory as WROLPi-v${VERSION}-amd64.iso.
Flash with Raspberry Pi Imager, Rufus, or:
sudo dd if=WROLPi-v${VERSION}-amd64.iso of=/dev/sdX bs=4M status=progress conv=fsync
Upgrading an existing WROLPi USB
A WROLPi USB carries two partitions: the ISO (boot) partition and a
persistence partition created on first boot that holds your library,
database, and configuration. To move to a newer ISO without losing the
persistence partition, use scripts/wrolpi-usb.sh from any Linux host:
sudo ./scripts/wrolpi-usb.sh upgrade WROLPi-v${VERSION}-amd64.iso /dev/sdX
It backs up the partition table, overwrites only the ISO partition, and re-adds the persistence partition entry at its original location. The ISO partition reserves 8 GiB of headroom so a larger future ISO still fits ahead of the persistence partition.
Converting an existing data drive (not supported)
There is no in-place conversion of a drive that already holds your data
into a WROLPi USB — flashing the ISO erases the whole drive, and there
is no safe, filesystem-agnostic way to graft WROLPi onto a full drive.
scripts/wrolpi-usb.sh install only prints this procedure:
- Back up everything on the drive to another disk.
- Flash the whole drive with the ISO (Raspberry Pi Imager/Rufus/
dd— this erases it). - Boot once so WROLPi creates its persistence partition and sets itself up.
- Copy your data into
/media/wrolpi/, then let WROLPi refresh/repair to index the restored files.
Afterwards, future ISO upgrades preserve your library via the
upgrade command above.
Layout on disk
The drive carries everything WROLPi needs. The SQLite database lives alongside the user's library so a drive moved between hosts keeps its full state:
/media/wrolpi/
videos/ ← user-facing media
archives/
zims/
map/
tags/
config/
wrolpi.yaml
controller.yaml
fstab.yaml
ssl/
wrolpi.db ← SQLite database (created by the
API on first start; -wal/-shm
sidecars appear while running)
Booting via Ventoy or other multiboot USBs
Booting WROLPi via Ventoy, YUMI, Easy2Boot, AIO Boot, GLIM, or any other tool that loop-mounts the ISO works, but only in ephemeral mode.
When the live medium appears under /dev/loop*, /dev/dm-*, or
/dev/mapper/* (the kernel's tell-tale for a loop/device-mapper-backed
file rather than a real partition), wrolpi-bootstrap.sh refuses to
create a persistence partition. The underlying disk in that case is the
user's Ventoy stick, not a blank target — appending a new ext4 partition
to it would risk corrupting the user's other ISOs and data.
Instead the script mounts a tmpfs at /media/wrolpi (sized to half of
RAM by default), and the rest of the boot is unchanged. The config
layout and SQLite database are created as usual, just into RAM. The
user sees a "Running ephemerally…" notice in the first-boot dialog.
Everything written to the WROLPi library — downloads, archives, video
metadata, the database — is lost on reboot. This mode is intended for
trying WROLPi out without committing a USB stick; for any real use,
flash the ISO directly to its own drive with Raspberry Pi Imager or dd.
Direct (Raspberry Pi Imager/dd) boot is distinguished by the live medium living under
/dev/sd*, /dev/nvme*, or /dev/mmcblk*; this is the only shape
where wrolpi-bootstrap.sh will touch the partition table.
(Future work: integrate with Ventoy's native persistence.dat flow so
the user can opt into a persistent ephemeral-style image without
needing a dedicated drive.)
Implementation status
- Phase 1 — merged live + chroot config: Single
debian-live-config/produces a Debian Live ISO with the full WROLPi stack, XFCE auto-login aswrolpi, persistence partition created on first boot. - Phase 2 — Debian Installer: Standard
debian-installerbundled vialb config --debian-installer live --debian-installer-gui true. GRUB exposes "Live", "Install", and "Graphical Install" entries. Live boots into WROLPi; Install/Graphical Install copy the running squashfs onto the target disk via Debian'slive-installerflow. (We previously tried Calamares-as-the-installer; the XFCE desktop-icon click path proved unreliable in the wrolpi auto-login session and the upstream d-i path is better-tested.) - Phase 3 — Ventoy/multiboot safety:
wrolpi-bootstrap.shdetects when it's been booted via a loop-mounted ISO (Ventoy and friends) and falls back to a tmpfs-backed/media/wrolpiinstead of writing a new partition onto the user's multiboot stick. - Release: CI on tag, hosting, wrolpi.org docs.