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 1R3NOU-0000aU-Ek for garchives@archives.gentoo.org; Tue, 13 Sep 2011 07:26:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DDD5721C32A; Tue, 13 Sep 2011 07:26:44 +0000 (UTC) Received: from smtpq3.tb.mail.iss.as9143.net (smtpq3.tb.mail.iss.as9143.net [212.54.42.166]) by pigeon.gentoo.org (Postfix) with ESMTP id 4019B21C042 for ; Tue, 13 Sep 2011 07:25:20 +0000 (UTC) Received: from [212.54.42.138] (helo=smtp7.tb.mail.iss.as9143.net) by smtpq3.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1R3NMt-0008KX-Br for gentoo-user@lists.gentoo.org; Tue, 13 Sep 2011 09:25:19 +0200 Received: from 5ed027a1.cm-7-1a.dynamic.ziggo.nl ([94.208.39.161] helo=data.antarean.org) by smtp7.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1R3NMr-0001Cb-TU for gentoo-user@lists.gentoo.org; Tue, 13 Sep 2011 09:25:17 +0200 Received: from localhost (localhost [127.0.0.1]) by data.antarean.org (Postfix) with ESMTP id 78AA2ED0 for ; Tue, 13 Sep 2011 09:25:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at antarean.org Received: from data.antarean.org ([127.0.0.1]) by localhost (data.antarean.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLofasUVek5E for ; Tue, 13 Sep 2011 09:25:17 +0200 (CEST) Received: from eve.localnet (eve.lan.antarean.org [10.20.13.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by data.antarean.org (Postfix) with ESMTPS id 9A787635 for ; Tue, 13 Sep 2011 09:25:17 +0200 (CEST) From: Joost Roeleveld To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] udev + /usr Date: Tue, 13 Sep 2011 09:25:15 +0200 Message-ID: <1774445.5FZghbAy0d@eve> User-Agent: KMail/4.7.1 (Linux/2.6.36-gentoo-r5; KDE/4.7.1; x86_64; ; ) In-Reply-To: References: <20110912150248.GB3599@acm.acm> <2307746.bmI8c8UP9m@pc> 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-ZiggoSMTP-MailScanner-Information: Please contact the ISP for more information X-ZiggoSMTP-MailScanner-ID: 1R3NMr-0001Cb-TU X-ZiggoSMTP-MailScanner: Found to be clean X-ZiggoSMTP-MailScanner-SpamCheck: geen spam, SpamAssassin (niet cached, score=-0.692, vereist 5, BAYES_00 -1.90, KHOP_DYNAMIC 0.73, RDNS_DYNAMIC 0.98, RP_MATCHES_RCVD -0.50) X-ZiggoSMTP-MailScanner-From: joost@antarean.org X-Spam-Status: No X-Archives-Salt: X-Archives-Hash: ddad9e93d00bf18716154775b272748e On Monday, September 12, 2011 04:07:46 PM Michael Mol wrote: > On Mon, Sep 12, 2011 at 3:41 PM, Michael Schreckenbauer =20 wrote: > > On Monday, 12. September 2011 15:18:53 Michael Mol wrote: > >> On Mon, Sep 12, 2011 at 3:07 PM, Michael Schreckenbauer > >> > >=20 > > wrote: > >> > On Monday, 12. September 2011 14:37:24 Canek Pel=E1ez Vald=E9s w= rote: > >> >> No fixable, in reality. The flexibility of udev is in part in > >> >> that the userspace can (and actually do) run arbitrary scripts > >> >> and binaries from udev rules. You can "fix" the ones that > >> >> require binaries in /usr *NOW*, but not forever, unless you > >> >> forbid the use of arbitrary binaries from udev rules. > >> >=20 > >> > Why do you need to run arbitrary scripts to mount /usr? > >>=20 > >> It's not specifically that you need to run arbitrary scripts to mo= unt > >> /usr. It's that it's unknown that /usr must be mounted before some= > >> hotplug events are handled. > >=20 > > Claiming "this is not fixable... unless you forbid the use of arbit= rary > > binaries from udev rules" implies, that you need to run arbitrary > > scripts to mount /usr. >=20 > No, it states that it's not solveable for the broadest set of cases (= I > hesitate to say 'universally') unless you can run arbitrary scripts > which may be in /usr. >=20 > Consider it possible that nfsd is needed to mount /usr. The > credentials needed for NFS to connect to the server are on an > encrypted partition. The key for decrypting that partition is stored > on a USB flash drive. The USB flash drive is formatted using a very > recent version of NTFS. FUSE is necessary to read that flash drive's > filesystem. >=20 > In this scenario, the NFS binaries and FUSE binaries are located unde= r /usr. Since when does NFS need credentials to connect to the server? :) also, why use NTFS on a flash-drive storing the keys, this is simply an= =20 example of someone trying to be clever and being far too lazy to proper= ly=20 implement it. It should fail and the error message should read: "PEBKAC" (Problem Exi= sts=20 Between Keyboard And Chair) > It's this kind of scenario that falls under the general class that > udev's trying to solve. If I understand it properly, the mentality is= , > "I can't forsee what distros and sysadmins will want to do, I get bug= > reports when peoples' configurations fail because they were trying to= > load things from unmounted filesystems, so if I say the filesystem > *must* be mounted (or they must use an initramfs) in order to use > udev, those bug reports will solve themselves." In other words, this dev has a god-complex and feels he should fix all = that is=20 wrong in this world. He should do his job and fix his error-reporting and documentation to s= pecify=20 that EITHER the people demanding this ensure the scripts run by udev wi= ll work=20 with only "/" mounted or ensure all other required partitions are mount= ed by=20 init*. Not force all partitions to be available when "init" starts. > > Otherwise a fix would be to mount /usr with whatever is needed to > > do this and then run the arbitrary scripts. Sadly udev does not sup= port > > this. > Which requires some kind of dependency or retry scheme, which adds > complexity to udev that the Fedora dev decided he didn't want to spen= d > the time on. Fixing the docs and error-reporting is the logical and least invasive o= ption. -- Joost