From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A76711387F7 for ; Sat, 2 Feb 2013 15:21:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 093D021C012; Sat, 2 Feb 2013 15:21:17 +0000 (UTC) Received: from mx.virtyou.com (mx.virtyou.com [178.33.32.244]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6D95BE0329 for ; Sat, 2 Feb 2013 15:21:15 +0000 (UTC) Received: by mx.virtyou.com (Postfix, from userid 65534) id 25C55DC05C; Sat, 2 Feb 2013 16:21:14 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on pri.ms X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 Received: from weird.wonkology.org (ip-88-153-77-34.unitymediagroup.de [88.153.77.34]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx.virtyou.com (Postfix) with ESMTPSA id A0058DC04D for ; Sat, 2 Feb 2013 16:21:11 +0100 (CET) Date: Sat, 2 Feb 2013 16:21:10 +0100 From: Alex Schuster To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] udev-191 bit me. Insufficient ptys Message-ID: <20130202162110.1623aaa5@weird.wonkology.org> In-Reply-To: References: X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.14; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 25ce4d94-4d5d-4861-8341-868763760a81 X-Archives-Hash: 9a91808a7d3692c414aba55ee6923572 Michael Mol writes: > 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. [...] > 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. Ran into the same problem, with my sister's PC. Which I had updated from remote, so I did not see the elogs. I do not think it is correct behaviour to continue building udev although the system wouldn't boot with that kernel option missing. I would expect the udev ebuild to check the running kernel for that option, and refuse to build until it has it set. Or until building is forced by some USE flag or an environment variable. Had these things not been handled better in the past? Alex