SLES 11 SP1 Problem with YaST2 - segmentation fault

SUSE Linux Enterprise Server SLES Configure-Administer
1

I am having the same problem with YaST2 on all 10+ of my SLES 11 SP1 servers that run IBM HTTP Server (IHS). The issue is that just about everything I try to do using YaST2 results in the screen flashing and nothing happening. Upon exiting YaST2, there is a message in PuTTY for each task attempted which is:

/sbin/yast: line 443: 37014 Segmentation fault $ybindir/y2base $module “$@” “$SELECTED_GUI” $Y2_GEOMETRY $Y2UI_ARGS

Just about everything attempted in YaST2 results in the above message.

I received the above message when I went to Hardware → DASD. When I tabbed to DASD and pressed Enter, the screen simply flashed as stayed on the YaST2 Control Center screen.

These servers are a mix of test and production servers. None have been modified since September, 2011, when they were upgraded from SLES 11 SP0 to SP1. YaST2 worked fine after the upgrade to SP1 and stopped working sometime in February.

A few differences between these servers and the ones that run WebSphere Application Server (WAS) are:

  • The servers running IHS run with 128 MB of memory and the servers running WAS are at 1GB and above.
  • The servers running IHS are in a DMZ and the servers running WAS are not (I don’t believe that this has anything to do with the issue). Thus, the IHS servers can’t connect to Novell for updates without me re-IPing then to a different network for the upgrade process.

Does anyone have an idea as to what I need to do to resolve the segmentation faults?

Harley

2

Hi
So your running a X server locally and using putty via ssh -X to
connect?

I’m assuming the ncurses version of YaST runs fine in your putty
session?

What X server are you using locally? Does it provide any log
information?

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.13-0.27-default
up 13:21, 2 users, load average: 0.02, 0.03, 0.05
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

3

[QUOTE=malcolmlewis;3100]Hi
So your running a X server locally and using putty via ssh -X to
connect?

I’m assuming the ncurses version of YaST runs fine in your putty
session?

What X server are you using locally? Does it provide any log
information?

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.13-0.27-default
up 13:21, 2 users, load average: 0.02, 0.03, 0.05
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU[/QUOTE]

Hi Malcolm,

No, I’m not running an X server (that I know of). I’m using PuTTY (utilizing ssh) to simply login to the server in command line mode. The only time I use a GUI is to install maintenance. To do this I start vncserver and access the vnc server via a browser.

All of my SLES instances are running as guests under z/VM (1 LPAR) on an IBM z9 mainframe.

Harley

4

Hi
Sorry for the delay…

So your running just the yast command (ncurses) not yast2 (which is
the GUI version)?

So when you putty in to the machine via ssh it’s as your user, then
switch to root to run yast?

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.13-0.27-default
up 1 day 3:12, 2 users, load average: 0.02, 0.04, 0.05
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

5

Hi Malcolm,

No problem on the delay. This issue isn’t critical at this point but is nagging at me to get it resolved.

I’m invoking yast but the full screen the starts up says that it is yast2.

Yes, I putty in as myself then issue ‘sudo su -’ to switch to root, then invoke yast.

I had a thought that maybe the issue is because the http servers are in a DMZ and use the SuSEfirewall to restrict access to them. My client let me take one of the test http servers yesterday for a test. I modified the network (IP address and the routes file) to put it into a different network and also shut down the software firewall (actually disabled it with chkconfig and rebooted). I verifed that the firewall was down and tried to invoke yast → hardware → dasd and encountered the same segmentation fault message. Apparently, the locked down network doesn’t have anything to do with the issue.

Harley

P.S. FYI - I will on vacation next week and won’t be checking for responses.

6

Hi
Only su - is necessary, then run the command yast

OK, can you check that ncurses is installed;

zypper se -i ncurses

There should be a packages called yast2-ncurses installed.

Not something in the putty configuration?

