I have to run an old software on opensuse.
This software worked well with version 11.3.
After upgrade to 13.1 the software shows an error, that the /dev/ttyxx is missing.
(Can’t open /dev/ttyxx)
I googled and found out, that this is maybe from using grub2 in 13.1
Do someone know a way, to reimplement the /dev/ttyxx ?
Thank you.
WolfgM
Is it /dev/ttySxx? In other words, does your software use the old style serial ports?
No, it is /dev/ttyxx
In 11.3 it looks like:
fg26:/usr/src/linux # ls -alt /dev/ttyxx
prw-rw-rw- 1 root root 0 Aug 13 2010 /dev/ttyxx
Do you still have access to the 11.3 system?
If so, could you: dmesg | grep tty
And see what device creates ttyxx, or alternatively look at /etc/inittab if there is a custom string that creates it.
yes, I have access to the old system. here ist the output of “[FONT=courier new]dmesg | grep tty”
fg26:/usr/src/linux # dmesg | grep tty
0.000000] console [tty0] enabled
0.335539] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
0.359927] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
0.409120] 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
0.434337] 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
and also in /etc/inittab, no ttyxx is shown:
[/FONT]# getty-programs for the normal runlevels
1:2345:respawn:/sbin/mingetty --noclear tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
no more tty’s…
I have no idea, where ttyxx is initialiezed.
It could also be created with an udev rule ( /etc/udev/rules.d/somefilehere ) - Check through those as well as the udev directory itself.
Is this a server you setup or someone else?
It is no server. It is a desktop system.
fg26:/etc/udev # uname -a
Linux fg26 2.6.37.6-24-desktop #1 SMP PREEMPT 2012-10-18 22:36:08 +0200 i686 i686 i386 GNU/Linux
I checked
/etc/udev
and also all files in
/etc/udev/rules.d
if there is any occurrence of tty (or ttyxx), but I did not find any occurrence.
grep did not find anything in /etc:
fg26:/etc/udev # grep -rnl /etc -e ttyxx
fg26:/etc/udev #
I do find it in
/usr/src/linux/Documentation/uml/UserModeLinux-HOWTO.txt
/usr/src/linux/drivers/char/Kconfig
/usr/src/linux/arch/um/Kconfig.char
/usr/src/linux/arch/h8300/Kconfig
/usr/src/linux-2.6.37.6-24/Documentation/uml/UserModeLinux-HOWTO.txt
/usr/src/linux-2.6.37.6-24/drivers/char/Kconfig
/usr/src/linux-2.6.37.6-24/arch/um/Kconfig.char
/usr/src/linux-2.6.37.6-24/arch/h8300/Kconfig
For exapmle:
config UNIX98_PTYS
bool “Unix98 PTY support”
help
…
Linux has traditionally used the BSD-like names /dev/ptyxx for
masters and /dev/ttyxx for slaves of pseudo terminals. This scheme
has a number of problems. The GNU C library glibc 2.1 and later,
however, supports the Unix98 naming standard: in order to acquire a
pseudo terminal, a process opens /dev/ptmx; the number of the pseudo
terminal is then made available to the process and the pseudo
terminal slave can be accessed as /dev/pts/<number>. What was
traditionally /dev/ttyp2 will then be /dev/pts/2, for example.
Maybe I should use the old BSD instead of Unix98 PTY ?
There has never ever been ttyxx (unless someone created it manually). There could have been ttyx0 through ttyxf as pseudo terminal slaves.
You got it backwards. /dev/ttyxx (for certain values of xx) are slaves of legacy BSD pseudo terminals while Unix98 are modern pseudo-terminals. On 13.1 kernel LEGACY_PTY_COUNT is set to 0 by default, so no legacy pseudo terminals are allocated. If you want (need) to use them, boot with pty.legacy_count=nn or legacy_count=nn kernel parameter (nor sure which one works for that old kernel).
Your solution probably depends on whether your tty is needed on system bootup or not.
Your solution might be found in the following concurrent Forum thread and the Lennart blog post reference in my post, then read the tty MAN pages for yoour openSUSE to verify what was implemented then
As always,
if your post included more deatail about your application and the actual error, you’d get better help… For now anyone offering help is guessing a lot.
HTH,
TSU