ptx®/LAE V1.0.0 Release Notes

ptx/LAE provides a Linux Application Environment for DYNIX/ptx® V4.6.1 that enables you to install and run supported Linux applications.


System Requirements

ptx/LAE requires that the following products also be installed:


Supported Linux Applications

To find out which products are supported for use with ptx/LAE V1.0.0, consult the following URL: http://oss.software.ibm.com.


ptx/LAE Software Installation

Refer to the DYNIX/ptx V4.6.1 and Layered Products Software Installation Release Notes for information about installing ptx/LAE and the required Red Hat Linux components. Refer to the section entitled "Install Linux Applications and Packages" (later in these release notes) for information about installing Linux applications and packages.


ptx/LAE Limitations

The following limitations apply to ptx/LAE:


The ptx/LAE Root Directory and Pathmapping

To avoid conflicts with DYNIX/ptx, ptx/LAE installs Red Hat Linux components in an alternate root directory, /linux/root. ptx/LAE provides a feature called pathmapping that enables Linux applications to access the objects in /linux/root automatically. When a Linux application is invoked, the pathmapping feature attempts to map the file path specified by the application to /linux/root/filepath. If this fails, then the original path is used.

The DYNIX/ptx kernel uses the following methods to recognize a Linux binary application and then performs the necessary pathmapping:

A Linux shell script is recognized as follows:


System Files

Linux applications require that the following /proc files be present on the system: mtab, fstab, meminfo, cpuinfo. ptx/LAE provides a script, genlaefiles, that creates these files. The script runs every 30 minutes as a cron job to keep the files up to date.

The genlaefiles script uses the following methods to create the files:


Linux System Calls

ptx/LAE implements the following system calls:

Table 1. Implemented System Calls

1 exit

2 fork

3 read

4 write

5 open

6 close

7 waitpid

8 creat

9 link

10 unlink

11 execve

12 chdir

13 time

14 mknod

15 chmod

16 lchown

18 stat

19 lseek

20 getpid

23 setuid

24 getuid

25 stime

27 alarm

28 fstat (old)

29 pause

30 utime

33 access

34 nice

36 sync

37 kill

38 rename

39 mkdir

40 rmdir

41 dup

42 pipe

43 times

45 brk

46 setgid

47 getgid

49 geteuid

50 getegid

54 ioctl

55 fcntl

57 setpgid

60 umask

61 chroot

63 dup2

64 getppid

65 getpgrp

66 setsid

67 sigaction (old)

68 sgetmask

69 ssetmask

70 setreuid

71 setregid

72 sigsuspend

73 sigpending

75 setrlimit

76 getrlimit

77 rusage

78 gettimeofday

79 settimeofday

80 getgruops

81 setgroups

82 select (old)

83 symlink

84 lstat

85 readlink

90 old_mmap

91 munmap

92 truncate

93 ftruncate

94 fchmod

95 fchown

96 getpriority

97 setpriority

99 statfs

100 fstatfs

102 socketcall

104 setitimer

105 getitimer

106 newstat

107 newlstat

108 newfstat

114 wait4

117 ipc

118 fsync

119 sigreturn

120 clone

122 newuname

123 modify_ldt

125 mprotect

126 sigprocmask

133 fchdir

136 personality

138 setfsuid

139 setfsgid

140 llseek

141 getdents

142 select

143 flock

144 msync

145 readv

146 writev

148 fdatasync

156 sched_setscheduler

157 sched_getscheduler

158 sched_yield

162 nanosleep

163 mremap

164 setresuid

165 getresuid

168 poll

173 rt_sigreturn

174 rt_sigaction

175 rt_sigprocmask

176 rt_sigpending

179 rt_sigsuspend

180 pread

181 pwrite

182 chown

186 sigaltstack

190 vfork


The following system calls are unimplemented in ptx/LAE. They return ENOSYS and allow the application to continue. The system calls preceded by "2.4" are available only in 2.4 kernels.

Table 2. Unimplemented System Calls Returning ENOSYS

62 ustat (deprecated)

154 sched_setparam

155 sched_getparam

59 sched_get_priority_max

60 sched_get_priority_min

61 sched_rr_get_interval

177 rt_sigtimedwait

178 rt_sigqueueinfo

183 getcwd

191 - 2.4 getrlimit

192 - 2.4 mmap2

193 - 2.4 truncate64

194 - 2.4 ftruncate64

195 - 2.4 stat64

196 - 2.4 lstat64

197 - 2.4 fstat64

198 - 2.4 lchown

199 - 2.4 getuid

200 - 2.4 getgid

201 - 2.4 geteuid

202 - 2.4 getegid

203 - 2.4 setreuid

204 - 2.4 setregid

205 - 2.4 getgroups

206 - 2.4 setgroups

207 - 2.4 fchown

208 2.4 - setresuid

209 - 2.4 getresuid

210 - 2.4 setresgid

211 - 2.4 getresgid

212 - 2.4 chown

213 - 2.4 setuid

214 - 2.4 setgid

215 - 2.4 setfsuid

216 - 2.4 setfsgid

218 - 2.4 mincore

219 - 2.4 madvise


The following system calls are unimplemented in ptx/LAE. They return the SIGSEGV signal, causing the application to core dump and abort. The system call preceded by "2.4" is available only in 2.4 kernels.

Table 3. Unimplemented System Calls Returning SIGSEGV

0 unused by Linux

17 unused by Linux

21 mount

22 unused by Linux

26 ptrace

31 unused by Linux

32 unused by Linux

35 unused by Linux

44 unused by Linux

48 signal (old)

51 acct

52 unmount

53 unused by Linux

56 unused by Linux

58 unused by Linux

59 olduname

74 sethostname

86 uselib

87 swapon

88 reboot

89 old_readdir

98 unused by Linux

101 ioperm

103 syslog (admin)

109 uname

110 iopl

111 vhangup

112 idle will

113 vm86old

115 swapoff

116 sysinfo

121 setdomainname

124 adjtimex

127 create_module

128 init_module

129 delete_module

130 get_kern_syms

131 quotactl

132 getpgid

134 bdflush

135 sysfs

137 unused by Linux

147 getsid

149 sysctl

150 mlock

151 munlock

152 mlockall

153 munlockall

166 vm86

167 query_module

169 nfsservctl

170 setresgid

171 getresgid

172 prctl

184 capget

185 capset

187 sendfile

188 unused by Linux

189 unused by Linux

217 - 2.4 pivot_root


ptx/LAE does not support other Linux system calls. If an application uses an unsupported system call, the kernel will take one of the following actions:

The following IOCTLs are supported in ptx/LAE. Unsupported IOCTLs return EINVAL.

Table 4. IOCTLs Supported in ptx/LAE

TCGETS

TIOCOUTQ

TCSETS

TIOCSTI

TCSETSW

TIOCGWINSZ

TCSETSF

TIOCSWINSZ

TCGETA

FIONREAD

TCSETA

FIONBIO

TCSETAW

TIOCGETD

TCSBRK

TIOCSETD

TCSBRK

TCSBRKP

TCXONC

FIOCLEX

TCFLSH

FIONCLEX

TIOCSPGRP

FIOASYNC

TIOCGPGRP



ptx/LAE Tunable Parameter

The modify_ldt() system call allocates Local Descriptor Tables (LDTs) in low kernel memory. When a process calls modify_ldt(), the call creates a per-process LDT. This LDT is freed when the process exits.

Many processes do not use modify_ldt(). For those processes (such as Java®) that call modify_ldt(), there can be one LDT per process.

The low kernel memory used for LDTs must be reserved at boot time. ptx/LAE provides a tunable parameter, LAE_MAX_LDT_CNT, that specifies the maximum number of LDTs that can exist at any given instant. By default, LAE_MAX_LDT_CNT reserves memory for 200 concurrent LDTs. You can use the ptx/ADMIN "Kernel Configuration" option to modify this parameter. The range of values is 10 to 3000.


Using ptx/LAE


The Linux Environment

The Linux environment provides the following:


Set the Sticky Bit on Linux Scripts

The lae_mark command sets the sticky bit on a non-ELF regular file. The DYNIX/ptx kernel uses the sticky bit to distinguish between DYNIX/ptx and Linux scripts.

You can use the lae_mark command to set the sticky bit on Linux scripts that you create.

REFERENCE
lae_mark(1LAE)


DYNIX/ptx Support for the Sticky Bit

When ptx/LAE is installed, a non-root user can set the sticky bit. When ptx/LAE is not installed, only root can set the sticky bit. (This is standard DYNIX/ptx behavior.)

The following DYNIX/ptx utilities support the sticky bit when ptx/LAE is installed:

cp
Propagates the sticky bit to the target file only if ptx/LAE is installed.
chmod
When ptx/LAE is installed, chmod will not unset the sticky bit, unless the -f option is used.
tar
The -L argument, available only when ptx/LAE is installed, sets the sticky bit on non-ELF regular files during extraction. It will not set the sticky bit for directories and special files. The -L argument is enabled by default when the _LAE_INSTALLING environment variable is set to 1.
sh (or ksh), csh
If the sticky bit is set on a shell script, and the first line of the shell script lists a specific interpreter with a first line of the form #! interpreter [arg], then the script is executed by /linux/root/interpreter. For example, #! /bin/sh would be executed by /linux/root/bin/sh.

If the sticky bit is set on a shell script and the first line of the shell script does not list a specific interpreter with a first line of the form #! interpreter [arg], then the Linux version of the current shell /linux/root/bin/[sh,ksh,csh] will be used to process the shell script.


Debug Linux Processes

Two debugging tools are available to debug Linux applications on DYNIX/ptx: gdb and truss. truss is provided as part of DYNIX/ptx; gdb is provided as part of ptx/LAE.

When ptx/LAE is present on the system, truss traces all Linux system calls automatically. The utility provides options for excluding or including specific Linux system calls.

For Linux system calls supported by ptx/LAE, truss displays the name, parameters, and return value of each call. The verbose option displays additional parameter information. For Linux system calls not supported by ptx/LAE, truss displays only the system call name.

REFERENCE
truss(1)


ptx/LAE and the syslogd Daemon

The ptx/LAE log input file /linux/root/dev/log is created when syslogd starts. If the /linux/root/dev directory does not exist after the system is booted or is removed after syslogd is started, then ptx/LAE logging will not work until syslogd is restarted.


Install Linux Applications and Packages

Once you have installed ptx/LAE and the required components from Red Hat Linux V6.2 (see the DYNIX/ptx V4.6.1 and Layered Products Software Installation Release Notes for instructions), you may wish to install Linux applications and packages. To do so, use one of the following three methods:


Install Linux Applications with rpm (Red Hat Package Manager)

rpm is an open packaging system that enables Linux applications to be more easily installed, upgraded, and deinstalled. During installation, rpm manages configuration files so that site-specific customizations are not lost. RPM also maintains a database of installed packages and their files, which enables you to more easily manage the Linux applications on your host.

ptx/LAE includes a version of rpm (the ptx/LAE rpm command) that has been ported for use with DYNIX/ptx. Specifically, the rpm command is a port of RPM 3.0.6 to DYNIX/ptx as provided under the terms of the GNU General Public License.


ATTENTION

Do not install Linux native rpm.


ptx/LAE rpm provides the following default behavior:

Note that although the rpm command will install files and set the sticky bit on them, other installation steps may be required to complete the installation. If this is the case, you must run the lae_mode command to install any additional scripts, and then run lae_mark on the files the scripts generate so that the sticky bit is set. See "Install Linux Applications with lae_mode" for more information about running lae_mode and lae_mark.


Install Linux Applications with tar

When ptx/LAE is installed on a host, the DYNIX/ptx tar command can be used to extract .tar files that contain Linux applications. In order to set the sticky bit on the files you are installing, use either the -L option to the tar command or set the _LAE_INSTALLING environment variable to 1.

For example, to extract the archive file ABCLinux.tar that is located in /usr/local:

tar -xvfL /usr/local/ABCLinux.tar
or
export _LAE_INSTALLING=1 (if using ksh)
tar -xvf /usr/local/ABCLinux.tar

Note that although the tar command will have expanded the installed files and set the sticky bit on them, other installation steps may be required to complete the installation. If this is the case, you must run the lae_mode command to install any additional scripts, and then run lae_mark on the files the scripts generate so that the sticky bit is set. See "Install Linux Applications with lae_mode" for more information about running lae_mode and lae_mark.


Install Linux Applications with lae_mode

The lae_mode command runs the install command for a Linux application so that it, and any scripts or files generated during the installation process, will act as if they were Linux scripts and allows them to be properly interpreted. You must use the lae_mode command when a Linux application has its own installation program or it is on a read-only medium since there is no other way for the installer to interpret them as Linux applications. Once a Linux application has been installed with lae_mode, you must "mark" any of the application's scripts that were installed by setting the sticky bit on the files with lae_mark or manually with chmod. Marking the Linux files enables the DYNIX/ptx kernel to recognize the files as Linux files. (You do not need to mark binaries and directories.)

The installation procedure for Linux applications when using lae_mode is the same as on native Linux, except that you use the lae_mode command to run the install command for the application you are installing. For example, if the install command for a product is install_product, use the following command to install the product with ptx/LAE:

lae_mode install_product


ATTENTION

For application installations that use graphical-user interfaces, you must set the following: LD_LIBRARY_PATH=/usr/X11R6/lib and DISPLAY=your display. For example:

LD_LIBRARY_PATH=/usr/X11R6/lib
DISPLAY=your display
export LD_LIBRARY_PATH DISPLAY


Next, use the lae_mark command to set the sticky bit on the installed files. For example, if the Linux application is installed in /oracle, use the following command to recursively mark all the files in this directory and any subdirectories:

find /oracle | xargs lae_mark

For Linux application-specific installation information, refer to the documentation provided with the Linux application you are installing.


Deinstall the ptx/LAE and Red Hat Components

You can deinstall ptx/LAE by using the Software Management option on the System Administration menu in the ptx/ADMIN menu system. If you are not familiar with the steps to deinstall a product, refer to the ptx/INSTALL Software Installation Guide.


ATTENTION

To deinstall Red Hat components, ptx/LAE must be installed. Do not deinstall ptx/LAE until after you deinstall Red Hat components, unless you intend to keep the Red Hat components.


To deinstall Red Hat components, use the rpm command. A package can only be deinstalled by the user who installed the package (usually root).

  1. To determine the names of installed Red Hat packages, issue this command:

    # rpm -qa

  2. To deinstall a single package, issue this command (where package_name) is the name of the Red Hat package you wish to deinstall:

    # rpm --erase package_name

  3. To deinstall all Red Hat packages, issue this command:

    # rpm --nodeps --erase 'rpm -qa'


Open Problem Reports

This release of ptx/LAE includes the following open software defect. The number in parentheses identifies the problem in the IBM problem-tracking system.


Linux Version of JDK V1.3 Hangs (255028)

Java applications using JDKTM V1.3 may freeze, due to an internal thread locking problem when the JDK is run on ptx/LAE.

Workaround. Use JDK V1.1.8.