If you putty into one server, can you ssh in as your user (to
localhost or another one on your network), then run su - and yast.

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.13-0.27-default
up 1 day 6:00, 3 users, load average: 0.01, 0.04, 0.05
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

7

[QUOTE=malcolmlewis;3494]Hi
Only su - is necessary, then run the command yast

OK, can you check that ncurses is installed;

zypper se -i ncurses

There should be a packages called yast2-ncurses installed.

Not something in the putty configuration?

If you putty into one server, can you ssh in as your user (to
localhost or another one on your network), then run su - and yast.

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.13-0.27-default
up 1 day 6:00, 3 users, load average: 0.01, 0.04, 0.05
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU[/QUOTE]

Malcolm,

Due to the servers encountering the segmentation fault issue being in a DMZ, they aren’t allowed to access the internet. Thus, the zypper command you provided failed on one of the servers having the issue, server testh1. I ran the command on several other servers, which don’t encounter the error, and they all came back with

Refreshing service ‘nu_novell_com’.
Retrieving repository ‘SLES11-SP1-Updates’ metadata [done]
Building repository ‘SLES11-SP1-Updates’ cache [done]
Loading repository data…
Reading installed packages…

S | Name | Summary | Type
–±------------------±-------------------------------------------------±-------
i | libncurses5 | The New curses Libraries | package
i | libncurses5-32bit | The New curses Libraries | package
i | libncurses6 | The New curses Libraries | package
i | ncurses-utils | Tools using the new curses libraries | package
i | yast2-ncurses | YaST2 - Character Based User Interface | package
i | yast2-ncurses-pkg | YaST2 - Character Based Package Manager Frontend | package[/FONT]

yast2-ncurses is installed.

I’m using the same putty configuration for all of my servers. The only servers having this problem are the ones that exist to run IBM HTTP Server.

I tested as you suggested by:

  • Logging into server ‘testh1’ with my non-root id.
  • Issued ‘ssh localhost’ and entered my password.
  • Issued ‘su -’ and entered the password for root.
  • Issued ‘yast’.
  • Selected Hardware->DASD.
  • The screen flashed and when I exited yast putty showed the segmentation fault message.

I then tested by:

  • Logging into server ‘test’ with my non-root id.
  • Issued ‘ssh testh1’ and entered my password.
  • Issued ‘su -’ and entered the password for root.
  • Issued ‘yast’.
  • Selected Hardware->DASD.
  • The screen flashed and when I exited yast putty showed the segmentation fault message.

Note that test and testh1 were cloned from the same golden image and have the same software base installed. Server test runs WAS and testh1 runs IBM HTTP Server. Server ‘test’ does not have the segmentation fault problem.

Harley

8

Maybe I’m wrong but I do think that the problem simply has to do something with this:

[QUOTE=x0500hl;3829]- The servers running IHS run with 128 MB of memory and the servers
running WAS are at 1GB and above.[/QUOTE]

Let’s just try to temporarily increase the RAM for one IHS server and let’s see if it faults.

Also, an strace -f yast2 s390 (if I’m right on the module name, yast2 -l helps) output could show something.

9

The problem has been resolved with a LOT of help from Novell support.

The problem turned out to be that the stack size was reduced in February from the default of 8MB to 256K. The size was reduced, as recommended by IBM, to resolve a problem that we had where IBM HTTP Server (IHS) had crashed due to an out of memory condition. I had forgotten that my coworker (he had forgotten about this as well) had implemented this change on all 10 servers whose function is to run IHS.

Novell support had me issue command ‘ulimit -s unlimited’ and test the yast functions that were seg faulting. All of the issues went away. As an aside, with the stack size set at 256K, most of the rpm commands that were issued also seg faulted.

Thanks to everyone for their ideas!

P.S. I couldn’t find an option, as exists on some forums, to mark this as resolved.

10

Thank for posting back the solution.

This, again, has showed how important logging of configuration changes, and change management in general, are :wink: