Bug #52183 Host lookup fails for mysql_install_db on windows
Submitted: 18 Mar 2010 15:27 Modified: 8 Dec 2016 9:14
Reporter: Nirbhay Choubey Email Updates:
Status: Won't fix Impact on me:
Category:MySQL Server: Installing Severity:S3 (Non-critical)
Version:5.1.45 OS:Microsoft Windows
Assigned to: CPU Architecture:Any
Triage: Triaged: D4 (Minor)

[18 Mar 2010 15:27] Nirbhay Choubey
Running 'perl script\mysql_install_db.pl --no-defaults --basedir=.' on windows
from cmd.exe fails with the following error :

FATAL ERROR : Neither host 'xyz' nor 'localhost' could be looked up
with ./bin/resolvip
Please configure the 'hostname' command to return to a correct hostname.

How to repeat:
As described above.

Suggested fix:
The following lines from mysql_install_db looks culprit to me :

# Try to determine the hostname

# Check if hostname is valid
if test "$cross_bootstrap" -eq 0 -a "$in_rpm" -eq 0 -a "$force" -eq 0
  resolved=`$extra_bindir/resolveip $hostname 2>&1`
  if test $? -ne 0
    resolved=`$extra_bindir/resolveip localhost 2>&1`
`/bin/hostname` won't work from cmd.exe
[18 Mar 2010 15:41] Nirbhay Choubey
Occurs for mysql-noinstall packages built for Windows.
[18 Mar 2010 17:25] Valeriy Kravchuk
I am not sure if this script is intended to be executed on Windows at all. Our manual (http://dev.mysql.com/doc/refman/5.1/en/windows-post-installation.html) clearly says:

"It is unnecessary to run the mysql_install_db script that is used on Unix."

You have data subdirectory with initial content of mysql database even in the noinstall package, as far as I remember. Please, check.
[18 Mar 2010 18:03] Nirbhay Choubey
Hi Valeriy,

IMO marking it 'unnecessary' does not rule out the possibility of users
running the script on windows. So, either this issue should be resolved or
documented 'specifically' somewhere.
[18 Mar 2010 18:42] Sveta Smirnova
Thank you for the report.

Verified as described.

Can be new reoccurance of old bug #30759 or bug #35105 or bug #42421
[23 Mar 2010 11:08] Daniel Fischer
The bug is about mysql_install_db.pl, not mysql_install_db which was quoted in the bug report. Therefore it's not about hostname not being available. The perl script uses the perl function hostname(), which is shown to work in the example output ('xyz').

The perl script was explicitly written as a conversion of the sh script so that we can ship something similar on Windows, so it's not a bug that it is included. It was meant to be included in Windows packages.

However, it can never have worked properly. The relevant code is this:

  my $resolveip;

  $resolved = `$resolveip $hostname 2>&1`;

Without any code in between that actually determines what $resolveip should be.

My vote is to deprecate the script entirely, i.e. set this bug to "Won't Fix" and remove the script from MySQL 5.5. It is never necessary to run this script as the initial database files are included in our packages.
[25 Mar 2010 11:06] Marek Goclowski
Hi boys
According to Google problem is almost 10 years old .
Occurs in Windows and Unix.
Yesterday i used two current Windows version - with installer and without installer:


I used two ways of creating data catalogs for noninstall version

1:   perl mysql_install_db.pl --skip-name-resolve --basedir=d:\mysql --datadir=E:\MYSQL_NOINST\data --force --user=root
     Perl installer does not create databases because host problems but create empty catalogs only:

2:   mysqld --console
     created only log files: ib_logfile0, ib_logfile1 and ibdata1 

MSi version solve this problem properly.

You can always copy databases betwen catalogs but it is "shame" solution

As I remember installation instructins were always written by "Guru's" for "Guru's" but not for general public.  

[8 Dec 2016 9:14] Yngve Svendsen
Posted by developer:
This is indeed a real bug, but with the time that has passed, the impact is much diminished: MySQL 5.7 and newer do not use mysql_install_db on any platform, and the main delivery vehicle for MySQL on Windows is the new MySQL Installer for Windows, which does not employ mysql_install_db for any version of MySQL. Weighing that against the risk and effort of fixing this properly, I am closing this as Not feasible to fix.