On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol <mike...@gmail.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