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 1RF23O-0000ee-UM for garchives@archives.gentoo.org; Sat, 15 Oct 2011 11:05:23 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC94621C04B; Sat, 15 Oct 2011 11:05:13 +0000 (UTC) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by pigeon.gentoo.org (Postfix) with ESMTP id A3E1F21C022 for ; Sat, 15 Oct 2011 11:04:06 +0000 (UTC) Received: by wyf19 with SMTP id 19so4589629wyf.40 for ; Sat, 15 Oct 2011 04:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=I0CkMVVUOBQcnyFOmgxVkOszI43Cn2A4JQ9d1qBQeyI=; b=u62W+pSZqEYyqq/q3L3X90WnKt52nNTwo5VlUdpTLQnHgcO5qYvMR9RhTCEB0VvRMN VScISguEzOpjcOSoAPDNlYXAHF8x3CrrSkZ2zgwYkfzh1b566BJMLUNSDy2olWHSG7ei XTQSVDCDGLUY8sqQ3GsnSqcM3PnZVUojjoYG4= 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 Received: by 10.216.183.70 with SMTP id p48mr3986454wem.109.1318676645836; Sat, 15 Oct 2011 04:04:05 -0700 (PDT) Received: by 10.216.234.130 with HTTP; Sat, 15 Oct 2011 04:04:05 -0700 (PDT) In-Reply-To: <1559098.M7SR0hh33e@pc> References: <2025295.2eY0pAzGXv@pc> <1559098.M7SR0hh33e@pc> Date: Sat, 15 Oct 2011 04:04:05 -0700 Message-ID: Subject: Re: [gentoo-user] Apologize to everyone for my nonprofessional From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 01165842a4254febac83eacbfa05cf98 On Sat, Oct 15, 2011 at 3:45 AM, Michael Schreckenbauer wr= ote: > On Saturday, 15. October 2011 03:34:27 Canek Pel=C3=A1ez Vald=C3=A9s wrot= e: >> On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer > wrote: >> > On Saturday, 15. October 2011 02:47:26 Canek Pel=C3=A1ez Vald=C3=A9s w= rote: >> >> On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer >> >> >> > >> > wrote: >> >> > On Saturday, 15. October 2011 02:11:43 Canek Pel=C3=A1ez Vald=C3=A9= s wrote: >> >> >> On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer >> >> >> >> >> > >> >> > wrote: >> >> >> > On Saturday, 15. October 2011 01:42:10 Canek Pel=C3=A1ez Vald=C3= =A9s wrote: >> >> >> >> > /var/lib usually stores whole >> >> >> >> > databases. The difference is important and relevant." >> >> >> >> >> >> >> >> My systems has directories alsa, bluetooth, hp and many >> >> >> >> more >> >> >> >> there that are not databases at all. >> >> >> >> >> >> >> >> So? >> >> >> >> Which one? That /var is not going into /? >> >> >> > >> >> >> > No. That /var/lib contains databases. Is this so difficult >> >> >> > to get? >> >> >> >> >> >> I get it; it's just not relevant. >> >> >> >> >> >> > On my system /var/lib/alsa contains data, that alsa uses to >> >> >> > restore >> >> >> > mixer- levels. >> >> >> >> >> >> Yeah, it does. >> >> >> >> >> >> > So *my* /var/lib is used during boot and *my* /var/lib has >> >> >> > to be >> >> >> > mounted by the initramfs. >> >> >> >> >> >> No, it doesn't. What are you talking about? Look at >> >> >> /etc/init.d/alsasound: >> >> >> >> >> >> depend() { >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 need localmount >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 after bootmisc modules isapnp coldplug= hotplug >> >> >> } >> >> >> >> >> >> 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 would >> >> >> 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. >> >> >> >> >> >> 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. >> >> >> >> >> >> >That's the situation on nearly every gentoo system >> >> >> > >> >> >> > using sound >> >> >> >> >> >> Yeah, and as I explained, thanks to need localmount there is no >> >> >> problem. >> >> >> >> >> >> >(systemd might handle this different, I have no idea) >> >> >> >> >> >> Yeah, it does more intelligently: as I said, the volume >> >> >> restoring is >> >> >> only needed just before starting X. >> >> >> >> >> >> > Got it? Your system is not the center of the world. >> >> >> >> >> >> No, but I start to think you don't know *your* system. Check the >> >> >> alsasound init script. >> >> > >> >> > *lol* >> >> > Now, this is getting ridiculous. >> >> >> >> Indeed, it is getting ridiculous. >> >> >> >> > I don't know my system? >> >> >> >> No, you don't. >> >> >> >> > Have a look into >> >> > /lib/udev/rules.d/90-alsa-restore.rules >> >> > to realize, that this is a hack, that restores alsa-levels *twice* >> >> > on >> >> > systems that have /var/lib on /. The levels are supposed to be >> >> > restored by *udev* not the script. >> >> >> >> Yeah, but it doesn't run when udev *starts*. It runs when a card is >> >> *added* to the system; that is the reason for the ACTION=3D"add" part= . >> >> It's inteded to be used for USB cards (like external speakers with a >> >> little sound card incorporated), so its volume is restored *at insert >> >> time*. >> > >> > Nonsense. Action "add" is used for every device in your system, built-= in >> > or plugged in later. So this rule is not only used for >> > hotplug-USB-soundcards, but for every soundcard in your system. >> >> Yeah, you are right. Sorry. I forgot about the little numbers udev uses: >> >> 10-dm.rules >> 11-dm-lvm.rules >> 13-dm-disk.rules >> 60-persistent-storage.rules >> 70-persistent-net.rules >> 90-alsa-restore.rules >> >> 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. > > My 60-persisten-storage.rules creates device nodes. It does not mount > anything. Is your's different? > >> 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 /. > > So my devices nodes for harddisks exist, when alsa restores it's levels. = Does > not solve anything. > >> You guys keep speculating. > > We are speculating? > *You* were wrong about the assumtion that /var/lib contains databases. > *You* were wrong about the assumtion how action "add" works. > And *you* are wrong about the assumption, what 60-persistent-storage.rule= s > does. > Yet you claim, that *I* don't know my system. > I'd say, do your homework, then we can talk. I got that points wrong, I admit. I repeat, 3am here ;) I apogolize for saying that to you Michael; I shouldn't have, even if I would have been right (and I wasn't). Again, no excuse, but it's (actually) 4am here now. It doesn't change the fact that a) the system doesn't need /var/lib to boot (ALSA does, and it's only for the cosmetic reason of restore the volume, easily fixable latter in the boot process), and b) that nobody is proposing that /var should go in the same partition as /. In the end, my point is that either you would need an initramfs, or Zac's proposal, or /usr in the same partition as / (depending on the complexity of your setup). In any case, the fact is that, *as of now*, a /var inside / is not necessary for boot. The fact is, *nobody* is proposing nothing similar. And the fact is, with the *current* stack (and yeah, that includes the latest versions of systemd and udev and all the other crazy stuff), /var can happily live in its own partition, without an initramfs. Those are facts, and nobody can deny them. If you say that you fear that /var could no longer be allowed to be on its own partition in the future, well, you can analyze the situation that way, but there is not a single fact (or evidence) that supports that. The whole /run and /lock thing is proof that the developers want to keep /var on its own partition. And therefore, all speculation about forbidding a separated /var is that. Speculation. Regards. --=20 Canek Pel=C3=A1ez Vald=C3=A9s Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n Universidad Nacional Aut=C3=B3noma de M=C3=A9xico