Devuan bug report logs -
#550
Unconditional addgroup kvm trouble
Reported by: Bob Proulx <bob@proulx.com>
Date: Wed, 17 Feb 2021 21:03:02 UTC
Severity: normal
Found in version 3.2.9-8~beowulf1
Done: Bob Proulx <bob@proulx.com>
Full log
🔗
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Wed, 17 Feb 2021 14:53:18 -0700
with message-id <20210217145011741276571@bob.proulx.com>
and subject line Re: bug#550: Unconditional addgroup kvm trouble
has caused the Devuan bug report #550,
regarding Unconditional addgroup kvm trouble
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.devuan.org
immediately.)
--
550: https://bugs.devuan.org/cgi/bugreport.cgi?bug=550
Devuan Bug Tracking System
Contact owner@bugs.devuan.org with problems
[Message part 2 (message/rfc822, inline)]
Package: eudev
Version: 3.2.9-8~beowulf1
The recent eudev 3.2.9-8~beowulf1 arrive on my systems and I noticed
that it configured two new groups "kvm" and "renderer". Which is
okay. And I note that libvirt-daemon-system also creates "kvm".
But the code used in the postinst is problematic. The code is this.
#!/bin/sh
set -e
...
case "$1" in
configure)
...
# Add new system group used by udev rules
addgroup --quiet --system input
# Make /dev/kvm accessible to kvm group
addgroup --quiet --system kvm
# Make /dev/dri/renderD* accessible to render group
addgroup --quiet --system render
Those are unconditional additions. Which means that if the group
already exists then there is an error. And due to the set -e this
error prevents installation. Problem reported by user DeepDive on
the #devuan IRC channel.
The group addition should not be unconditional. It should be
conditional upon the group not already existing. I present two
alternative examples.
The first from postfix. The "try it and see" method.
cd ${CHROOT}
# make sure that the postfix user exists. Simplest portable way to check is to
# chown something, so we'll create the directories that we need here.
makedir private root:root 700
chgrp postfix private 2>/dev/null ||
addgroup --system postfix
chown postfix private 2>/dev/null ||
adduser --system --home ${CHROOT} --no-create-home --disabled-password --ingroup postfix postfix
The second from libvirt-daemon-system. The "check it and see" method.
if ! getent group libvirt >/dev/null; then
addgroup --quiet --system libvirt
fi
if ! getent group kvm >/dev/null; then
addgroup --quiet --system kvm
fi
And so either way seems good and acceptable. I would probably do the
same thing libvirt-daemon-system is doing as that is simple enough.
Here is a suggested fix for this.
# Add new system group used by udev rules
if ! getent group input >/dev/null; then
addgroup --quiet --system input
fi
# Make /dev/kvm accessible to kvm group
if ! getent group kvm >/dev/null; then
addgroup --quiet --system kvm
fi
# Make /dev/dri/renderD* accessible to render group
if ! getent group render >/dev/null; then
addgroup --quiet --system render
fi
Thank you for maintaining eudev in Devuan! :-)
Bob
[Message part 3 (message/rfc822, inline)]
I just now discovered Bug#548 https://bugs.devuan.org/548 which I did
not originally see. I haven't ever really liked how the BTS handles
merges. Therefore I am simply going to close my report now with this
message and then add additional information to the original report.
That's simplest all around for everyone. :-)
Bob
Send a report that this bug log contains spam.