Devuan bug report logs - #548
eudev: postinst fails when kvm group present

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Package: eudev
Version: 3.2.9-8~beowulf1
Severity: normal

Dear Maintainer,

I just upgraded a number of packages on a machine where I had
manually added a `kvm` group.  This caused the postinst script
to fail with

  The group `kvm' already exists and is not a system group. Exiting.

leaving `eudev` unconfigured.

I don't know if the `kvm` *must* be a system group but things 
have been working fine for me with a non-system group.  As long as
a non-system `kvm` group exists, configuring `eudev` will fail.
This is easily confirmed with

  $ sudo dpkg-reconfigure eudev
  The group `kvm' already exists and is not a system group. Exiting.

Changing the group to a system group fixes this behaviour.

I worked around the issue by appending `|| true` in the postscript
to the `adduser` command that tries to create the system group.

If the `kvm` group does not have to be a system group, I would expect
configuration to succeed if a non-system `kvm` group is present.

-- Package-specific info:

-- System Information:
Architecture: x86_64

Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages eudev depends on:
ii  adduser      3.118
ii  debconf      1.5.71
ii  libblkid1    2.33.1-0.1+devuan1~beowulf2
ii  libc6        2.28-10
ii  libeudev1    3.2.9-8~beowulf1
ii  libkmod2     26-1
ii  libselinux1  2.8-1+b1
ii  lsb-base     10.2019051400
ii  procps       2:3.3.15-2+devuan1
ii  util-linux   2.33.1-0.1+devuan1~beowulf2

eudev recommends no packages.

eudev suggests no packages.

-- no debconf information

[udev-database.txt (text/plain, attachment)]

Message #10 received at 548@bugs.devuan.org (full text, mbox, reply):

severity 548 important
thanks


Meeuwissen Olaf wrote:
> I just upgraded a number of packages on a machine where I had
> manually added a `kvm` group.  This caused the postinst script
> to fail with
>
>   The group `kvm' already exists and is not a system group. Exiting.
>
> leaving `eudev` unconfigured.

I noticed this on Sunday and also investigated.  And then today
another user DeepDive on #devuan IRC reported the same problem.
Therefore I am raising the severity to important due to the effect
this has for many users.

> I don't know if the `kvm` *must* be a system group but things
> have been working fine for me with a non-system group.  As long as
> a non-system `kvm` group exists, configuring `eudev` will fail.
> This is easily confirmed with
>
>   $ sudo dpkg-reconfigure eudev
>   The group `kvm' already exists and is not a system group. Exiting.
>
> Changing the group to a system group fixes this behaviour.
>
> I worked around the issue by appending `|| true` in the postscript
> to the `adduser` command that tries to create the system group.
>
> If the `kvm` group does not have to be a system group, I would expect
> configuration to succeed if a non-system `kvm` group is present.

But the code used in the postinst is problematic.  The code is this.
(I know the web version does not show indentation.  Imagine the code
being indented.  Check the original files.)

    #!/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 addgroup
returns a non-zero exit code then due to the set -e the configure
fails and the package is left unconfigured.

It is true that the addgroup would return 0 (success) if it would not
need to do the action.  But if the user has already locally configured
an account user or group then that previously existing configuration
should be maintained.

Therefore group addition should not be unconditional.  It should be
conditional upon the group not already existing.  I present two
alternative examples from existing packages that handle this in two
different ways.

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

Again for the web display please imagine the above having indentation.

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 #20 received at 548@bugs.devuan.org (full text, mbox, reply):

Bob Proulx writes:

