Bug 1126252 - Installer fails on Windows 7
Summary: Installer fails on Windows 7
Keywords:
Status: ASSIGNED
Alias: None
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: Installer
Version: 6.0.0 GA
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 6.1.0
Assignee: Miroslav Sochurek
QA Contact: Len DiMaggio
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-04 01:27 UTC by Jason Shepherd
Modified: 2019-02-22 22:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
installation log when attempting to update 127.0.0.1 to localhost part way through install (2.00 KB, text/plain)
2014-08-05 07:16 UTC, Jason Shepherd
no flags Details
Loopback test (2.21 KB, application/octet-stream)
2014-08-05 16:20 UTC, Miles Tjandrawidjaja
no flags Details
Installation Logs from various attempts by customer to run the installer (25.57 KB, application/gzip)
2014-08-06 05:27 UTC, Jason Shepherd
no flags Details

Description Jason Shepherd 2014-08-04 01:27:49 UTC
Description of problem:


When trying to install on Windows 7, the installation fails and we get this error message, 'database schema creation failed - see sqlresults.log'.


How reproducible:

Run the installer on Windows 7, 32bit arch.

Comment 1 Jason Shepherd 2014-08-05 07:16:17 UTC
We tried changing all the 127.0.0.1 entries in standalone*.xml to 'localhost' but the installation still failed with the 'database schema creation failed' message.

Attached in the installation log from that attempt.

Comment 2 Jason Shepherd 2014-08-05 07:16:59 UTC
Created attachment 924112 [details]
installation log when attempting to update 127.0.0.1 to localhost part way through install

Comment 3 Jason Shepherd 2014-08-05 07:19:13 UTC
If you look at that Installation log, the connect to localhost only fails on the first attempt. Subsequent attempts to connect with the CLI work OK.

Comment 4 Jason Shepherd 2014-08-05 07:35:56 UTC
I can't recreate this locally, but I was using the default database. I asked the customer to try this as well, and report back.

Comment 5 Thomas Hauser 2014-08-05 14:11:54 UTC
Hey Jason,

The attachment you've added seems to be the output of some kind of port / ip tracing software, can you upload the log please?

Also I've changed the BZ "Version" to 6.0.0.GA (because this is the version with the problem) and the "Target Release" to 6.1.0, because this is where the fix will go.

Comment 6 Miles Tjandrawidjaja 2014-08-05 16:20:14 UTC
Created attachment 924258 [details]
Loopback test

Hello,

I also cannot create this situation locally. I tested with MSSQL.
It is possible that a packet filter/firewall is causes the issues stated above.
You may want to turn of any firewalls to see if this is the problem.

Attached is a java class to query the machines loopback address and localhost.
Download the file and run "java LoopBack".
Ensure that you do not receive any exceptions.
Below is the output I received, it indicates that my loopback and localhost connections are indeed a loopback address.
"""
[Loopback] InetAddress = localhost/127.0.0.1
[Loopback] InetAddress.isAnyLocalAddress = false
[Loopback] InetAddress.isLinkLocalAddress = false
[Loopback] InetAddress.isLoopbackAddress = true
[Loopback] InetSocketAddress = localhost/127.0.0.1:8080
[Loopback] InetSocketAddress.isUnresolved = false
[LocalHost] InetAddress = John-PC/10.0.2.15
[LocalHost] InetAddress.isAnyLocalAddress = false
[LocalHost] InetAddress.isLinkLocalAddress = false
[LocalHost] InetAddress.isLoopbackAddress = false
[LocalHost] InetSocketAddress = John-PC/10.0.2.15:8080
[LocalHost] InetSocketAddress.isUnresolved = false
[0.0.0.0] InetAddress = /0.0.0.0
[0.0.0.0] InetAddress.isAnyLocalAddress = true
[0.0.0.0] InetAddress.isLinkLocalAddress = false
[0.0.0.0] InetAddress.isLoopbackAddress = false
[0.0.0.0] InetSocketAddress = /0.0.0.0:8080
[0.0.0.0] InetSocketAddress.isUnresolved = false
"""

Comment 7 Jason Shepherd 2014-08-06 05:24:27 UTC
Comment on attachment 924112 [details]
installation log when attempting to update 127.0.0.1 to localhost part way through install

I uploaded the output of netstat instead of the log.

Comment 8 Jason Shepherd 2014-08-06 05:27:05 UTC
Created attachment 924352 [details]
Installation Logs from various attempts by customer to run the installer

InstallationLog.txt.localhostChange is the log which we attempted to change standalone*.xml from 127.0.0.1 to localhost during the installation process.

Comment 9 Jason Shepherd 2014-08-07 07:41:03 UTC
Got some more updates from the customer, they will send more details of how to setup the static IP in Windows 7.

They claim that this issue only happens on workstations which are configured with a static IP address. 

They ran the java LoopBack program you offered, and the output looks as expected:

[Loopback] InetAddress = localhost/127.0.0.1
[Loopback] InetAddress.isAnyLocalAddress = false
[Loopback] InetAddress.isLinkLocalAddress = false
[Loopback] InetAddress.isLoopbackAddress = true
[Loopback] InetSocketAddress = localhost/127.0.0.1:8080
[Loopback] InetSocketAddress.isUnresolved = false
[LocalHost] InetAddress = AUD113047D/10.10.10.10
[LocalHost] InetAddress.isAnyLocalAddress = false
[LocalHost] InetAddress.isLinkLocalAddress = false
[LocalHost] InetAddress.isLoopbackAddress = false
[LocalHost] InetSocketAddress = AUD113047D/10.10.10.10:8080
[LocalHost] InetSocketAddress.isUnresolved = false
[0.0.0.0] InetAddress = /0.0.0.0
[0.0.0.0] InetAddress.isAnyLocalAddress = true
[0.0.0.0] InetAddress.isLinkLocalAddress = false
[0.0.0.0] InetAddress.isLoopbackAddress = false
[0.0.0.0] InetSocketAddress = /0.0.0.0:8080
[0.0.0.0] InetSocketAddress.isUnresolved = false

Comment 10 Thomas Hauser 2014-08-07 13:31:50 UTC
Thanks for following up on this Jason; note that the underlying issue is that the jboss-cli.sh cannot start. It's possible there's a bug in the jboss-as-cli code that is causing this issue, looking at the output of the LoopBack program

Comment 11 Jason Shepherd 2014-08-08 01:57:46 UTC
Customer stated this is now they configure their network on Windows 7:

1. Click on 'Start Menu', then 'Control Panel'.

2. Click on 'Network and Sharing Center'.

3. On the left, click on 'Change adapter settings'.

4. Right click on the relevant connection, and select properties.

5. Double click on the 'Internet Protocol Version 4 (TCP/IPv4) option.

6. Select 'Use the following IP address'
Enter the appropriate details.

7. Select 'Use the following DNS server addresses'
Enter the appropriate details. (in our case there are two DNS servers)

8. Click on Advanced, then click on the 'DNS' tab.
Select 'Append these DNS suffixes (in order)'
Enter the appropriate details. (in our case there are two domains).

9. Click Ok, Ok, OK to finish. Wait a minute for settings to apply.

Comment 12 Miles Tjandrawidjaja 2014-08-08 15:34:16 UTC
Hello,

I've configured my VM with the steps provided above,
but I am not encountering the problems indicated in attachment 924352 [details].
It is looking like a problem with their network configuration.
I am not able to emulate the problem.

Comment 13 Thomas Hauser 2014-09-02 15:32:38 UTC
Any more news on this issue? I'd like to figure out the root cause so that it can be addressed in future releases.


Note You need to log in before you can comment on or make changes to this bug.