MySQL Bugs: #54415: Solaris 10 MEM install doesn't refresh screen beyond language selection

Bug #54415	Solaris 10 MEM install doesn't refresh screen beyond language selection
Submitted:	11 Jun 2010 1:56	Modified:	24 Mar 2015 16:50
Reporter:	Shannon Wade	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Installing	Severity:	S3 (Non-critical)
Version:	2.2.1.1721	OS:	Solaris (5.10 Generic_120011-1)
Assigned to:	Assigned Account	CPU Architecture:	Any
Triage:	Needs Triage: D2 (Serious)

Description:
Agent and monitor install did the same thing on:

SunOS elara 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T1000

Installing the agent or monitor via gui or mode text would show the language selection screen but
not show the selection prompt nor proceed past that screen or seem to react to the keyboard.

Analysis of truss showed it was waiting on user input. By outputting to a file you could select an option the install would proceed. But outputting to the screen would not refresh so it *seemed* to hang.

Last bit of truss output:

stat("/lib/libXext.so.0", 0xFFBFB5A0)		Err#2 ENOENT
stat("/usr/lib/libXext.so.0", 0xFFBFB5A0)	= 0
resolvepath("/usr/lib/libXext.so.0", "/usr/openwin/lib/libXext.so.0", 1023) = 29
open("/usr/lib/libXext.so.0", O_RDONLY)		= 5
mmap(0xFF200000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5, 0) = 0xFF200000
mmap(0x00010000, 204800, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFEDC0000
mmap(0xFEDC0000, 96472, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 5, 0) = 0xFEDC0000
mmap(0xFEDE8000, 3133, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 5, 98304) = 0xFEDE8000
munmap(0xFEDD8000, 65536)			= 0
mmap(0xFEDF0000, 264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0xFEDF0000
munmap(0xFEDEA000, 24576)			= 0
mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF0D0000
memcntl(0xFEDC0000, 16304, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
close(5)					= 0
stat("/usr/openwin/lib/libc.so.1", 0xFFBFB5A0)	Err#2 ENOENT
stat("/usr/openwin/lib/libc.so.1", 0xFFBFB5A0)	Err#2 ENOENT
stat("/usr/openwin/lib/libnsl.so.1", 0xFFBFB360) Err#2 ENOENT
stat("/usr/openwin/lib/libsocket.so.1", 0xFFBFB360) Err#2 ENOENT
stat("/usr/openwin/lib/libdl.so.1", 0xFFBFB360)	Err#2 ENOENT
stat("/usr/openwin/lib/libsocket.so.1", 0xFFBFB360) Err#2 ENOENT
munmap(0xFF200000, 8192)			= 0
unlink("/var/tmp/tclCLaWXH")			= 0
write(1, " L a n g u a g e   S e l".., 20)	= 20
write(1, "\r\n", 2)				= 2
write(1, " P l e a s e   s e l e c".., 41)	= 41
write(1, " [ 1 ]   E n g l i s h  ".., 23)	= 23
write(1, " [ 2 ]   J a p a n e s e".., 26)	= 26
write(1, " P l e a s e   c h o o s".., 30)	= 30
read(0, 0x00EE98C8, 4096)	(sleeping...)
    Received signal #2, SIGINT, in read() [default]
read(0, 0x00EE98C8, 4096)			Err#4 EINTR

How to repeat:
Not sure yet

Suggested fix:
Allow user to not only respond to input but to see the results of that input =)

Hi,

We will try to reproduce on our side. As a workaround the user could use the text mode to install the MEM (--mode text)

The --mode text did not help (same behavior). The unattended mode worked fine.

Could we have access to the machine?

We can not reproduce using the terminal wrapper that Michael Schuster posted in the bug tracking. Is there any possibility that you can reproduce this issue in a machine out of the SUN's internal network or to have a meeting with GoToMeeting?

Michael Schuster writes: 
I can certainly try!

please provide access data, path information and whatever else I need to know so I can do so.
cheers

Hi,

Since the machine is in your network, it is up to you how we can access it.  We currently can setup GotoMeeting meetings and you can give us control, but it requires Windows. Would it be possible to start a goto meeting session and then, from your Windows install, open a VNC session to the Sparc machine?  Would that work?  Can you reproduce the issue using VNC ?

Best regards

Daniel

Michael Schuster writes: 
two things: sorry for delayed response, the automatic notification I set up seems to be ignoring me, and I didn't check earlier ...

I think there's a slight misunderstanding: I can't grant you access to any machine on our network, AFAIK, by whatever means, (I guess) unless you're physically on a campus with someone from Sun/Oracle ... also, I read your comment "Is there any possibility that you can reproduce this issue in a machine out of the SUN's internal network" as "you (bitrock) will provide access to a machine that I can test on"; sorry if that's not what you meant.
I've never heard of GoToMeeting, so can't comment on that other than the above.

Unfortunately we cannot provide access to our own internal machines as they are used for development/testing of other customers' code. I thought since you are Sun, that you may be able to get a development machine through the partner program that is accessible for testing (we have such arrangements with IBM Virtual Loaner Program and HP for HP-UX-related development)  

The only other solution we can think of is that you talk with a dedicated server provider and get one of their machines for a small period of time (though minimum time seems a month)

 http://www.btinet.net/Dedicated_Solutions/Solaris/index.html

Alternatively if you were able to reproduce this on a Solaris 10 virtual machine, then we could provide a place for you to upload

Best regards

Daniel

Michael Schuster writes: 
the VM suggestion proved to be the right way forward, thx!

I've created a tar.bz2 file of a VirtualBox OVF file (size: 1928840513; md5sum: 358917b334bf734ef74f16c6896fadcf); please let me know where to upload it to, I will not attach it to an email :-) and bugs.mysql.com allows attachments only up to 500KB, it seems.

once you've downloaded and unpacked it, here's the steps I think will get you there:

1) install Virtualbox 3.2.(4|6) -- something new at any rate (don't know about other virtualisation technologies).
2) start Virtualbox
3) import the .ovf file (File->import ...), it should be almost trivial

