[MDEV-13976] Windows msi installer fails at starting service - version 10.1.28 Created: 2017-10-01  Updated: 2017-12-19  Resolved: 2017-12-19

Status: Closed
Project: MariaDB Server
Component/s: Packaging, Platform Windows
Affects Version/s: 10.1.28
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Wilbur Union Assignee: Vladislav Vaintroub
Resolution: Cannot Reproduce Votes: 0
Labels: need_feedback
Environment:

Windows 32 bit


Attachments: Text File logfile.txt     Text File logfile_2.txt     Text File mariadb_win_event_log.txt     Text File mariadb_win_event_log_2.txt    
Sprint: 10.1.30

 Description   

MSI installer fails at starting service and rolls back - says not enough privileges - run as administrator. Manual port creation did not work either.



 Comments   
Comment by Elena Stepanova [ 2017-10-01 ]

Given that 10.0.28 was released almost a year ago, you must have had it for a while. Has it only started failing now?

Comment by Wilbur Union [ 2017-10-01 ]

My error on the drop down it affects 10.1.28 - the latest msi version

Comment by Elena Stepanova [ 2017-10-01 ]

Was it not the case with previous versions, didn't they require the user to have admin rights?
Which version of Windows is it, apart from it being 32-bit?

Comment by Wilbur Union [ 2017-10-01 ]

I have admin rights - ran it both ways from a cmd prompt ran as administrator as well as logged in as administrator It is Windows 7

Comment by Vladislav Vaintroub [ 2017-10-01 ]

Can you please attach verbose installation logs, as per information here
https://mariadb.com/kb/en/library/installing-mariadb-msi-packages-on-windows/#installation-logs ?

Comment by Wilbur Union [ 2017-10-01 ]

I moved it to the root directory and ran it from there - no change - HOWEVER - in the logfile.txt I see problems

Here is one

MSI (c) (60:EC) [16:05:11:331]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'F:\'.

The first partition on the hard drive is an ext2 partition which was for MacOSX - and Windows has always seen it as "F:"

I see that "F:" reference at several places - I do not know the meaning of the rest of the logfile

logfile.txt

Comment by Vladislav Vaintroub [ 2017-10-02 ]

Thanks. According to the MSI log, the error is that the service does not start, up to this point everything (bootstrapping, copying) was fine. So I guess MSI is not to blame, but there is something on the box that prevents running mysqld (whether as service, or not).

We can figure out from Windows event log entries for MySQL.

Can you please run the below command (in elevated command prompt), and attach the resulting log file? Thank you!

wevtutil qe Application /q:"*[System[Provider[@Name='MySQL']]]"  /f:text /rd:true /c:1000 > mariadb_win_event_log.txt

Comment by Wilbur Union [ 2017-10-02 ]

Here is the output from the command you sent
mariadb_win_event_log.txt

Comment by Vladislav Vaintroub [ 2017-10-02 ]

thanks! unfortunately thats not much readable output on Win7. On my Windows 2012 , description is a readable text, rather than N/A, which makes reconstruction of error log easy

Well, if that does not work, since we do not suspect MSI anymore, you can maybe install without DatabaseInstance (you can deselect this feature from the MSI tree)
Then you can try to manually install database service (all following commands from elevated command prompt)

e.g

mysql_install_db.exe --datadir=C:\db --service=MySQL --password=secret

mysql_install_db.exe is installed by default into C:\Program Files\MariaDB 10.1\bin

and start service with

net start MySQL

starting service should fail, but at least we'll have a error log in data directory (if you type command above this would be a file with .err extension on C:\db), which will allow us to at have a better idea of what happened.

More into on mysql_install_db.exe https://mariadb.com/kb/en/library/mysql_install_dbexe/

Comment by Wilbur Union [ 2017-10-04 ]

I reinstalled the msi from an elevated commend program and "unchecked" CREATE SERVICE and NETWORKING radio buttons - it apparently created a port on 3306 for mariadb anyway.

