I have an amd64 (STABLE) server and for seome reason, after a reboot I started to get from app-misc/screen-4.0.3-r4 application: "No more PTYs. Sorry, could find a PTY.". I saw the issue in the past and probably never fixed that, so it popped up now after a reboot. I checked and recreated the kernel several times and rebooted, no luck. I should say that udev during emerge complain that I have 2.6.32.58 vanilla kernel and that kernels < 2.6.32 do not work (probably an issue version checking). Recently I upgraded: sys-apps/sysvinit-2.88-r1 -> sys-apps/sysvinit-2.88-r3 which maybe caused the whole issue? While chasing for a fix: I upgraded: sys-apps/sysvinit-2.88-r1 -> sys-apps/sysvinit-2.88-r3 sys-apps/openrc-0.8.3-r1 -> sys-apps/openrc-0.9.8.4 sys-fs/udev-164-r2 -> sys-fs/udev-171-r5 I removed: sys-apps/hal-0.5.13-r2 I am now on: sys-apps/baselayout-2.0.3 sys-fs/udev-171-r5 sys-apps/openrc-0.9.8.4 sys-apps/sysvinit-2.88-r3 Workaround: I do NOT have in /etc/fstab any line mounting devpts. I could get around the issue by adding that line, because running the mount command manually works for me. See below: # gzip -dc /proc/config.gz | grep -i PTS CONFIG_DEVPTS_MULTIPLE_INSTANCES=y # gzip -dc /proc/config.gz | grep -i PTY CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # cat /etc/mtab rootfs / rootfs rw 0 0 /dev/root / ext3 rw,noatime,errors=continue,data=writeback 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 rc-svcdir /lib64/rc/init.d tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0 configfs /sys/kernel/config configfs rw,nosuid,nodev,noexec,relatime 0 0 udev /dev tmpfs rw,nosuid,relatime,size=10240k,mode=755 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0 /dev/md1 /nfslarge ext3 rw,noatime 0 0 /dev/sdb3 /scratch ext3 rw,noatime 0 0 usbfs /proc/bus/usb usbfs rw,noexec,nosuid,devmode=0664,devgid=85 0 0 binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,noexec,nosuid,nodev 0 0 rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 nfsd /proc/fs/nfsd nfsd rw,noexec,nosuid,nodev 0 0 # cat /etc/mtab > /tmp/fstab.old # ls -la /dev/pts total 0 drwxr-xr-x 2 root root 40 Mar 10 11:18 . drwxr-xr-x 7 root root 13920 Mar 10 11:18 .. # mount -t devpts none /dev/pts # ls -la /dev/pts total 0 drwxr-xr-x 2 root root 0 Mar 10 11:18 . drwxr-xr-x 7 root root 13920 Mar 10 11:18 .. c--------- 1 root root 5, 2 Mar 10 11:18 ptmx # cat /etc/mtab > /tmp/fstab.new diff -u -w /tmp/fstab.old /tmp/fstab.new --- /tmp/fstab.old 2012-03-10 11:48:07.000000000 +0100 +++ /tmp/fstab.new 2012-03-10 11:47:49.000000000 +0100 @@ -15,3 +15,4 @@ binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,noexec,nosuid,nodev 0 0 rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 nfsd /proc/fs/nfsd nfsd rw,noexec,nosuid,nodev 0 0 +none /dev/pts devpts rw 0 0 # So, I see now maybe the cause (two lines, maybe an old a new syntax?): # grep pts /etc/mtab devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 none /dev/pts devpts rw 0 0 # Somewhat related bugs: #329335, #375947. Also http://www.gossamer-threads.com/lists/gentoo/user/206090
On 3.2.1-gentoo-r1, baselayout-2.1, openrc-0.9.8.4, I've got: # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set no pts fstab lines 'mount' returns: devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620) and inside /dev/pts there are eleven nodes (0-10) with 'crw--w----' permissions owned by currently logged in user.
openrc would mount that filesystem in /etc/init.d/devfs
(In reply to comment #1) > On 3.2.1-gentoo-r1, baselayout-2.1, openrc-0.9.8.4, I've got: > > # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set > CONFIG_UNIX98_PTYS=y > # CONFIG_LEGACY_PTYS is not set > no pts fstab lines > > 'mount' returns: > devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620) I get on some, healthy system instead (note the extra 'ptmxmode=000'): devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) > > and inside /dev/pts there are eleven nodes (0-10) with 'crw--w----' > permissions owned by currently logged in user. Same on the healthy system. But, on the ill-one the files /dev/pts/[0-11] are owned by group tty instead of root. On the ill system I have CONFIG_DEVPTS_MULTIPLE_INSTANCES=y Enable support for multiple instances of devpts filesystem. If you want to have isolated PTY namespaces (eg: in containers), say Y here. Otherwise, say N. If enabled, each mount of devpts filesystem with the '-o newinstance' option will create an independent PTY namespace. Does this help? I probably cannot reboot in near future to test. :(
There is one kernel config variable specifying that kernel pre-creates and mounts a"skeleton" /dev directory with some minimal contents. Full /dev/ should be mounted later on during boot procedure on top of it. Could this interfere somehow? I forgot the variable name in .config.
Do you mean CONFIG_DEVTMPFS{,_MOUNT} ? As of udev 181, the first one is a prerequisite. As for the numbered nodes in /dev/pts, they're owned by currently logged user (well, only one user is logged in, so perhaps they're created for each), but the group is 'tty'.
Created attachment 327468 [details] Screenshot of VM with failing /dev/pts/ I noticed on one of my VMs. I slightly augmented the devfs init script to show the mkdir error messages and echo the mount commandline used. On boot, I noticed that the mkdir failed with "read-only filesystem". I also noticed that my rootfs did _not_ have the /dev/pts directory (neither did it have /dev/shm). So I created them. Upon reboot, devfs can see them and mounts the dirs correctly. Yet, on SSH login, there's still "PTY allocation request failed on channel 0" Logging in, sure enough: /dev/pts is not there. Looking closer at the boot messages, I saw something peculiar -- take a look at the screenshot I attached. It seems that _after_ mounting /dev/pts and /dev/shm the udev init script mounts /dev over the existing stuff -- shadowing /dev/pts and /dev/shm in the process. I suspect this is either an oversight in the udev script (not remounting those two dirs) or an ordering issue between the two init scripts.
Try adding udev-mount to the sysinit runlevel with this command: rc-update add udev-mount sysinit There is a warning about this in the latest stable udev (udev-171-r8). The next release of OpenRC will probably do this automatically if udev is in the sysinit runlevel.
(In reply to comment #6) > It seems that _after_ mounting /dev/pts and /dev/shm the udev init script > mounts /dev over the existing stuff -- shadowing /dev/pts and /dev/shm in > the process. I've had the same issue today, running ~amd64 Gentoo, first reboot after 5 days uptime. I updated world on October 30th. Whatever was updated also started printing debug messages on shutdown (extraneous echo of unmounted file systems) and on reboot (mounted file systems), and that's when mounting /dev/shm failed, and once the boot finished /dev/shm and /dev/pts were mounted but empty (shadowed). I couldn't start urxvt until typing "mount /dev/pts" again in console. I wgetpasted the emerge.log for Oct 30 here: http://bpaste.net/show/55387/ Among other things it updated: sys-apps/openrc-0.10.5 -> sys-apps/openrc-0.11.2 sys-fs/udev-init-scripts-16 -> sys-fs/udev-init-scripts-17-r1 sys-fs/udev-194 -> sys-fs/udev-195 Updating again now to see if it will resolve the issue. I also added udev-mount to sysinit now, it wasn't there before (didn't show up in rc-update show), but it never caused a problem before the last world update. CONFIG_DEVTMPFS is enabled in my kernel, CONFIG_DEVTMPFS_MOUNT is not - does this actually make a difference with Initramfs being the first system mounted? I'd assume that mounting devtmpfs in the root partition is something the Initramfs would have to do either way, or does the kernel really do that automatically in the switch_root?
Try adding udev-mount to the sysinit runlevel with this command: rc-update add udev-mount sysinit Report back to the bug and let me know if that takes care of your issue.
OK after rebooting the issue seems to be gone. Still not sure why it broke in the first place. Also there's still this debug message that echoes out the mountpoints as it mounts/umounts stuff on boot/shutdown.
I know about the issue that you are talking about wrt printing out mount points. That is fixed in git and will be part of OpenRC-0.11.3 which will be released soon.
