Hi,
so the script is calling mysqld_install_cmd_line(), which is calling mysqld with some options

mysqld_install_cmd_line()

{

  "$mysqld_bootstrap" $defaults $defaults_group_suffix "$mysqld_opt" --bootstrap $silent_startup\

  "--basedir=$basedir" "--datadir=$ldata" --log-warnings=0 --enforce-storage-engine="" \

  "--plugin-dir=${plugindir}" \

  $args --max_allowed_packet=8M \

  --net_buffer_length=16K

}

Note that above there is no log_error server option.
Based on log_error server variable if the server is started without --log-error errors should be in stderr.
If there is no name (of a file for this option) logs will be in <hostname.err> in the datadir (since $ldata == datadir in your case in /var/lib/mysql).
So in your case the error logs will be in stderr already you can try to find out does it exist.
Even the server code is saying the same:

 case OPT_LOG_ERROR:

    /*

      "No --log-error" == "write errors to stderr",

      "--log-error without argument" == "write errors to a file".

    */

Note that if you have a config file (see option files that is configuring log_error) it can be invoked from there also.
In debian there is postinst script that is using hardcoded value for logs {{mysql_logdir=/var/log/mysql }}.
I think that correct patch for this case is to write Examine the logs in stderr for more information. - since log_error="" and parsing the arguments is already finished before!
But let's wait on danblack review too.

it generally sounds better to use log-error is stderr immediately since is already quietened already.

dbdeployer seems to cover the init with --no-defaults https://github.com/datacharmer/dbdeployer/blob/6c64381704783784d164adf865ae02ed907c2c09/sandbox/sandbox.go#L812 so I assume this is stderr already, datacharmer do you have an opinion here?

containter usage of mysql_install_db will process stderr in the logs of the container execution so that use is ok.

The last option that I'd rather avoid is to look at the /proc/

/fd/3 (not BSD friendly) symlink during bootstrap to see where its being written to.

As written, going to get tests written first MDEV-24268

dbdeployer uses --no-defaults to prevent the sandboxed server from being
hijacked by existing my.cnf in the recognized paths.
As for the output, mysql_install_db writes regular messages to stdout, and
only errors to stderr.
The error log is defined in the configuration file (my.sandbox.cnf) but
since we use --no-defaults, the output of errors goes to stderr, and it
gets displayed to users if mysql_install_db exits with a non-zero code.

On Tue, Nov 24, 2020 at 6:27 AM Daniel Black (Jira) <jira@mariadb.org>

PR for review https://github.com/MariaDB/server/pull/2363

Note Debian downstream will still need to pass --log-error on their cmd line in the post-install. Maybe its useful if that is kept different to the user default as its packaging related and reading the error log of the previous combined with the current would be less readable.