if the VM is started automatically, stop it again - the following step only works on a powered-off VM (or so I understand)

4) to be able to ssh *into* the VM, one way is to set up the network as "NAT" ed (this is the default and should already be set) and then, on the commandline *on the host*, do the following:

    # VBoxManage modifyvm "s10u8" --natpf1 "guestssh,tcp,,2222,,22"

5) restart VM

now, if the host's name is eg foo.my.domain:

6) "ssh -p 2222 test@foo.my.domain" (password: test) will create an ssh session into the VM (details about this can be found in the Virtualbox User Manual, ch. 6.3.1)
 
in the VM:
7) $ cd /export/store/
8) $ ./mysqlmonitoragent-2.2.2.1727-solaris10-x86-32bit-installer.bin --mode text

this showed the problem nicely both when I created the session directly from my workstation as well as in a VNC session. In both cases I use opensolaris' /usr/bin/xterm, in one special case without any options, and reproduced the issue again.

Hi Michael,

Thanks for reproducing in a Virtual Machine. I sent you a private email with the credentials to upload the Appliance in our FTP server.

From Michael:

I found a workaround for "my" issue:

adding the "-k8" option to xterm got rid of the "hang". Here's the man-page excerpt:

     -k8     This  option  sets  the  allowC1Printable  resource.
             When  allowC1Printable  is  set, xterm overrides the
             mapping of C1 control characters (code  128-159)  to
             treat them as printable.

This also helps the graphical installation, btw.

I hope this information helps addressing this.

Michael

From BitRock:

Hi all,

Thanks Michael for your feedback, it was very helpful for us. Regarding your test notes it seems that the problem is the locale file. These are the reported issues:

- The installer looked non-optimal. This is due to the user does not have installed the Japanese locale. We can not do anything to fix this issue, the user should install the Japanese locale files.

- The installer seems to hang on text mode. This could be related to the Terminal settings. Michael Schuster points to the "-k8" option which overrides the control characters. We can not fix this issue in the installer, it depends on the Terminal settings. This is not the usual configuration in the system and it is not easy to reproduce it as you can see in the bug report so we suggest to document it.

Regards,

Beltran