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 1RF9RJ-0001zY-LN for garchives@archives.gentoo.org; Sat, 15 Oct 2011 18:58:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1678421C22E; Sat, 15 Oct 2011 18:58:25 +0000 (UTC) Received: from smtpq1.tb.mail.iss.as9143.net (smtpq1.tb.mail.iss.as9143.net [212.54.42.164]) by pigeon.gentoo.org (Postfix) with ESMTP id 20C4721C136 for ; Sat, 15 Oct 2011 18:57:25 +0000 (UTC) Received: from [212.54.42.149] (helo=smtp17.tb.mail.iss.as9143.net) by smtpq1.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1RF9QC-00062a-Il for gentoo-user@lists.gentoo.org; Sat, 15 Oct 2011 20:57:24 +0200 Received: from 5ed027a1.cm-7-1a.dynamic.ziggo.nl ([94.208.39.161] helo=data.antarean.org) by smtp17.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1RF9Q9-0008Vp-LS for gentoo-user@lists.gentoo.org; Sat, 15 Oct 2011 20:57:21 +0200 Received: from localhost (localhost [127.0.0.1]) by data.antarean.org (Postfix) with ESMTP id 3C037179E for ; Sat, 15 Oct 2011 20:57:35 +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 CLvJH4MtaxrY for ; Sat, 15 Oct 2011 20:57:33 +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 36ABB4B8 for ; Sat, 15 Oct 2011 20:57:33 +0200 (CEST) From: Joost Roeleveld To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Apologize to everyone for my nonprofessional Date: Sat, 15 Oct 2011 20:57:18 +0200 Message-ID: <2051999.5WV1KllRKS@eve> User-Agent: KMail/4.7.1 (Linux/2.6.36-gentoo-r5; KDE/4.7.1; x86_64; ; ) In-Reply-To: References: <2025295.2eY0pAzGXv@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: 1RF9Q9-0008Vp-LS X-ZiggoSMTP-MailScanner: Found to be clean X-ZiggoSMTP-MailScanner-SpamCheck: geen spam, SpamAssassin (niet cached, score=-0.615, vereist 5, BAYES_00 -1.90, KHOP_DYNAMIC 0.73, RDNS_DYNAMIC 0.98, RP_MATCHES_RCVD -0.50, TW_GD 0.08) X-ZiggoSMTP-MailScanner-From: joost@antarean.org X-Spam-Status: No X-Archives-Salt: X-Archives-Hash: 32c103f8d90c73677cc24f04f807307b On Saturday, October 15, 2011 03:34:27 AM Canek Pel=E1ez Vald=E9s wrote= : > On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer =20 wrote: > > On Saturday, 15. October 2011 02:47:26 Canek Pel=E1ez Vald=E9s wrot= e: > >> On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer > >> > >=20 > > wrote: > >> > On Saturday, 15. October 2011 02:11:43 Canek Pel=E1ez Vald=E9s w= rote: > >> >> On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer > >> >> > >> >=20 > >> > wrote: > >> >> > On Saturday, 15. October 2011 01:42:10 Canek Pel=E1ez Vald=E9= s wrote: > >> >> >> > /var/lib usually stores whole > >> >> >> > databases. The difference is important and relevant." > >> >> >>=20 > >> >> >> My systems has directories alsa, bluetooth, hp and many > >> >> >> more > >> >> >> there that are not databases at all. > >> >> >>=20 > >> >> >> So? > >> >> >> Which one? That /var is not going into /? > >> >> >=20 > >> >> > No. That /var/lib contains databases. Is this so difficult > >> >> > to get? > >> >>=20 > >> >> I get it; it's just not relevant. > >> >>=20 > >> >> > On my system /var/lib/alsa contains data, that alsa uses to > >> >> > restore > >> >> > mixer- levels. > >> >>=20 > >> >> Yeah, it does. > >> >>=20 > >> >> > So *my* /var/lib is used during boot and *my* /var/lib has > >> >> > to be > >> >> > mounted by the initramfs. > >> >>=20 > >> >> No, it doesn't. What are you talking about? Look at > >> >> /etc/init.d/alsasound: > >> >>=20 > >> >> depend() { > >> >> need localmount > >> >> after bootmisc modules isapnp coldplug hotplug > >> >> } > >> >>=20 > >> >> Look at the first need from alsasound depend: it says, that it > >> >> goes > >> >> after localmount. If you have /var in NFS (a very weird setup > >> >> for a > >> >> desktop machine) maybe it will cause problems: but then it woul= d > >> >> be > >> >> fault of OpenRC (or the alsasound init script). If /var is on a= > >> >> different partition, localmount will mount it and *then* > >> >> alsasound > >> >> will execute. > >> >>=20 > >> >> And it makes sense: the volume restoring doesn't matter until > >> >> immediately before running gdm and going into the desktop; of > >> >> course > >> >> you can mount /var before that. > >> >>=20 > >> >> >That's the situation on nearly every gentoo system > >> >> > > >> >> > using sound > >> >>=20 > >> >> Yeah, and as I explained, thanks to need localmount there is no= > >> >> problem. > >> >>=20 > >> >> >(systemd might handle this different, I have no idea) > >> >>=20 > >> >> Yeah, it does more intelligently: as I said, the volume > >> >> restoring is > >> >> only needed just before starting X. > >> >>=20 > >> >> > Got it? Your system is not the center of the world. > >> >>=20 > >> >> No, but I start to think you don't know *your* system. Check th= e > >> >> alsasound init script. > >> >=20 > >> > *lol* > >> > Now, this is getting ridiculous. > >>=20 > >> Indeed, it is getting ridiculous. > >>=20 > >> > I don't know my system? > >>=20 > >> No, you don't. > >>=20 > >> > Have a look into > >> > /lib/udev/rules.d/90-alsa-restore.rules > >> > to realize, that this is a hack, that restores alsa-levels *twic= e* > >> > on > >> > systems that have /var/lib on /. The levels are supposed to be > >> > restored by *udev* not the script. > >>=20 > >> Yeah, but it doesn't run when udev *starts*. It runs when a card i= s > >> *added* to the system; that is the reason for the ACTION=3D"add" p= art. > >> It's inteded to be used for USB cards (like external speakers with= a > >> little sound card incorporated), so its volume is restored *at ins= ert > >> time*. > >=20 > > Nonsense. Action "add" is used for every device in your system, bui= lt-in > > or plugged in later. So this rule is not only used for > > hotplug-USB-soundcards, but for every soundcard in your system. >=20 > Yeah, you are right. Sorry. I forgot about the little numbers udev us= es: >=20 > 10-dm.rules > 11-dm-lvm.rules > 13-dm-disk.rules > 60-persistent-storage.rules > 70-persistent-net.rules > 90-alsa-restore.rules These only matter when there are conflicting rules in these files. The = rule in=20 the "lower" number is used. Higher numbers are then ignored. > So, the same way that in the alsasound init script "need localmount" > guarantee that /var is mounted, the 60-persistent-storage.rules > guarantees that /var is mounted before the 90-alsa-restore.rules > restores ALSA's volume. Wrong, see above. > Again, there is no problem. Yeah, the rule is executed at udev > execution time... but after the persisten-storage rule. So, you see, > no problem. No need for /var in the same partition as /. Wrong, /etc/init.d/alsasound is a fix for that. Udev should handle the situation where filesystems are not available ye= t and=20 keep those in a retry-queue for when all filesystems are available. > You guys keep speculating. As of *now*, there is not a single line of= > code that prevents a system from booting correctly if /var lives in > another partition, no matter if the system uses an initramfs or not. > As of *now* nobody is discussing, proposing, or even mentioning > (except for you guys) about requiring /var to live in the same > partition as /. /var will be required. alsasound is a workaround for this. -- Joost