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 /.
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 /.
And that's that.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
