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 <gentoo-user+bounces-129786-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1RF1ln-0006MV-3l
	for garchives@archives.gentoo.org; Sat, 15 Oct 2011 10:47:14 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 1E20F21C0EC;
	Sat, 15 Oct 2011 10:47:01 +0000 (UTC)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23])
	by pigeon.gentoo.org (Postfix) with SMTP id 8163B21C045
	for <gentoo-user@lists.gentoo.org>; Sat, 15 Oct 2011 10:46:00 +0000 (UTC)
Received: (qmail invoked by alias); 15 Oct 2011 10:45:59 -0000
Received: from p5B085C58.dip.t-dialin.net (EHLO pc.localnet) [91.8.92.88]
  by mail.gmx.net (mp043) with SMTP; 15 Oct 2011 12:45:59 +0200
X-Authenticated: #13997268
X-Provags-ID: V01U2FsdGVkX19+aRkpssh+ZRtRIPCGGncMNlT1BSorob7vO7fwNy
	O1PFHlIZCSE3ES
From: Michael Schreckenbauer <grimlog@gmx.de>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Apologize to everyone for my nonprofessional
Date: Sat, 15 Oct 2011 12:45:59 +0200
Message-ID: <1559098.M7SR0hh33e@pc>
User-Agent: KMail/4.7.2 (Linux/2.6.38-gentoo; KDE/4.7.2; x86_64; ; )
In-Reply-To: <CADPrc82RP51u2Zyu7iUO=vgkeXHEfZTTWpd5587MtoVoQPhr4Q@mail.gmail.com>
References: <tencent_37F5F8956D61083C1D2D5307@qq.com> <2025295.2eY0pAzGXv@pc> <CADPrc82RP51u2Zyu7iUO=vgkeXHEfZTTWpd5587MtoVoQPhr4Q@mail.gmail.com>
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
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-Y-GMX-Trusted: 0
X-Archives-Salt: 
X-Archives-Hash: d6e8a10433cec3e53cf86ce9e5e24934

On Saturday, 15. October 2011 03:34:27 Canek Pel=E1ez Vald=E9s wrote:
> On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer <grimlog@gmx.=
de>=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
> >> <grimlog@gmx.de>
> >=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
> >> >> <grimlog@gmx.de>
> >> >=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
>=20
> 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=20=

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=20
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.ru=
les=20
does.
Yet you claim, that *I* don't know my system.
I'd say, do your homework, then we can talk.

> Regards.

Best,
Michael