Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-dev@g.o
From: Joost Roeleveld <joost@...>
Subject: Re: udev and /usr
Date: Sun, 18 Sep 2011 17:22:42 +0200
On Saturday, September 17, 2011 06:40:03 PM Robin H. Johnson wrote:
> On Fri, Sep 16, 2011 at 10:36:27AM +0200, Joost Roeleveld wrote:
> (The other reason I think systemd and udev might merge at some point, or
> at least have good IPC between them, because there is a potential for
> speed gains there).

If udev and systemd merge, what will happen with people not using systemd?

I don't see any added benefit from using DBUS on my servers.

> > > udev runs that rule as soon as the hardware turns up, which is often
> > > before localmount.
> > 
> > I have doubts about having all these things handled by udev. As you
> > said,
> > there is an init-script that handles this. Is the ultimate goal to get
> > rid of init-scripts and have everything done automagically?
> The rule is really useful & important if you plug in a USB or Firewire
> sound card at some point after boot. If you already had it configured a
> previous time, that rule will restore your volume settings :-).

udev knows the sound card is removable (USB, Firewire,...) or "fixed" (PCI, 
For removable devices, yes, these extra scripts make sense. But why have this 
same mechanism forced with non-removable hardware as the same can easily (and 
already is) be handled by existing init-scripts that run after localmount?

> The other parts of that init script are valuable still, but the volume
> restore is just a crutch for failing to load the volume when the device
> was first detected. If you have a soundcard that makes a pop when your
> system boots, that's a bug caused by this.

My sound card doesn't pop, actually. So I guess I am lucky I don't see this 
bug on my system.

> > > Just because there are no visible errors, doesn't mean that they
> > > don't
> > > exist. This move to encourage initramfs is to ensure that there
> > > isn't
> > > any major breakage incidents soon. What if udev upstream suddenely
> > > starts hard requiring /usr to mounted, and not doing retries at all.
> > > How many systems are going to break, and users going to complain
> > > about
> > > needing to use livecds to recover?
> > 
> > A lot. And those will be very vocal.
> > I have a few goals with this thread and one of them is to try to figure
> > out how best to avoid users to get affected by this.
> For now, users having an initramfs ahead of time is the best option to
> avoid future breakages.

That, or have the logic of the initramfs in localmount and have udev wait till 
after localmount is run.

> > > DEVTMPFS creates the first batch, and udev creates the rest.
> > > 
> > > The deciding case then becomes:
> > > - Is the device for your /usr entry in fstab created by udev or
> > > 
> > >   something else?
> > > 
> > > MD: done by devtmpfs
> > > LVM: done by udev+lvm
> > > by-uuid/by-label: done by udev
> > > 
> > > by-uuid and by-label present a lot of annoyance to the minimal
> > > initramfs. We have to ensure that we explicitly support them, which
> > > has
> > > increased the complexity of the initramfs.
> > 
> > My /usr is on LVM. That requires udev.
> > 
> > My understanding is:
> > - udev needs /usr to be mounted to work
> Correct.
> > - udev is needed to sort out LVM to get access to /usr
> Incorrect. But perhaps not for the reason that you think.
> Using genkernel's initramfs here as an example, this is the sequence of
> LVM commands that run:
> vgscan
> vgchange -ay --sysinit
> That --sysinit part is important, as it tells LVM to avoid locking (and
> some interaction with udev), and then LVM has fallback code to create
> the symlinks and other device nodes in /dev. What udev CAN do is create
> all of the by-label/by-uuid bits above. The fallback code in LVM is very
> complex, just for the case of handling udev not being there yet.
> > And why can't this be implemented in localmount?
> /etc/init.d/lvm does it on your system.

Ok, so have localmount depend on /etc/init.d/localmount and the problem is 


Re: udev and /usr
-- Duncan
udev and /usr
-- Joost Roeleveld
Re: udev and /usr
-- Robin H. Johnson
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: udev and /usr
Next by thread:
Re: udev and /usr
Previous by date:
Re: udev and /usr
Next by date:
Re: Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.