public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Joost Roeleveld <joost@antarean.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Apologize to everyone for my nonprofessional
Date: Sat, 15 Oct 2011 20:57:18 +0200	[thread overview]
Message-ID: <2051999.5WV1KllRKS@eve> (raw)
In-Reply-To: <CADPrc82RP51u2Zyu7iUO=vgkeXHEfZTTWpd5587MtoVoQPhr4Q@mail.gmail.com>

On Saturday, October 15, 2011 03:34:27 AM Canek Peláez Valdés wrote:
> On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer <grimlog@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
> >> <grimlog@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
> >> >> <grimlog@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

These only matter when there are conflicting rules in these files. The rule in 
the "lower" number is used. Higher numbers are then ignored.

> 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.

Wrong, see above.

> 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 /.

Wrong, /etc/init.d/alsasound is a fix for that.
Udev should handle the situation where filesystems are not available yet and 
keep those in a retry-queue for when all filesystems are available.

> 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 /.

/var will be required. alsasound is a workaround for this.

--
Joost



  parent reply	other threads:[~2011-10-15 18:58 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-14 15:43 [gentoo-user] Apologize to everyone for my nonprofessional Lavender
2011-10-14 15:52 ` Michael Mol
2011-10-14 16:15   ` Dale
2011-10-14 21:41     ` Neil Bothwick
2011-10-14 22:47       ` Dale
2011-10-15  5:10         ` Pandu Poluan
2011-10-15  6:56           ` Dale
2011-10-15  7:09             ` Pandu Poluan
2011-10-15  7:34             ` Canek Peláez Valdés
2011-10-15  7:50               ` Canek Peláez Valdés
2011-10-15  8:35                 ` Michael Schreckenbauer
2011-10-15  8:42                   ` Canek Peláez Valdés
2011-10-15  8:53                     ` Michael Schreckenbauer
2011-10-15  9:11                       ` Canek Peláez Valdés
2011-10-15  9:31                         ` Michael Schreckenbauer
2011-10-15  9:47                           ` Canek Peláez Valdés
2011-10-15 10:05                             ` Michael Schreckenbauer
2011-10-15 10:34                               ` Canek Peláez Valdés
2011-10-15 10:45                                 ` Michael Schreckenbauer
2011-10-15 11:04                                   ` Canek Peláez Valdés
2011-10-15 19:23                                     ` Michael Schreckenbauer
2011-10-15 10:49                                 ` Canek Peláez Valdés
2011-10-15 18:57                                 ` Joost Roeleveld [this message]
2011-10-15 23:25                     ` Mike Edenfield
2011-10-15  8:37               ` Dale
2011-10-15  9:02                 ` Canek Peláez Valdés
2011-10-15  9:15                   ` Michael Schreckenbauer
2011-10-15  9:21                     ` Canek Peláez Valdés
2011-10-15  9:32                       ` Michael Schreckenbauer
2011-10-15  9:49                         ` Canek Peláez Valdés
2011-10-15  9:37                       ` Dale
2011-10-15  9:54                         ` Canek Peláez Valdés
2011-10-15 17:23                           ` Dale
2011-10-15 14:23                   ` pk
2011-10-15 16:46                     ` Claudio Roberto França Pereira
2011-10-15 19:20                       ` Michael Schreckenbauer
2011-10-15 21:15                       ` Neil Bothwick
2011-10-15  9:53               ` Neil Bothwick
2011-10-15 10:10                 ` Canek Peláez Valdés
2011-10-15 11:31                   ` Neil Bothwick
2011-10-15 12:19                     ` Jonas de Buhr
2011-10-15 13:44               ` Alan McKinnon
2011-10-15 13:48               ` Alan McKinnon
2011-10-15 18:43               ` Joost Roeleveld
  -- strict thread matches above, loose matches on Subject: below --
2011-10-14 16:05 [gentoo-user] 回复: " Lavender
2011-10-17 12:45 ` du yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2051999.5WV1KllRKS@eve \
    --to=joost@antarean.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox