Was it UNIX98 ptys, or /dev/pts filesystem? I know I have UNIX98 ptys built in on my kernel, and it works flawlessly. The only time I ran into the tmpfs issue was once when I actually forgot to compile in tmpfs, because I was actually looking for "tmpfs" in the filesystems section instead of it's proper name, which is "Virtual..." soemthing or another.

Hrmmm, I'm having the same problems now, except that I don't UNIX98 ptys enabled. I can't find anyplace to enable or disable /dev/pts filesystem anwhere either. Also can't find any reference to the tempfs in the menuconfig.

Hrmmm, I'm having the same problems now, except that I don't UNIX98 ptys enabled. I can't find anyplace to enable or disable /dev/pts filesystem anwhere either. Also can't find any reference to the tempfs in the menuconfig.

edit: ***Correction, I was blind. I found the /dev/pts stuff. I'm enabling to see if that helps

You should say Y here if you said Y to "Unix98 PTY support" above.
You'll then get a virtual file system which can be mounted on
/dev/pts with "mount -t devpts". This, together with the pseudo
terminal master multiplexer /dev/ptmx, is used for pseudo terminal
support as described in The Open Group's Unix98 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.

The GNU C library glibc 2.1 contains the requisite support for this
mode of operation; you also need client programs that use the Unix98
API. Please read Documentation/Changes for more information
about the Unix98 pty devices.

Note that the experimental "/dev file system support"
(CONFIG_DEVFS_FS) is a more general facility.

The last sentence is why /dev/pts looks neccessary to disable to use devfs correctly. Still very weird though. Whatever works, though...

I have /dev/pts disabled, and tmpfs enabled, and all is fine for my Blade system.

Well, I've had /dev/pts and tmpfs enabled, and I've been having the same problems with a fresh install on an Ultra10. It's definitely kernel config enabled, since the kernel from the install disk boots just fine. I'm rebuilding with /dev/pts off and tmpfs on right now; I'll followup with results.

It would be nice if the install guide had a "these kernel config settings must be like so" section...

The red warning following Code Example 17.2 in the x86 install states this:

Quote:

Warning: For your kernel to function properly, there are several options that you will need to ensure are in the kernel proper -- that is, they should be enabled and not compiled as modules. You will need to enable the "Code maturity level options --> Prompt for development and/or incomplete code/drivers" option to see several of these selections. Under the "File systems" section, be sure to enable the "Device File System" (note that you don't need to enable the "/dev/pts file system support" option). You'll also need to enable the "Virtual Memory Filesystem". Be sure to enable "ReiserFS" if you have any ReiserFS partitions; the same goes for "Ext3". If you're using XFS, enable the "SGI XFS filesystem support" option. It's always a good idea to leave ext2 enabled whether you are using it or not. Also, most people using IDE hard drives will want to enable the "USE DMA by default" option; otherwise, your IDE drives may perform very poorly. Of course, remember to enable "IDE disk" support as well -- otherwise your kernel won't be able to see your IDE disks.

It looks like they will need to add this for sparc systems as well. I believe a bug will need to be filed for this to get the documentation updated.