Description of problem: All TSM clients (I tried 6.2.2, 6.3.1, 6.4.0.7) crash since Fedora-19. This happens in the same manner on a workstation that was manually migrated to F19 by a new installation. It happens as well on a notebook (Lenovo T520) that was upgraded with 'fedup' from F17 to F19. All the versions worked just fine with Fedora-17 and all the years before. Version-Release number of selected component (if applicable): TSM client 6.2.2, 6.3.1, 6.4.0.7. I tried (stepping back) How reproducible: ------------------------------------------------------------------------------- [root@hphws ~]# dsmc IBM Tivoli Storage Manager Command Line Backup-Archive Client Interface Client Version 6, Release 4, Level 0.7 Client date/time: 11/04/2013 21:02:29 (c) Copyright by IBM Corporation and other(s) 1990, 2013. All Rights Reserved. Node Name: HPHWS Aborted (core dumped) ------------------------------------------------------------------------------- =============================================================================== [root@hphws ~]# gdb dsmc GNU gdb (GDB) Fedora 7.6.1-42.fc19 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /opt/tivoli/tsm/client/ba/bin/dsmc...done. (gdb) run Starting program: /bin/dsmc [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffefc49700 (LWP 19338)] IBM Tivoli Storage Manager Command Line Backup-Archive Client Interface Client Version 6, Release 4, Level 0.7 Client date/time: 11/04/2013 21:02:41 (c) Copyright by IBM Corporation and other(s) 1990, 2013. All Rights Reserved. Node Name: HPHWS Program received signal SIGSEGV, Segmentation fault. 0x00000000006961c6 in psCreateCryptoKey(unsigned char*, char*) () Missing separate debuginfos, use: debuginfo-install TIVsm-BA-6.4.0-7.x86_64 (gdb) ============================================================================== Steps to Reproduce: 1. Find a location with a TSM server 2. Install a TSM client on an F19 based machine and configure (Software source ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance/client/v6r4/Linux/LinuxX86/BA/v641/) 3. run the distributed storage manager client 'dsmc'. Actual results: You should get a 'tsm>' prompt (see below) but the program crashes with a seg fault right after the introduction message. Firewalls are turned 'off' on client (hphws) and server (clumas) for testing: ------------------------------------------------------------------------ [root@hphws ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@hphws ~]# ------------------------------------------------------------------------ [root@clumas ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@clumas ~]# ------------------------------------------------------------------------ 'ping' works smoothly in both directions: ------------------------------------------------------------------------ [root@hphws ~]# ping clumas.naslan PING clumas.naslan (192.168.254.12) 56(84) bytes of data. 64 bytes from clumas.naslan (192.168.254.12): icmp_seq=1 ttl=64 time=0.115 ms 64 bytes from clumas.naslan (192.168.254.12): icmp_seq=2 ttl=64 time=0.130 ms 64 bytes from clumas.naslan (192.168.254.12): icmp_seq=3 ttl=64 time=0.121 ms ^C --- clumas.naslan ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.115/0.122/0.130/0.006 ms [root@hphws ~]# ------------------------------------------------------------------------ [root@clumas ~]# ping hphws.naslan PING hphws.naslan (192.168.254.11) 56(84) bytes of data. 64 bytes from hphws.naslan (192.168.254.11): icmp_seq=1 ttl=64 time=0.190 ms 64 bytes from hphws.naslan (192.168.254.11): icmp_seq=2 ttl=64 time=0.217 ms 64 bytes from hphws.naslan (192.168.254.11): icmp_seq=3 ttl=64 time=0.176 ms 64 bytes from hphws.naslan (192.168.254.11): icmp_seq=4 ttl=64 time=0.194 ms ^C --- hphws.naslan ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3121ms rtt min/avg/max/mdev = 0.176/0.194/0.217/0.017 ms [root@clumas ~]# ------------------------------------------------------------------------ So all communication conditions match and the crash cannot happen due to authentication issues against the TSM server. Expected results: I have an older notebook (32 bit; Fedora-14) and here it still works fine as all the years before ... ------------------------------------------------------------------------------- [root@hphnote ~]# dsmc IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface Client Version 5, Release 5, Level 2.0 Client date/time: 11/04/2013 20:07:10 (c) Copyright by IBM Corporation and other(s) 1990, 2009. All Rights Reserved. Node Name: LINOTE Session established with server TSM6LNX: Linux/x86_64 Server Version 6, Release 3, Level 4.0 Server date/time: 11/04/2013 21:07:12 Last access: 11/04/2013 21:05:20 tsm> inc /etc Incremental backup of volume '/etc' Successful incremental backup of '/etc' Total number of objects inspected: 1 Total number of objects backed up: 0 Total number of objects updated: 0 Total number of objects rebound: 0 Total number of objects deleted: 0 Total number of objects expired: 0 Total number of objects failed: 0 Total number of bytes transferred: 0 B Data transfer time: 0.00 sec Network data transfer rate: 0.00 KB/sec Aggregate data transfer rate: 0.00 KB/sec Objects compressed by: 0% Elapsed processing time: 00:00:02 tsm> ------------------------------------------------------------------------------- Additional info: If this gets into any RHEL distribution and/or update it disables all infected RHEL production servers from doing machine backups in datacenters. I keep a TSM server in my lab for testing purposes and can assist. Anyway, I am stuck due to the behavior in Fedora-19 while everything (Client version 6.4.0.7 and the configuration) worked fine in the Fedora-17 system. It fails badly after the migration to Fedora-19 with harsh seg faults - and I cannot get a clue 'why' ...
I'm unclear as to why you think this is a kernel problem. There are many software components that change between each Fedora release. Perhaps you should take this up with IBM to start with. They should be able to get you a full backtrace and at least help narrow the problem down according to whatever level of support your contract provides. If you are having issues with TSM on a RHEL product, please open a bug against RHEL.