Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Canek Peláez Valdés]

On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol <mikemol@×××××.com> wrote:
> So, I botched the upgrade to udev-191. I thought I'd followed the
> steps, but I apparently only covered them for one machine, not both.
>
> The news item instructions specified that I had to remove
> udev-postmount from my runlevels. I didn't have udev-postmount in my
> runlevels, so I didn't remove it. Turns out, that dictum also applies
> to udev-mount. So after removing that[1], I was able to at least boot
> again.
>
> Udev also complained about DEVTMPFS not being enabled in the
> kernel.[2]  I couldn't get into X, but I could log in via getty and a
> plain old vt, so I enabled it, rebuilt the kernel, installed it and
> rebooted...and now that's presumably covered.
>
> I'm now able to get into X, but when I try to run an xterm, it fails.
> Checking ~/.xsession_errors, I find:
>
> xterm: Error 32, error 2: No such file or directory
> Reason: get_pty: not enough ptys

Do you have CONFIG_LEGACY_PTYS=y?  If so, do you really need it? A
little over a year ago[1] I had an annoying issue for having that
option enabled in my kernel, with a lot of virtual ttys reported in
systemctl. This is a shot in the dark (I really don't know if it's
related to your problem), but perhaps having the LEGACY_PTYS option
enabled somehow depleted your available pseudo terminals (which any X
terminal needs to run)? I suppose screen is also out of the question
for the same reason.

> I find this bizarre, as I'd never had any trouble with xterm in this
> way before. What'd I do wrong, and how do I recover? I don't trust
> emerging at this point; I tried re-emerging udev, and I aborted after
> I saw an stderr line about failing to open a pty, even though portage
> does quiet builds for parallel building by default...so I doubt
> whatever emitted that line on stderr was being properly guarded
> against the failure.

I don't see how an error about pseudo terminals could affect the
compilation. You could also try to compile with &> to a log file, and
prepare a binary package instead of installing it immediately. The log
file actually could help to find the problem.

[1] http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/3609

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México