> Meeuwissen Olaf wrote:
>> I just upgraded a number of packages on a machine where I had
>> manually added a `kvm` group.  This caused the postinst script
>> to fail with
>>
>>   The group `kvm' already exists and is not a system group. Exiting.
>>
>> leaving `eudev` unconfigured.
>
> I noticed this on Sunday and also investigated.  And then today
> another user DeepDive on #devuan IRC reported the same problem.
> Therefore I am raising the severity to important due to the effect
> this has for many users.

Thanks.  I was wondering whether to do so on the initial report.

>> I don't know if the `kvm` *must* be a system group but things
>> have been working fine for me with a non-system group.  As long as
>> a non-system `kvm` group exists, configuring `eudev` will fail.
>> This is easily confirmed with
>>
>>   $ sudo dpkg-reconfigure eudev
>>   The group `kvm' already exists and is not a system group. Exiting.
>>
>> Changing the group to a system group fixes this behaviour.
>>
>> I worked around the issue by appending `|| true` in the postscript
>> to the `adduser` command that tries to create the system group.
>>
>> If the `kvm` group does not have to be a system group, I would expect
>> configuration to succeed if a non-system `kvm` group is present.
>
> But the code used in the postinst is problematic.  The code is this.
> (I know the web version does not show indentation.  Imagine the code
> being indented.  Check the original files.)
>
>     #!/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 addgroup
> returns a non-zero exit code then due to the set -e the configure
> fails and the package is left unconfigured.
>
> It is true that the addgroup would return 0 (success) if it would not
> need to do the action.  But if the user has already locally configured
> an account user or group then that previously existing configuration
> should be maintained.
>
> Therefore group addition should not be unconditional.  It should be
> conditional upon the group not already existing.  I present two
> alternative examples from existing packages that handle this in two
> different ways.
>
> 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
>
> Again for the web display please imagine the above having indentation.
>
> 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.

I would also go the libvirt-daemon-system way.  It more clearly states
what is going on.

> 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! :-)

And thank you for actually suggesting a fix!

Hope this helps,
--
Olaf Meeuwissen, LPIC-2       FLOSS Engineer -- EPSON AVASYS CORPORATION
       Free Software Foundation Associate Member since 2004-01-27
    Support Free Software                  https://my.fsf.org/donate
    Join the Free Software Foundation        https://my.fsf.org/join

Message #25 received at 548@bugs.devuan.org (full text, mbox, reply):

Hello,

When reconfiguring or reinstalling eudev-3.2.9-8~beowulf1 I don't have any
problem with the groups input, kvm and render being present already:
as root: dpkg-reconfigure eudev
[ ok ] Stopping hot-plug events dispatcher: udevd.
[ ok ] Starting hot-plug events dispatcher: udevd.

*******************************************************
  Warning: eudev will default to the older network
  interface names, such as eth0 or wlan0. If you use
  the new names, such as enp0s3, you will need to add
  the following to the boot command:
                net.ifnames=1
********************************************************
		
update-initramfs: deferring update (trigger activated)
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-14-amd64

No failure here from eudev.postinst. Please help me find a way to reproduce this
bug. Is the usage of sudo the problem?

Thanks!

Message #30 received at 548@bugs.devuan.org (full text, mbox, reply):

You'll need to make sure the kvm group has a gid > 1000.

E.g. edit /etc/group and change the kvm line from say 106 to 10666, then

# apt-get install --reinstall eudev

fails with:
----
The group `kvm' already exists and is not a system group. Exiting.
dpkg: error processing package eudev (--configure):
 installed eudev package post-installation script subprocess returned error exit status 1
Processing triggers for man-db (2.8.5-2) ...
Errors were encountered while processing:
 eudev
E: Sub-process /usr/bin/dpkg returned an error code (1)
----

Message #35 received at 548@bugs.devuan.org (full text, mbox, reply):

On Sun, 2021-02-21 at 23:00 +1100, Ralph Ronnquist wrote:
> You'll need to make sure the kvm group has a gid > 1000.
> 
> E.g. edit /etc/group and change the kvm line from say 106 to 10666,
> then
> 
> # apt-get install --reinstall eudev
> 
> fails with:
> ----
> The group `kvm' already exists and is not a system group. Exiting.
> dpkg: error processing package eudev (--configure):
>  installed eudev package post-installation script subprocess returned
> error exit status 1
> Processing triggers for man-db (2.8.5-2) ...
> Errors were encountered while processing:
>  eudev
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Problem is if non-system groups: input, kvm and render should be
allowed or not. The whole idea of system group names is that these
names should be reserved?? WDYT?

Message #40 received at 548@bugs.devuan.org (full text, mbox, reply):

Hi,

Svante Signell writes:

> On Sun, 2021-02-21 at 23:00 +1100, Ralph Ronnquist wrote:
>> You'll need to make sure the kvm group has a gid > 1000.

Mostly correct.  My original report mentioned I had a regular group as
opposed to a system group.  The exact ranges for these are customizable
but the defaults are such that regular groups get 1000-60000.
BTW, the defaults are in /etc/login.defs.  You're looking for GID_MIN
and GID_MAX.  The system group values, SYS_GID_MIN and SYS_GID_MAX are
mentioned in comments.

