From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SXJqz-0008FS-Lc for garchives@archives.gentoo.org; Wed, 23 May 2012 22:16:25 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 49755E079D; Wed, 23 May 2012 22:16:08 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by pigeon.gentoo.org (Postfix) with ESMTP id BB807E0777 for ; Wed, 23 May 2012 22:14:48 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so4707884wib.10 for ; Wed, 23 May 2012 15:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:organization :x-mailer:mime-version:content-type:content-transfer-encoding; bh=toVxOKs19i2QT62QhHP88o1w1NrPAl99ZPenmAY4ao0=; b=vjd38KYKRmm/9EobOyTIY+ardzGPhW5VWv33y4Ir4R+aY2O5J8CkhOf7DrauhidpYE lK5pV3itWe1LMok7saLRYOhCe21EuykaWIxsCRoUDQUShOFqNrc83cKoh3wpDqp0zm3z JjmDzC8PJvu+280TusxhNEAP7LtYLB6vOnr9MU9c91+gFofiXW+0BK3giAVGFtbOXqfM oCF730xFs8s5HVBizi5bS3NbyMgAwRy6jQHeYn3mDnRFTiUAcIPJD2NXMTgmj8LCR8xo sk/gIufaGEhNL81UlqrAezaoRGxCc4TmJK1fEFiTUNE8T82LrRXKS1EgL0/I8YNPXRBw wjUw== Received: by 10.180.7.133 with SMTP id j5mr50119698wia.14.1337811287919; Wed, 23 May 2012 15:14:47 -0700 (PDT) Received: from khamul.example.com (196-215-114-166.dynamic.isadsl.co.za. [196.215.114.166]) by mx.google.com with ESMTPS id gv7sm26302838wib.4.2012.05.23.15.14.44 (version=SSLv3 cipher=OTHER); Wed, 23 May 2012 15:14:46 -0700 (PDT) Date: Thu, 24 May 2012 00:11:32 +0200 From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] udevd boot messages Message-ID: <20120524001132.323a8581@khamul.example.com> In-Reply-To: <4FBD5C8F.5040705@gentoo.org> References: <4FBA07BB.6070807@gmail.com> <4FBA50BA.4050301@hadt.biz> <4FBAAD05.8040201@gentoo.org> <4FBD0F26.2010400@libertytrek.org> <4FBD55D1.9000508@gentoo.org> <20120523234750.200ecdd6@khamul.example.com> <4FBD5C8F.5040705@gentoo.org> Organization: Internet Solutions X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; 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: 3d60c420-17d7-4160-9ad3-297121b24864 X-Archives-Hash: 73ebe5342db76439b4847827e93deed8 On Wed, 23 May 2012 22:54:23 +0100 Markos Chandras wrote: > On 05/23/2012 10:47 PM, Alan McKinnon wrote: > > On Wed, 23 May 2012 22:25:37 +0100 > > Markos Chandras wrote: > > > >> On 05/23/2012 05:24 PM, Tanstaafl wrote: > >>> On 2012-05-21 5:00 PM, Markos Chandras > >>> wrote: > >>>> On 05/21/2012 03:27 PM, Michael Hampicke wrote: > >>>>>> I updated udev from 171-r5 to 171-r6 and now i get several > >>>>>> udevd boot message as : udevd[1389]: can not find > >>>>>> '/lib/udev/rules.d/90-network.rules': No such file or directory > >>>>>> udevd[1389]: can not find '/lib/udev/rules.d/95-keymap.rules': > >>>>>> No such file or directory ...................... and so on. > >>>>>> > >>>>>> /lib is a symlink pointing to /lib64. /lib64/udev/rules.d is ok > >>>>>> with all the rules that udevd does not find at boot. > >>>>> > >>>>> No I would guess it was because of the upgrade of > >>>>> sys-apps/baselayout to 2.1-r1. Things got crazy here with that > >>>>> upgrade. I had to re-merge every package with files under /lib/ > >>>>> In your case re-merging udev should to the trick. > >>> > >>>> The package clearly informed you that you need to reboot for > >>>> things to work properly > >>>> > >>>> "You should reboot the system now to get /run mounted with > >>>> tmpfs!" > >>>> > >>>> Have a look on pkg_postinst() function in that ebuild. You chose > >>>> to ignore it and this is why you had these problems after the > >>>> update. > >>> > >>> > >>> I asked about this a while back but never got a decent answer... > >>> > >>> *Especially* for servers, there really, REALLY needs to be a way > >>> to see this kind of warning BEFORE updating... ie, the warning > >>> should be printed to the screen during an 'emerge -pvuDN world' or > >>> something, so I know that a reboot will be required for this > >>> update. > >>> > >> This kind of messages are also printed at the end of -uDNav world > >> so if you scroll your screen up you can see all the warning/log > >> messages from every package that you have updated. Also, these > >> kind of messages are logged in /var/log/portage/ > > > > You are missing the point. > > > > Tanstaafl wants to know if a reboot *will* be required *before* he > > does the update. What you are describing tells him that after the > > update completes when it is already too late. > > > > I face the same issue at work. We have a change policy requiring 14 > > days advance notice of any change affecting service. If I do a > > routine world update then have to log an emergency change for an > > unexpected reboot, the change manager will have my nuts for > > breakfast. > > > > If it happens more than once, I'd be having a really unusual > > conversation with the CTO which probably ends with him standing > > behind me watching while I migrate every single box that isn't > > RHEL6 (all 200 of them) over to RHEL6 where I *do* have exact > > knowledge in advance of the impact of a change. > > > > > > > Did either of you ever open a bug about this or even discuss it in the > gentoo-dev mailing list? What you say sounds like a valid concern to > me but unless you express your needs to maintainers, nothing is ever > going to happen. However, in this particular case, yes a news item > would be the ideal solution. I haven't opened a bug myself, mostly because I've never been bitten by this. My Gentoo servers run stable so I've always known from this list and other places when something requiring a reboot is coming down the line. I agree, a news item is the perfect solution. Having portage do it will be highly cumbersome, it will require some kind of new magic flag in ebuilds that portage must parse. All that work for something that doesn't happen often? Nah, it'll never fly. -- Alan McKinnnon alan.mckinnon@gmail.com