Repository navigation
os/v3/puppy: the appliance cannot answer an mDNS query, so 1bit-os.local never resolves #952
Description
Owner (2026-11-04 ~01:3x): the 1bit OS appliance should be reachable by a clickable link from ryzen or a phone, i.e. http://1bit-os.local:13305, not only by IP.
Measured in the built resolute64 rootfs (the image the c20 stick was written from): libavahi-client/libavahi-common are present, but /usr/sbin/avahi-daemon is not, and nothing in the image answers an mDNS query. getent hosts 1bit-os.local has nothing to resolve against because nsswitch.conf has no mdns line either.
Two halves, both missing:
- responder —
avahi-daemonpackage row + a boot service. PID 1 in this image is not systemd, so nothing starts the D-Bus system bus that avahi needs; the service must start the bus itself. - client name resolution —
libnss-mdnspackage row +mdns4_minimalinnsswitch.conf, orgetent hosts 1bit-os.localcannot resolve the name the appliance publishes.
The image also has to refuse to be published without both, and vm-check needs a row that asserts the name resolves on the box (peer-on-the-LAN resolution needs multicast from outside the guest, which QEMU user networking does not carry — that half is the board's).
Found on the c20 board (TOS3-C18-items.md item 10).
Activity
bong-water-water-bong commentedon Nov 4, 2026
Triaged; the fix is already up as PR #953 (pi-os3), which carries
closes #952.Your two halves are exactly the two refusals in that PR, and it does the right thing on the part that is testable without multicast:
os/v3/puppy/embed/etc/init.d/18onboard-mdnsstarts the D-Bus system bus itself beforeavahi-daemon— the point your report makes (PID 1 here is not systemd, andavahi-daemonexits without a bus) is the reason it is a script and not a package's service file;libnss-mdnsinpackages-extra+md4_minimalinnsswitch.conf, sogetent hosts 1bit-os.localhas something to resolve against;os/v3/puppy/container-build.shfails an image missing either, so this cannot regress silently — which is the#657class this board has spent three passes on, applied on purpose.What is verified vs what is not, stated on the PR itself (and worth keeping that way):
getent hostsinside the guest is theU2 mdnsvm-checkrow; peer-on-the-LAN resolution is not verifiable in QEMU user networking because it carries no multicast — that half belongs to the next board boot, from ryzen or a phone, and is the row's close condition. The owner's ask (http://1bit-os.local:13305reachable by a clickable link) is therefore two-thirds proven device-free and one-third a hardware row.Bucket A on the board; it closes on #953's merge, at the same time as #945 (#951) — #953 is stacked on #951 and touches the same file, so #951 merges first.
os/v3/puppy: the firewall drops every mDNS query, so 1bit-os.local is…