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