Udev-178

[Matthew Burgess]

New version, and recent releases are now back on kernel.org. No release announcement as yet.

[Matthew Burgess]

Uggh, from ChangeLog: "require kmod >= 3". This package appears to be trying to replace module-init-tools. The required version of kmod was only announced last week at ​http://www.spinics.net/lists/hotplug/msg05256.html and it doesn't inspire confidence, e.g.:

In this version we added a new implementation of depmod, the only missing tool
to completely replace module-init-tools. We have only a couple of options
missing yet and need more testing, so I'd not say distros could start shipping
kmod instead of module-init-tools yet. This will probably be possible with the
next version.

I'll try bumping the book up to Udev-175 for the time being, and work out what's required for a kmod migration in due course.

[Bryan Kadzban]

Now -177, fixing a bug in the rule-generator installation.

​http://marc.info/?l=linux-hotplug&m=132634372931050&w=2

(And for -176, ​http://marc.info/?l=linux-hotplug&m=132631689022747&w=2)

Also, -176 now *requires* a devtmpfs on /dev (it no longer calls mknod(2) when it gets a uevent -- hello devfs, it's been a while!), not just an empty tmpfs mounted on /dev.

At minimum we'll need to change the kernel configuration requirements to specify devtmpfs support, and we'll need to change fstab to use it. We might need to change mountvirtfs as well (I don't remember offhand if it does a "mount /dev", or if it tries to specify the fstype).

We will almost assuredly need to muck with the ./configure flags as well, to get binaries and libraries into the right locations again. The INSTALL file is supposed to be correct, but it should be double checked I think.

(Yeah, it's great that they've bought into the freedesktop idea that if /usr is a separate partition, it needs to be mounted by the initramfs. Too bad that might require networking support in the initramfs, which might require /usr because those packages have bought into this idea as well. Argh.)

[bdubbs@…]

Replying to bryan@…:

Also, -176 now *requires* a devtmpfs on /dev (it no longer calls mknod(2) when it gets a uevent -- hello devfs, it's been a while!), not just an empty tmpfs mounted on /dev.

That does not seem to be a big deal.

At minimum we'll need to change the kernel configuration requirements to specify devtmpfs support, and we'll need to change fstab to use it. We might need to change mountvirtfs as well (I don't remember offhand if it does a "mount /dev", or if it tries to specify the fstype).

No, mountvirtfs does not mount /dev. Right now /dev is a part of / (e.g. a regular fs). That's probably a mistake.

We will almost assuredly need to muck with the ./configure flags as well, to get binaries and libraries into the right locations again. The INSTALL file is supposed to be correct, but it should be double checked I think.

I couldn't build -177 at all:

configure: error: Package requirements (libkmod >= 3) were not met:
No package 'libkmod' found

There doesn't seem to be a way around it. Considering the kmod announcement says "We have only a couple of options missing yet and need more testing, so I'd not say distros could start shipping kmod instead of module-init-tools yet."

I sent a message to linux-hotplug asking about it.

(Yeah, it's great that they've bought into the freedesktop idea that if /usr is a separate partition, it needs to be mounted by the initramfs. Too bad that might require networking support in the initramfs, which might require /usr because those packages have bought into this idea as well. Argh.)

It is too bad that they are reducing flexibility, but do you know of anyone mounting /usr over the network, or even via a separate partition. I don't know of any, but my visibility of what others are doing is limited.

[bdubbs@…]

This is an interesting link remotely related to this ticket.

​https://fedoraproject.org/wiki/Features/UsrMove

[Bryan Kadzban]

Replying to bdubbs@…:

No, mountvirtfs does not mount /dev. Right now /dev is a part of / (e.g. a regular fs). That's probably a mistake.

It's a tmpfs somehow or other... :-)

Oh, I see. udev mounts it (and specifies -t tmpfs). That's relatively easy to change assuming devtmpfs is in the kernel.

I sent a message to linux-hotplug asking about it.

The reply seems to be "it's not necessarily ready as a replacement for module-init-tools, but the library works when you compile udev against it".

Which means we could install libkmod alongside module-init-tools, at least until v4, and not use the binary that it creates when making manual changes to modules. (And in the loadmodules script.)

As for the rest, it only really matters if the NFS tools start to install into /usr themselves I think. (Given the contents of the UsrMove wiki page, it seems like this is the intended final result of this change. Whee.) Unless the intent is to include every binary and config file on the system into the initramfs, or I'm missing something...

[bdubbs@…]

Replying to bryan@…:

Replying to bdubbs@…:

No, mountvirtfs does not mount /dev. Right now /dev is a part of / (e.g. a regular fs). That's probably a mistake.

It's a tmpfs somehow or other... :-)

Oh, I see. udev mounts it (and specifies -t tmpfs). That's relatively easy to change assuming devtmpfs is in the kernel.

Yes, I think the 'mistake' is that /dev is mounted -n (--no-mtab) in udev and not added to mtab in mountfs. We just need to add

mount -f /dev

in the mountfs script.

[Bryan Kadzban]

Replying to bdubbs@…:

Yes, I think the 'mistake' is that /dev is mounted -n (--no-mtab) in udev and not added to mtab in mountfs. We just need to add

mount -f /dev

in the mountfs script.

Well, I think we should do whatever we do with /run, /proc, and /sys, with /dev as well: add it to fstab and put it into mountvirtfs. (Which I called mountkernfs before. Oops.) udev can keep copying from /lib/udev/devices, and creating symlinks and whatever, but it makes sense to me to put all the kernel-virtual FSes together.

[bdubbs@…]

Replying to bryan@…:

Replying to bdubbs@…:

We just need to add

mount -f /dev

in the mountfs script.

Well, I think we should do whatever we do with /run, /proc, and /sys, with /dev as well: add it to fstab and put it into mountvirtfs. (Which I called mountkernfs before. Oops.) udev can keep copying from /lib/udev/devices, and creating symlinks and whatever, but it makes sense to me to put all the kernel-virtual FSes together.

The above *does* do what we do for /proc and similar systems. Yes, it should be added to fstab too. There is no need to change the actual mount from udev to mountvirtfs. It makes more sense to mount it where it is first used (udev).

[Bryan Kadzban]

Replying to bdubbs@…:

There is no need to change the actual mount from udev to mountvirtfs. It makes more sense to mount it where it is first used (udev).

Hmm. Should that apply to /sys and /run and /proc then as well?

It is definitely true that nothing uses /sys until udev starts (hmm, and maybe not even udevd uses it; it might only be "udevadm trigger").

I don't believe anything uses /run until udev either (there are no earlier daemons, at least, which doesn't necessarily prevent anything from using it, but it seems likely).

It seems consolelog uses /proc, but then the mounting of /proc should be moved there. :-)

OTOH, many other scripts also use stuff in /proc, so to avoid having them all depend on consolelog, it makes more sense I think to leave /proc where it is. But then for consistency we should move the other virtual FSes (/sys, /run, and now /dev) into that script as well, and depend on it (via the Required-Start: header, which enforces an ordering on an LSB setup, not via anything that sysvinit currently does) from the places that need any of them.

(Lots of scripts run programs that use /dev -- udev is the obvious one, but also swap, checkfs, cleanfs, mountfs, udev_retry, sysklogd, and maybe a bunch in BLFS. Some of these care about the modifications udevd will make, but for example sysklogd does not. It just creates the /dev/log socket.)

--

Note also there are a few broken network drivers with udev-176 (...and I thought Kay knew about the presence of these before he committed the patch to remove timeout handling, but either he didn't, or he committed it anyway):

​http://thread.gmane.org/gmane.linux.network/217729

We might need a newer kernel, to get the fixed drivers.

[bdubbs@…]

Replying to bryan@…:

I don't believe anything uses /run until udev either

/run is used 3 lines after it is mounted:

log_info_msg "Mounting virtual file systems: ${INFO}/run"

[Bryan Kadzban]

Replying to bdubbs@…:

Replying to bryan@…:

I don't believe anything uses /run until udev either

/run is used 3 lines after it is mounted

The three lines after the execution of the mount binary, anyway. That's all totally unnecessary if /run is not actually set up as a tmpfs though, so at least in my mind it's all part of the single logical "set up the virtual FS" operation.

/sys is the biggest issue though. We really need to unify all the virtual FSes: either put them all in mountvirtfs, or put them all in the first script that uses them, and figure out a way to handle dependencies in case we add newer scripts that need them later.

[Bryan Kadzban]

Regarding kmod, again:

​http://marc.info/?l=linux-hotplug&m=132673432905420&w=2

We'll need to set --sysconfdir explicitly, at least until we decide to put everything in /usr -- if we decide that. That's not different from a lot of other programs, but it's not necessarily obvious that something is wrong if you already have module-init-tools installed. (Unless you use the pkg-user hint, where nobody is allowed to create /usr/etc. Heh. :-) )

[Matthew Burgess]

Now udev-178. Release announcement at ​http://www.spinics.net/lists/hotplug/msg05298.html.

[Matthew Burgess]

Fixed in r9711.