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, ISA,...) 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 solved. -- Joost
