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 60ED513882D for ; Sun, 3 Feb 2013 17:52:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B590521C06A; Sun, 3 Feb 2013 17:52:00 +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 02F4B21C03A for ; Sun, 3 Feb 2013 17:51:58 +0000 (UTC) Received: by mx.virtyou.com (Postfix, from userid 65534) id 153B7DC054; Sun, 3 Feb 2013 18:51:56 +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 357D4DC04A for ; Sun, 3 Feb 2013 18:51:47 +0100 (CET) Date: Sun, 3 Feb 2013 18:51:45 +0100 From: Alex Schuster To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] udev-191 bit me. Insufficient ptys Message-ID: <20130203185145.4008d87f@weird.wonkology.org> In-Reply-To: <20130202211738.66a72582@khamul.example.com> References: <20130202162110.1623aaa5@weird.wonkology.org> <20130202211738.66a72582@khamul.example.com> 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: 47adf57a-3281-47ed-8fc6-e3f646c277a6 X-Archives-Hash: 0d7c73a7cf50ca056c0f9b046e6981ec Alan McKinnon writes: > On Sat, 2 Feb 2013 16:21:10 +0100 > Alex Schuster wrote: > > > Michael Mol writes: [system does not boot after UDEV upgrade] > > 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? > > There's a furious debate going on in -dev about this very thing, and > the bottom line is that your statements above are way too simplistic. > > - there is no guarantee that /proc/config.gz represents the kernel the > binary will actually run on (this emerge might well be the last > process you ever run on that kernel) > - there is no guarantee that /usr/src/linux corresponds to anything at > all (it's a symlink and can point to anything, even invalid stuff) > - there is no guarantee that the build host will run the code (think > build farms, crossdev etc, so every available config cannot possibly > be valid) > - and a couple more Sure, all this is not guaranteed. But IF there is a /proc/config.gz and a /usr/src/linux/.config without the DEVTMPFS entry, it is quite probable that the system will not boot. And I think a single line 'DEVTMPFS is not set in this kernel. Udev will not run.' along many others is not enough. > Basically, the only thing left for the ebuild devs is to notify the > user with the important information. That's okay with my PC I am sitting at. But on my sister's PC, I just logged in and started a world update, not monitoring the process all the time. She turned the thing off before I was able to read the elog, and she was surprised when it did not boot the next day. How should I have known what would happen? > The question is not whether to halt the build or not (that cannot and > will not be done) but how to do the communication: > > - news item There is one, from 2013-01-23, ending with 'Apologies if this news came too late for you.' Okay, if that one came a little earlier, I would have been fine. > - elog > - README > - some arb notice on a web site somewhere > ..... > > This is gentoo, the distro that does not hold your hand and gives you > every opportunity to keep both pieces. This is a good example of such. I'm using Gentoo for > 10 years now, and this is the first time such a thing has happened to me. Normally, the devs do quite a good job informing people about such changes that need to be dealt with, but this time I was not pleased. But I'll stop complaining. This incident just seems a little odd to me, unusual for Gentoo. Alex