Docker run command in README fails to initialize container

[JaiPEG]

Description

The docker run command as stated in the README fails to initialize the container.

Steps to Reproduce

Run the docker run command as stated in the README:

sudo -E docker run -it \
-v /dev:/dev:ro \
-v /lib/modules:/lib/modules:ro \
-v /etc/os-release:/etc/os-release:ro \
-v /var/log:/var/log:ro \
--privileged --net=host --pid=host \
linuxhw/hw-probe -all -upload

Expected Behaviour

The docker container is able to initialize and begin running hw-probe.

Actual Behaviour

The docker run command fails with

docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: chmod /dev/console: read-only file system: unknown

I'm not an expert in docker, but based on this error message, it seems like the docker run command failed to initialize the container itself, before even running the hw-probe program within the image. Furthermore, the docker runtime specifically failed on the step chmod /dev/console because the file system is read-only.

Environment

• Debian 11
• Docker version 28.3.0, build 38b7060

Possible Cause

I suspect the chmod /dev/console step fails because of the option -v /dev:/dev:ro passed to the docker run command, which bind mounts /dev as read-only.

Possible Workaround

There are probably good security reasons to bind mount /dev as read-only, so making it mount as read-write is probably not the solution.

However, it seems that we can get the docker runtime to avoid doing chmod /dev/console if we omit the -t flag. In other words, make docker not allocate a pseudo terminal.

Running the proposed workaround command

sudo -E docker run -i \
-v /dev:/dev:ro \
-v /lib/modules:/lib/modules:ro \
-v /etc/os-release:/etc/os-release:ro \
-v /var/log:/var/log:ro \
--privileged --net=host --pid=host \
linuxhw/hw-probe -all -upload

appears to succeed with the following output

Probe for hardware ... Ok
Reading logs ... Ok
Uploaded to DB, Thank you!

Probe URL: <REDACTED>

Closing

Note that this is my first time running hw-probe, and I have only successfully run it with docker, using the workaround described above, so I'm not fully aware of what the intended output is supposed to look like, but it seems like the proposed workaround succeeded.

If this issue is reproducible, and the proposed workaround sounds like a good solution, I'm happy to submit a PR for it.

Happy to answer any questions if something isn't clear.