So I added the port manually to the firewall TCP - 3306

This is the ini it created in the datadir along with the "test" and "mysql" databases

[mysqld]
datadir=D:/Program Files/MariaDB 10.1/data
skip-networking
enable-named-pipe
port=3306
sql_mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
default_storage_engine=innodb
innodb_buffer_pool_size=383M
innodb_log_file_size=50M
character-set-server=utf8
[client]
protocol=pipe
plugin-dir=D:/Program Files/MariaDB 10.1/lib/plugin

I have attached the msi logfile

logfile_2.txt

I then ran the command to create the service

D:\Program Files\MariaDB 10.1\bin>mysql_install_db.exe --datadir=D:/Program File
s/MariaDB 10.1/data --service=MySQL
Running bootstrap
2017-10-04 10:01:56 2312 [Note] D:\Program Files\MariaDB 10.1\bin\mysqld.exe (mysqld 10.1.28-MariaDB) starting as process 4760 ...
Removing default user
Creating my.ini file
Registering service 'MySQL'
Creation of the database was successfull

So I ran the net start command - as the above created the MySQL service and it shows in the Services admin tools of windows - but it resulted in

D:\Program Files\MariaDB 10.1\bin>net start MySQL
The MySQL service is starting...
The MySQL service could not be started.

A system error has occurred.

System error 1067 has occurred.

The process terminated unexpectedly.

HOWEVER there is no *.err log in the datadir

I have attached mariadb_win_event_log_2.txt run after I attempted to start the MySQL service

I would also point out I need innodb_file_per_table = 1 if this is to be of any use to recovering my data

I still cannot see how this will ever work with thr install showing any pointer to the "F:" drive which is ext2

Comment by Vladislav Vaintroub [ 2017-10-04 ]

Ok, in your case, to analyze the failure, we do not necessarily need .err log in datadir, and you do not need service.
Could you please do this in elevated command prompt

D:
cd D:\Program Files\MariaDB 10.1\bin
mysqld --console

And please attach whatever it writes to the stderr to this bug report.

Comment by Wilbur Union [ 2017-10-04 ]

this is output of trying to run the console . . . it stopped with NO console prompt and I did a ctrl c shut it down

I had added innodb_file_per_table = 1 to the my.ini

