this post was submitted on 19 Apr 2024
2 points (100.0% liked)
Linux
5230 readers
172 users here now
A community for everything relating to the linux operating system
Also check out [email protected]
Original icon base courtesy of [email protected] and The GIMP
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Looks like you're on Fedora Silverblue (or other Atomic version). This is happening because the system groups are in /usr/lib/group rather than /etc/group and this causes the issue you're seeing here. You can work around it by getting into a root shell with something like
sudo -i
and then getting the group added to /etc/group with
grep -E '^dialout' /usr/lib/group >> /etc/group
after that, you'll be able to add your user to the group with
usermod -aG dialout pipe
It's like when I run into some issue with how I've set up my system in NixOS and have to explain to a non-Linux user that it isn't Linux that's the issue but how I'm using an especially weird Linux lol
Is that considered a feature for some reason? That seems objectively terrible.
No, it's a side effect of how everything's handled by rpm-ostree currently, and it's on the list of issues to be fixed.
See Here for more info
Why can't we keep system config things in /etc? It's a method that works in unsurprising ways.
Is etc the mutable part? Would you have to do this again to add more users after a reboot?
/etc is writable, so no reboots are required. That said, /etc is treated in a special way and each deployment will have its own /etc, based on the previous one.
So if you make changes to /etc then revert to a previous deployment, your changes will be reverted as well. But if you make changes and upgrade (or do whatever to create a new deployment), your changes will bu preserved.
That's really helpful to understand the caveats, thank you.
Right on the money, that's what I ended up doing. Thanks!