v0.3.0: Silverblue base — first-boot group assignment (input/audio/video) doesn't persist; user can't access /dev/input or /dev/video0

[Moonwolf711]

Summary

On the Silverblue 42 base used by SecAI_OS v0.3.0, /etc/group is empty by design — groups are defined in /usr/lib/group. Any first-boot setup script that uses groupadd or appends to /etc/group to assign the AI user to input, audio, video etc. silently fails: getent group input returns the right entry from /usr/lib/group, but the AI user never gains the supplementary group, because rpm-ostree-managed /etc/group is the writable layer and your additions disappear on reboot or are not picked up.

Reproduction

Fresh boot, then:

$ getent group input
input:x:104:

$ id moonwolf
uid=1000(moonwolf) gid=1000(moonwolf) groups=1000(moonwolf), ...   # no input group

$ cat /etc/group
# empty

$ cat /usr/lib/group | grep input
input:x:104:

After running whatever first-boot script is supposed to add the AI user to input:

$ id moonwolf
# still no input group  ← user can't read /dev/input/* devices for PTT, hotkeys, etc.

Why it matters

The voice/PTT pipeline (whisper + push-to-talk via /dev/input/event*) can't function without input group membership. Likewise camera-daemon needs video, audio recording needs audio.

Suggested fix

On Silverblue, append to /etc/group and do not rely on it: the canonical Fedora-Silverblue path is to use usermod -aG input,audio,video <user> and let nss-altfiles merge /usr/lib/group. Make sure the setup runs after nss-altfiles is loaded (it is, by default).

Confirm on a fresh install that:

usermod -aG input,audio,video "$AI_USER"

…actually persists. If it doesn't, a /etc/sysusers.d/secai.conf entry with m <user> <group> directives is the correct Silverblue idiom.

My local workaround

Manually appended to /etc/group:

input:x:104:moonwolf
audio:x:63:moonwolf
video:x:39:moonwolf

…then logged out + back in. Works, but is non-idempotent and gets lost on rpm-ostree rebase.

🤖 Generated with claude-flow