NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

install/47774: sysinst(8) should handle ptyfs itself



>Number:         47774
>Category:       install
>Synopsis:       sysinst(8) should handle ptyfs itself
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    install-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Apr 28 02:40:00 +0000 2013
>Originator:     Izumi Tsutsui
>Release:        NetBSD 6.0 and -current
>Organization:
>Environment:
System: NetBSD 6.1_RC3 and -current
Architecture: all
Machine: all
>Description:
Since around NetBSD 6.0_RC1, old style pty device nodes
(/dev/[pt]typ0 etc.) has been deprecated and they are
no longer created by the default "MAKEDEV all" target.

On the other hand, sysinst(8) implicitly requires a pseudo tty
during installation, but not all MD installation environments
handle mount_ptyfs(8) or prepare compat pty nodes properly,
as filed in PR/46812 and PR/47123.

Now it turns out hp300 install RAMDISK kernels in netbsd-6-0
and netbsd-6 still have the same issue.
(no "ipty" target in distrib/hp300/ramdisk/Makefile,
 and I'm working on it)

For future releases (i.e. 7.0), we can fix it by
- create old style 'ipty' nodes in *all* possible RAMDISK
- add mount_ptyfs(8) in all possible ramdisk or miniroot
  and mount it in .profile script etc. before sysinst is invoked 
but in that way we have to check a lot of MD installation stuff
that could still be missed as the hp300 case.

To make MD changes minimum, I'd like to make sysinst(8) binary
check /dev/pts and handle mount(MOUNT_PTYFS) op in it
as mount_ptyfs(8) does if openpty(2) fails
http://nxr.netbsd.org/xref/src/sbin/mount_ptyfs/mount_ptyfs.c?r=1.10#210
so that we don't have to sweep all possble MD ramdisk lists and
startup .profile scripts and we can remove old depricated
compat pty stuff in installation environments.

The rest work is to enable "file-system PTYFS" in all possible
MD installation kernels, but we can check it much easier than
messy MD stuff in src/distrib.

See also discussion in PR/46812.

>How-To-Repeat:
See PR/46812 and PR/47123.

>Fix:
Suggested as the above, though we needs more discussion.



Home | Main Index | Thread Index | Old Index