rocker/r-base:4.2.1: addgroup: addgroup with two arguments is an unspecified operation.

[bathyscapher]

Hello everyone,

I just wanted to update rocker/r-base:4.2.0 to rocker/r-base:4.2.1 using the respective Dockerfiles. While the image build process went fine some months ago (July 2022), it now fails with the error addgroup: addgroup with two arguments is an unspecified operation. for both Dockerfiles 4.2.0 and 4.2.1

Sending build context to Docker daemon   7.68kB
Step 1/11 : FROM debian:testing
testing: Pulling from library/debian
Digest: sha256:1259c7959ad6824834c9075c3cbd0dde3977680dd334c58de5b8a06ec121c9a1
Status: Downloaded newer image for debian:testing
 ---> e0fbe927d84b
Step 2/11 : LABEL org.opencontainers.image.licenses="GPL-2.0-or-later"       org.opencontainers.image.source="https://github.com/rocker-org/rocker"       org.opencontainers.image.vendor="Rocker Project"       org.opencontainers.image.authors="Dirk Eddelbuettel <edd@debian.org>"
 ---> Using cache
 ---> 0adb35a86905
Step 3/11 : RUN useradd docker  && mkdir /home/docker   && chown docker:docker /home/docker     && addgroup docker staff
 ---> Running in c6425591592f
addgroup: addgroup with two arguments is an unspecified operation.
The command '/bin/sh -c useradd docker  && mkdir /home/docker   && chown docker:docker /home/docker     && addgroup docker staff' returned a non-zero code: 1

If docker build is run without the line && addgroup docker staff in the Dockerfile, the build process succeeds and the image can be run in containers (and so far without any errors).

The same behaviour appears on

• Debian 11 + Docker 20.10.18, build b40c2f6
• Amazon Linux 2 + Docker 20.10.17, build 100c701
• MacOS 12.6 + Docker 20.10.17, build 100c701

Do you have any idea why this error appears? Thank you! :)

[eddelbuettel]

I think it happened to me within the last week in both an interactive session and a container update; I would suspect that this changed in Debian itself.

edd@rob:~/git/rblpapi(master)$ docker run --rm -ti rocker/r-base bash
root@49af6bc9dc9b:/# addgroup -h
adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
[--firstuid ID] [--lastuid ID] [--gecos GECOS] [--ingroup GROUP | --gid ID]
[--disabled-password] [--disabled-login] [--add-extra-groups] USER
   Add a normal user

adduser --system [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
[--gecos GECOS] [--group | --ingroup GROUP | --gid ID] [--disabled-password]
[--disabled-login] [--add-extra-groups] USER
   Add a system user

adduser --group GROUP
addgroup [--gid=GID] GROUP
   Add a user group

addgroup --system [--gid=GID] GROUP
   Add a system group

adduser USER GROUP
   Add an existing user to an existing group

general options:
  --allow-badname       allow usernames which do not match the
                        NAME_REGEX configuration variable
  -q, --quiet           don't give process information to stdout
  -d, --debug           be more verbose during execution
  -h, --help            usage message
  -v, --version         version number and copyright
  -c FILE, --conf=FILE  use FILE as configuration file

root@49af6bc9dc9b:/# 

So I think we need to change the addgroup docker staff to adduser docker staff as I did here:

https://github.com/rocker-org/rocker/blob/53be7be0a1ab52534162910b4ab48f597d920664/r-base/latest/Dockerfile#L16

I think we are not going to change 'old' Dockerfiles like this for 4.2.1 as they are meant to be frozen. If you want to run it locally, I suggest to make that change locally. As the issue is taken care of the in the newest Rocker container (ie rocker/r-base::latest) I suggest we close this.

[bathyscapher]

Thank you for the quick response! :)

Okay, good and good to know! Sure, changing for the latest is more than fine! I'm just a bit confused now: isn't 4.2.1 identical with latest?

[eddelbuettel]

Yes, and I hesitated updating it but our preference is to (as much as possible) keep these as 'how they were when built' -- plus knowing with get R 4.2.2 on October 31 leads to leaving it as. We have a new 'versioned' one in a few weeks.

(There is another headache as you may have experience with /usrmerge ongoing in Debian. Starting from fresh debian:testing (and that I did too for latest works but apt upgrade of existing, non-prepared for /usrmerge containers, breaks. These happesn are annoying but they usually only happen once every few years for a good enough reason so ...)