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 1R2fKC-0002TF-Th for garchives@archives.gentoo.org; Sun, 11 Sep 2011 08:23:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2F2D421C0C8; Sun, 11 Sep 2011 08:23:28 +0000 (UTC) Received: from basement.kutulu.org (187.250.102.97.cfl.res.rr.com [97.102.250.187]) by pigeon.gentoo.org (Postfix) with ESMTP id 3811D21C053 for ; Sun, 11 Sep 2011 08:22:05 +0000 (UTC) Received: from localhost (basement.kutulu.org [127.0.0.1]) by basement.kutulu.org (Postfix) with ESMTP id B947A12200E for ; Sun, 11 Sep 2011 04:22:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at kutulu.org Received: from basement.kutulu.org ([127.0.0.1]) by localhost (basement.kutulu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmDoUqLQe-72 for ; Sun, 11 Sep 2011 04:22:04 -0400 (EDT) Received: from [192.168.69.4] (wombat.kutulu.org [192.168.69.4]) by basement.kutulu.org (Postfix) with ESMTP id 280D4122004 for ; Sun, 11 Sep 2011 04:22:04 -0400 (EDT) Message-ID: <4E6C6FA8.1000002@kutulu.org> Date: Sun, 11 Sep 2011 04:22:00 -0400 From: Mike Edenfield User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110905 Thunderbird/7.0 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] /dev/sda* missing at boot References: <201108191109.34984.michaelkintzios@gmail.com> <20110910093659.2f2fdf58@rohan> <201109101124.15694.michaelkintzios@gmail.com> <4E6B8BB8.7040103@gmail.com> <20110910232815.11dc7b1b@rohan> In-Reply-To: <20110910232815.11dc7b1b@rohan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: X-Archives-Hash: 035e177c8e3bfa87d5f53bd809d322ae On 9/10/2011 5:28 PM, Alan McKinnon wrote: > On Sat, 10 Sep 2011 12:19:10 -0400 > Michael Mol wrote: > >> On Sat, Sep 10, 2011 at 12:09 PM, Dale wrote: >>> Mick wrote: >>> From my understanding, the dev is not listening. That is another >>> thing that bothers me. When devs stop listening to users, that >>> causes a problem. Remember hal? How many people complained early From what I read, he's listening, he just isn't being swayed by the argument. From his perspective, udev "doesn't support" a split /,/usr because of the arbitrarily complex udev rules. This is causing users to fill their bug queue with errors when needed binaries are unavailable at boot, and thus their hardware doesn't work. Apparently he has concluded that the number of people who require a separate /usr partition but cannot use an initramfs is smaller than the number of people who need udev to have access to all of /usr. Unfortunately it appears that he's taking a pretty extreme approach to solving the problem that will actually *break* the systems of that second group, which I don't quite understand the reasoning behind. >> As I understand it, nothing of udev itself is in /usr, but instead >> packages and scripts which plug themselves into udev to be triggered >> by various events. >> >> Perhaps the real solution is to circumvent udev and get those other >> packages and scripts to not put hotplug-active files under /usr. > > That's my understanding too, and I agree with your conclusions. The > distros can easily (give enough man-power) deal with this too - they > simply have to modify their rpms/debs/pkgs/ebuilds to install specific > identified things to / instead of /usr. They *already* do this for > packages that natively install to peculiar locations. It would make perfect sense to me for the udev maintainer to simply declare a split /,/usr "not supported" and let us deal with the issues. The problem, if I'm reading correctly, is that he's taken things one step further and decided to move udev *itself* back into /usr. Even still, I would think that a Gentoo patchset to revert the paths back to /lib would be a feasible workaround to this mess. --Mike