On Sat, Oct 15, 2011 at 3:45 AM, Michael Schreckenbauer <grim...@gmx.de> wrote:
> On Saturday, 15. October 2011 03:34:27 Canek Peláez Valdés 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.
>
> 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.rules
> 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.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