>> E.g. edit /etc/group and change the kvm line from say 106 to 10666,
>> then
>>
>> # apt-get install --reinstall eudev
>>
>> fails with:
>> ----
>> The group `kvm' already exists and is not a system group. Exiting.
>> dpkg: error processing package eudev (--configure):
>>  installed eudev package post-installation script subprocess returned
>> error exit status 1
>> Processing triggers for man-db (2.8.5-2) ...
>> Errors were encountered while processing:
>>  eudev
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> Problem is if non-system groups: input, kvm and render should be
> allowed or not. The whole idea of system group names is that these
> names should be reserved?? WDYT?

I also mentioned this possibility, that kvm might have to be a system
group, in my original issue but could not find any definitive list of
system groups in Debian Policy and didn't look elsewhere.

If these groups must be system groups, then I think the right thing to
do is to log the discrepancy, change the group's ID *and* reassign the
group for all file system entries that have the old ID.

For the time being, I am still using my regular kvm group, i.e. with a
GID > 1000.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join

Message #45 received at 548-done@bugs.devuan.org (full text, mbox, reply):

Version: 3.2.9-9

Source package eudev (3.2.9-9) added to Devuan suite unstable.

This closes bug report 548.

Thanks

DAK managing the Devuan archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Fri, 26 Feb 2021 13:49:24 +0100
Source: eudev
Architecture: source
Version: 3.2.9-9
Distribution: unstable
Urgency: medium
Maintainer: Devuan Dev Team <devuan-dev@lists.dyne.org>
Changed-By: Svante Signell <svante.signell@gmail.com>
Closes: 527 538 548
Changes:
 eudev (3.2.9-9) unstable; urgency=medium
 .
   * debian/rules: Add --bindir=/bin to CONFFLAGS to fix path in 64-btrfs.rules.
     Problem found upstream: https://bugs.gentoo.org/739268 (Closes: #527, #538)
   * debian/eudev.postinst: Fix postinst when input, kvm or render groups, with
     gid >= 1000 are present. Solution proposed by Bob Proulx <bob@proulx.com>
     (Closes: #548)
Checksums-Sha1:
 e390dd847746a1d010e72b83b784ad383ae54e2a 2345 eudev_3.2.9-9.dsc
 fd2e0f54064a9f057016246749054007ab52fa0a 62368 eudev_3.2.9-9.debian.tar.xz
 e7cb1a0ec0259c408de7dd9c7462090277f66a86 5154 eudev_3.2.9-9_source.buildinfo
Checksums-Sha256:
 fe8b82f8727eea2e65ac3ab296a1971c5544380dc17064b21b0d3eea2d7a9b98 2345 eudev_3.2.9-9.dsc
 69a0b9b8187f061fbc3b4365a294f2c9a8676fbeba35b1a2b7cbae827a8f7191 62368 eudev_3.2.9-9.debian.tar.xz
 13b4a65fb342fa91c9da0c0dac342e5c556bb69b8a199232b856883b48e4aedd 5154 eudev_3.2.9-9_source.buildinfo
Files:
 253dcad1ff87a0862224435eb81ef6fc 2345 admin optional eudev_3.2.9-9.dsc
 665699c5a11e75f67223f9e13e9bcf46 62368 admin optional eudev_3.2.9-9.debian.tar.xz
 900fc1146f86b024c22cfcce7f8f189c 5154 admin optional eudev_3.2.9-9_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEcuPLdzMV36LkZHQ9lFMhJFQZIvsFAmA720EACgkQlFMhJFQZ
IvuKPwf/dQl9prglyLhz/uBvMpfKV4XAfwFCfERl0Hbb2uEUeCGLe5sp/PoN1oiy
IVkrD9UcSD24U8mjneE7vps/Y1K2M5k1HsGPrhuey+us5MY/CvQCBC6jVOACEkE6
H2+h8FSb/qqapVpNVukY17PoqXayQ8ypQlfcTvH2UOXtdNPAwFfjwO/gKOCZ0IOa
EsPJ7Hrrsx1SRpiIkiMXiluz4B18XXT0+mT/GoWz9qcgOsZQxxD89MA1hKLN5VaA
N20kt2XP7SgLv6EJcqE1CyGJLoAGRxL/gZmkByNd5a07EfNnBllAPoxK/GmjUAZ9
RFPPjvnm4qV+7L8kHPKLYNfx/4Vefw==
=Ce4O
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.