Resolve boot-time warnings

There are various warnings and errors in the journal, which don't need to block #8, but which we should consider before releasing EOS7.

This is a list created mostly by scanning the output of journalctl as of 2025-09-22.

Definition of done for this issue would be:

• For each issue above, either confirm it as fixed, or document why it doesn't need to be fixed.
• Re-check journalctl to see if any new boot-time warnings were added since I did the initial writeup, and fix / wontfix those too.

List of warnings and errors:

1. cupsd complains about 'nobody' user:

    /usr/lib/systemd/sysetm/cups-lpd@.service:8: Special user nobody configured, this is not safe!
   

   This issue occurs in GNOME OS too, as of IMAGE=nightly.901821. Probably harmless.

2. kernel fails to load /usr/lib/firmware/regulatory.db during initramfs:

    kernel: cfg80211: Loading compiled-in X.509 certificates for regulatory database
    kernel: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
    kernel: Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
    kernel: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
    kernel: cfg80211: failed to load regulatory.db
   

   Harmless since the initramfs doesn't need to connect to WiFi anyway.

3. zram setup fails.

   This was resolved as part of Fixes for live ISO images #194.

4. BFQ scheduling can't be enabled.

   This was resolved by Custom kernel based on Ubuntu #10. There are still warnings from the custom udev rule in 50-disk-bfq.rules, as it tries to enable BFQ scheduling not just for hard disks but also for loopback devices and the zram device, where it can't be used.

5. Multiple mDNS responders running.

   GNOME OS ships Avahi and systemd-resolved, both of which have mDNS responders. As of IMAGE=nightly.901821 there are warnings from avahi-daemon.service about this:

    *** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
   

   EOS7 also ships both, and has warnings from systemd-resolved:

    mDNS-IPv4: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding transfers.
   

   Needs resolving upstream. Mostly harmless but needs fixing.

6. colord fails on boot

   Resolved by Update colord to 1.4.8 #197

7. Warnings from systemd-tmpfiles

   Multiple issues:

    Failed to parse ACL "d:group::r-x,d:group:adm:r-x,d:group:wheel:r-x,group::r-x,group:adm:r-x,group:wheel:r-x", ignoring: Invalid argument
    Failed to parse ACL "d:group:adm:r-x,d:group:wheel:r-x,group:adm:r-X,group:wheel:r-X", ignoring: Invalid argument
    Failed to parse ACL "d:group::r-x,d:group:adm:r-x,d:group:wheel:r-x,group::r-x,group:adm:r-x,group:wheel:r-x", ignoring: Invalid argument
    Failed to parse ACL "d:group:adm:r-x,d:group:wheel:r-x,group:adm:r-x,group:wheel:r-x", ignoring: Invalid argument
    Failed to parse ACL "group:adm:r--,group:wheel:r--", ignoring: Invalid argument
    "/home" already exists and is not a directory.
    Failed to create directory or subvolume "/srv": Operation not permitted
    "/root" already exists and is not a directory.
   

   The "Failed to parse ACL" warnings happen also in GNOME OS, and should be fixed there.

   The warnings about /home and /srv and /root are likely because we need config changes for our unique OSTree filesystem layout.

8. var.mount service warns that /var/ is not empty. This warning happens in EOS6 as well.

   This also triggers a warning from ostree admin deploy about /var not being empty. Perhaps we just need to ensure /var is empty before we commit the ostree in eos/repo.bst -- Clean up /var in the filesystem tree #55

For #4 I expect the module is missing in the kernel config. I saw this in the output of bst artifact log eos/initramfs.bst:

dracut-install: Failed to find module 'bfq'
dracut[E]: FAILED:  /usr/lib/dracut/dracut-install -D /var/tmp/dracut.doP5Y88/initramfs -N ^nouveau$|^simpledrm$ --kerneldir /usr/lib/modules/6.15.1 -m bfq

Should be resolved with #10

For 3, I discovered that zram setup is handled in GNOME OS via https://github.com/systemd/zram-generator. This works already in eos7: see systemctl status systemd-zram-setup@zram0.service.

Opened endlessm/eos-boot-helper#426 to remove the custom service in eos-boot-helper.