On Sat, Oct 15, 2011 at 3:34 AM, Canek Peláez Valdés <can...@gmail.com> wrote:
> On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer <grim...@gmx.de>
> wrote:
>> On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
>>> On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer <grim...@gmx.de>
>> wrote:
>>> > On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
>>> >> On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
>>> >> <grim...@gmx.de>
>>> >
>>> > wrote:
>>> >> > On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés 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() {
>>> >> need localmount
>>> >> 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="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.
>
> 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 /.
Mmmh. I got that one wrong; the persistent-storage rules just creates
the necessary symlinks, doesn't mount anything. (It's 3 am here, so I
should get sleep).
However, my point remains: the system boots correctly even if that
rule fails. It's not only non-fatal, it's pretty trivial and easily
fixable by the init system (like OpenRC and systemd does).
Even if this ALSA rule "requires" /var/lib, it doesn't means that it
requires /var in the same partition as /.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