D:\Program Files\MariaDB 10.1\bin>mysqld --console
2017-10-04 11:52:36 6820 [Note] mysqld (mysqld 10.1.28-MariaDB) starting as proc
ess 6560 ...
2017-10-04 11:52:36 6820 [Note] InnoDB: Using mutexes to ref count buffer pool p
ages
2017-10-04 11:52:36 6820 [Note] InnoDB: The InnoDB memory heap is disabled
2017-10-04 11:52:36 6820 [Note] InnoDB: Mutexes and rw_locks use Windows interlo
cked functions
2017-10-04 11:52:36 6820 [Note] InnoDB: _mm_lfence() and _mm_sfence() are used f
or memory barrier
2017-10-04 11:52:36 6820 [Note] InnoDB: Compressed tables use zlib 1.2.3
2017-10-04 11:52:36 6820 [Note] InnoDB: Using generic crc32 instructions
2017-10-04 11:52:36 6820 [Note] InnoDB: Initializing buffer pool, size = 383.0M
2017-10-04 11:52:36 6820 [Note] InnoDB: Completed initialization of buffer pool
2017-10-04 11:52:36 6820 [Note] InnoDB: Setting log file .\ib_logfile101 size to
50 MB
2017-10-04 11:52:36 6820 [Note] InnoDB: Setting log file .\ib_logfile1 size to 5
0 MB
2017-10-04 11:52:36 6820 [Note] InnoDB: Renaming log file .\ib_logfile101 to .\i
b_logfile0
2017-10-04 11:52:36 6820 [Warning] InnoDB: New log files created, LSN=1616697
2017-10-04 11:52:36 6820 [Note] InnoDB: Highest supported file format is Barracu
da.
2017-10-04 11:52:36 6820 [Note] InnoDB: 128 rollback segment(s) are active.
2017-10-04 11:52:36 6820 [Note] InnoDB: Waiting for purge to start
2017-10-04 11:52:36 6820 [Note] InnoDB: Percona XtraDB (http://www.percona.com)
5.6.36-82.2 started; log sequence number 1616908
2017-10-04 11:52:37 7140 [Note] InnoDB: Dumping buffer pool(s) not yet started
2017-10-04 11:52:37 6820 [Note] Plugin 'FEEDBACK' is disabled.
2017-10-04 11:52:37 6820 [Note] mysqld: ready for connections.
Version: '10.1.28-MariaDB' socket: '' port: 0 mariadb.org binary distribution

2017-10-04 11:53:02 8144 [Note] mysqld: Normal shutdown

2017-10-04 11:53:03 8144 [Note] Event Scheduler: Purging the queue. 0 events
2017-10-04 11:53:03 4688 [Note] InnoDB: FTS optimize thread exiting.
2017-10-04 11:53:03 8144 [Note] InnoDB: Starting shutdown...
2017-10-04 11:53:04 8144 [Note] InnoDB: Waiting for page_cleaner to finish flush
ing of buffer pool
2017-10-04 11:53:05 8144 [Note] InnoDB: Shutdown completed; log sequence number
1616918
2017-10-04 11:53:05 8144 [Note] mysqld: Shutdown complete

D:\Program Files\MariaDB 10.1\bin>

Comment by Vladislav Vaintroub [ 2017-10-04 ]

Ok, the server starts if user is you, but does not start if user is NetworkService, which is the usual service use after installation.
I do not have a good idea of why would that happen. Perhaps, you can look once again in the datadirectory for the file named RoyUnion-PC.err (be warned that Windows explorer may hide the .err extension).

For a quick workaround, you may want to try changing the service config so under your user credential, or under LocalService, or under LocalSystem credentials.

Comment by Vladislav Vaintroub [ 2017-10-04 ]

Also, you do not need file-per-table=1. It is so by default

Comment by Wilbur Union [ 2017-10-04 ]

Service started when log on change to "Local System" - still no *.err file and "Hide extensions for known file types" is "unchecked" - all other file types show

I will see if I can get PhpMyAdmin installed and working now

Comment by Vladislav Vaintroub [ 2017-10-04 ]

ok, but take care as right now mysqld is not using the TCP port but pipe instead. I do not know if PhpAdmin copes with that

Comment by Vladislav Vaintroub [ 2017-12-18 ]

Anything new here?
the missing .err is really something strange. However maybe there is one of C:\Windows\my.ini C:\Windows\my.cnf C:\my.ini C:\my.cnf, which log-error in them? We do not create anything like this , but it is still read because of backwards compatiblity.

Comment by Wilbur Union [ 2017-12-18 ]

As i said earlier somewhere - there was a ext2 partition at the beginning of the drive - which the installer appears saw as the root drive - which was drive "F", and that likely caused all the issues.

I gave up on the Windows install and worked on the Centos 7 server directly upgrading to 10.2.9

Comment by Wilbur Union [ 2017-12-19 ]

As I said - the ext2 partition likely caused it and I have since also deleted and then shunk that frees pace of that partition out of existence with eaus partition manager - I once has a triple boot setup for for win 7, xp, and the osx

Comment by Vladislav Vaintroub [ 2017-12-19 ]

Not sure this F: has to do with anything. Looks installation was attempted into usual place C:\Program Files\MariaDB 10.1\data .
Anyway, I'll to close this mysterious bug for now, please feel free to reopen if something similar comes in the future.

Generated at Thu Feb 08 08:09:51 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.