udev/systemd 186 is out

[Armin]

​http://www.freedesktop.org/software/systemd/ Available there. I haven't found any switch on how to disable systemd nor how to install just udev.

[bdubbs@…]

I was able to build with:

    ./configure --prefix=''         \
                --disable-acl       \
                --disable-tcpwrap   \
                --disable-hostnamed \
                --disable-timedated \
                --disable-localed   \
                --disable-coredump  \
                --disable-gudev     \
                --disable-keymap    \
                --disable-audit     \
                --disable-ima       \
                --disable-introspection \
                --disable-gtk-doc-html  \
                --enable-split-usr      &&
    make                                &&
    make DESTDIR=/tmp/systemd install

I could not use --disable-logind because one program failed to link. We probably need to add --with-usb-ids-path=no and --with-pci-ids-path=no.

I was able to find most of the programs so we would need to do a manual install of only what we need.

Build time on my system was 99 seconds vs 14 for udev. :(

./lib/libudev.so.1.0.0
./lib/libudev.a
./lib/pkgconfig/libudev.pc
./lib/libudev.so
./lib/libudev.so.1
./lib/libudev.la
./bin/udevadm
./libexec/udev
./libexec/udev/rules.d/50-udev-default.rules
./libexec/udev/rules.d/95-udev-late.rules
./include/libudev.h
./etc/udev
./etc/udev/udev.conf
./share/pkgconfig/udev.pc
./share/man/man7/udev.7
./share/man/man8/systemd-udevd.8
./share/man/man8/udevadm.8
./usr/lib/systemd/systemd-udevd
./usr/lib/udev

systemd-udevd needs to be renamed and the man files edited. Notice that they put two .pc files in different directories.

The only programs we need are udevd and udevadm. We also need libraries, rules, .pc files, etc. I'll chcke my looks to see what udev-182 installed.

I have not tried in a Chapter 6 chroot environment, but it's looking like it's doable, even if it is a PITA.

[Bryan Kadzban]

Replying to bdubbs@…:

We probably need to add --with-usb-ids-path=no and --with-pci-ids-path=no.

Note that current udev (well... v180, the last one I tried) tries to read in the file "no" with that switch, contrary to autoconf convention where the special value "no" disables the feature. The flag is not (or, it was not) not actually disabling anything.

I don't *believe* this has changed, but I don't know for sure.

You can see for sure with e.g. "udevadm test /sys/class/net/eth0", and look for a "udev_rules_apply_to_event" line looking for the 'pci-db' builtin. Or look for an error message about failing to open the database file, either way.

Anyway, not extremely relevant, but if this is still broken, it might be a reasonable time to remove the flags if we don't want to fix the configury.

Commentary on the file list below...

./lib/pkgconfig/libudev.pc

Shouldn't this be /usr/lib? Same for the .la file?

./libexec/udev/rules.d/50-udev-default.rules

I thought the udev ABI (which the developers made a huge deal about back during the 32-bit to 64-bit migration days, when people were trying to create /lib64/udev) required that this be /lib/udev/rules.d?

./include/libudev.h

This should be /usr as well I believe.

./share/pkgconfig/udev.pc ./share/man/man7/udev.7 ./share/man/man8/systemd-udevd.8 ./share/man/man8/udevadm.8

All four of these belong in /usr/share, since /share doesn't exist.

[DJ Lucas]

Replying to bryan@…:

Replying to bdubbs@…:

We probably need to add --with-usb-ids-path=no and --with-pci-ids-path=no.

Note that current udev (well... v180, the last one I tried) tries to read in the file "no" with that switch, contrary to autoconf convention where the special value "no" disables the feature. The flag is not (or, it was not) not actually disabling anything.

I don't *believe* this has changed, but I don't know for sure.

--with-* should have a corresponding --without-* (which sets the value to 'no'). If not, then the flag should not use the "--with-" prefix (I was recently set straight on this on the icedtea list). We should ask for this to be fixed upstream (you'll need a 'no' case in configure.ac or the name of the flag should be changed). Please note that given upstream's fairly rigid history of "that's the way it is," the likely outcome is that usbutils will become a required dependency and we'll probably end up working around it ourselves anyhow. :-)

[ken@…]

Replying to bryan@…:

Replying to bdubbs@…:

We probably need to add --with-usb-ids-path=no and --with-pci-ids-path=no.

Note that current udev (well... v180, the last one I tried) tries to read in the file "no" with that switch, contrary to autoconf convention where the special value "no" disables the feature. The flag is not (or, it was not) not actually disabling anything.

I don't *believe* this has changed, but I don't know for sure.

You can see for sure with e.g. "udevadm test /sys/class/net/eth0", and look for a "udev_rules_apply_to_event" line looking for the 'pci-db' builtin. Or look for an error message about failing to open the database file, either way.

Still like this on my latest DESTDIR install of 183. Does it cause a problem ? Given upstream's attitude, I don't think raising or fixing this particular issue is urgent - unless it breaks something. There are enough other awkwardnesses (see my next response)

[ken@…]

I've now altered my configure options to try to get it to behave, but with only partial success. This is on a completed LFS-7.1 desktop.

First, a sed to change the name of the daemon from systemd-udevd back to udevd. Worked, but a more general sed broke the creation of the udevd manpage.

sed -i 's/systemd-\(udevd\$\)/\1/' Makefile.in

with hindsight, this barely scratches the surface of hte problems. See suggestion a little later.

Second, change some of the directory switches

--prefix=/usr libexecdir=/lib --bindir=/sbin --sysconfdir=/etc

This puts most things in the right places. The /sbin is for udevadm which otherwise goes to /bin or /usr/bin. Udevd is linked ok.

Unfortunately, udevd and all the helper routines (accelerometer, ata_id, cdrom_id, collect, mtd_probe, scsi_id, v4l_id) are *still* in /usr/lib.

There are a load of manpages, Only init.1 will overwrite a desired page.

The required pages need some seds: systemd-udevd.8 needs to be renamed and have all its systemd-udevd, SYSTEMD\-UDEVD, systemd\-udevd changed. udev.7 needs to change systemd-udevd in 'See Also'.

Beyond this, there are directories and files scattered around in the places where a gnome desktop would expect them.

For once, I suggest that we should consider doing a DESTDIR install to /tmp, then manually install the few things that we actually want by renaming, moving, and also sedding the manpages, then follow with ldconfig.

Note that I haven't tried to build this in chroot, there might be other issues with dependencies.

I'm also not suggesting that we use /libexecdir because that would need a gratuitous bootscript change, quite apart from any other concerns it will raise.

[ken@…]

Replying to ken@…:

Unfortunately, udevd and all the helper routines (accelerometer, ata_id, cdrom_id, collect, mtd_probe, scsi_id, v4l_id) are *still* in /usr/lib.

Note that cdrom_id needs libudev.so.1, so that will also need to be moved to /lib and the symlinks fixed up.

[bdubbs@…]

I've been thinking about this and am going to do a new build to check the dependencies.

It's possible that we may need to do a DESTDIR install, but we might just want to do a ./configure && make and then add our own mkdir/cp/install of appropriate files from there.

We could also create a Makefile.lfs for the install and do make -f Makefile.lfs install.

As far as the man pages go, we may want to create a patch instead of a sed to get the man pages right.

I don't look at this as an immediate problem. AFAIK, there's nothing wrong with keeping udev-182 until we get it figured out.

[ken@…]

Thought I'd just updated this, then noticed the email of Bruce's comment, came back, realised I haven't updated it : too tired.

My comment about moving the helpers was wrong - they are found by udevd because the location is coded into the programs, so moving them would break that. The following flags do the right thing (libexecdir is for udev/{devices,rules.d})

--prefix=/usr --with-rootprefix='' --bindir=/sbin --libexecdir=/lib --sysconfdir=/etc

udevd will install as /lib/systemd/systemd-udevd but we can move it.

I haven't looked at the details of doing our own install without a staging DESTDIR, but it sounds feasible.

However, for the two manpages I think a three-line sed to fix them up should be straightforward and easy enough to explain.

[Bryan Kadzban]

It's possible that we may need to do a DESTDIR install, but we might just want to do a ./configure && make and then add our own mkdir/cp/install of appropriate files from there.

Note that slackware (...I think anyway...) is doing the DESTDIR approach, although I think either should work. (Assuming udev doesn't do too much libtool; if it does, we may have to do some "./libtool --mode=install install -m<whatever> <binary wrapper script or .la file> <path>" (IIRC) magic to get the real files, instead of the libtool wrapper script or .la file. This might be problematic for libudev.)

​http://connie.slackware.com/~rworkman/standalone-udev-from-systemd/udev.SlackBuild

(Pulled from linux-hotplug.)

The following flags do the right thing (libexecdir is for udev/{devices,rules.d})

Isn't that really similar to the flags we're using today? Maybe we should just pull all of those in and call it a day. :-)

[ken@…]

For the man pages (without renaming until after the build/install), the slackware sed isn't enough to catch the systemd\- items in the text, nor the SYSTEMD\- header on systemd-udevd.8. The following sed fixes all of this, and (applied before configure) doesn't break the build.

sed -i -e "s,systemd.*-,,g" \
    -i -e "s,SYSTEMD.*-,,g" man/udev.7 man/udevadm.8 man/systemd-udevd.8

[Armin]

Version increment to 184

[bdubbs@…]

Replying to Krejzi:

Version increment to 184

I think we cna expect a lot of churn right now.

[Armin]

Version increment to 185

[Armin]

Version increment to 186

[bdubbs@…]

What I plan on doing is creating a custom Makefile.lfs. The instructions will then be only:

# As we do now
tar -xvf ../udev-config-20100128.tar.bz2
install -dv /lib/{firmware,udev/devices/pts}
mknod -m0666 /lib/udev/devices/null c 1 3

# And then
make -f Makefile.lfs &&
make -f Makefile.lfs install

It's interesting to note that developers use autotools that are designed for multiple architectures like solaris and aix when applications like udev/systemd are quite linux specific.

[Armin]

Hm, I don't think those files/directories in /lib/udev/devices are necesary. I don't have those and also I have all the files and directories. Have you ever tried running udev without them present? Also, I think that since udev 181 or 182 firmware is expected to be in /usr/lib/firmware for some reason, even tough udev's configure says it is set to /lib/firmware. I had the issue of not loading the firmware for radeon and r8169 because they weren't in /usr/lib/firmware. I just created a symlink. I use 182 tough.

[Bryan Kadzban]

Replying to Krejzi:

Hm, I don't think those files/directories in /lib/udev/devices are necesary.

Yes, they are. They're copied by the udev bootscript now, not udev itself.

Not all of them may be necessary at system boot time (devtmpfs *MIGHT* work there), but some (/dev/std*) are necessary for other programs, and are not created by udev or the kernel.

Also, I think that since udev 181 or 182 firmware is expected to be in /usr/lib/firmware

WFM in /lib. Are you sure you configured it correctly? Many of the configure commands present in this bug and on lfs-dev don't pick up all the flags that we used with -182 in the current /development/ book. (Though obviously none of this applies to Bruce's custom makefile. I *assume* he's set all the definitions correctly there.)

[Armin]

Replying to bryan@…:

Replying to Krejzi:

Hm, I don't think those files/directories in /lib/udev/devices are necesary.

Yes, they are. They're copied by the udev bootscript now, not udev itself.

Not all of them may be necessary at system boot time (devtmpfs *MIGHT* work there), but some (/dev/std*) are necessary for other programs, and are not created by udev or the kernel.

the /dev/std* ones are not present by default there. I was talking about /lib/udev/devices/null and /lib/udev/devices/pts ... Those are always present without any creation iirc. And devtmpfs is *required* for udev now and it works (tm).

Also, I think that since udev 181 or 182 firmware is expected to be in /usr/lib/firmware

WFM in /lib. Are you sure you configured it correctly? Many of the configure commands present in this bug and on lfs-dev don't pick up all the flags that we used with -182 in the current /development/ book. (Though obviously none of this applies to Bruce's custom makefile. I *assume* he's set all the definitions correctly there.)

First of all, I did not use LFS instructions to build it, but some customised BLFS ones. configure correctly set firmware dir to /lib/firmware but it didn't work. And if it makes life easier, same problem was encountered by an user on LFS IRC. He just said his firmware won't load even tough it is present in /lib/firmware. I told him to try to symlink /usr/lib/firmware to /lib/firmware and then the firmware started loading.

[bdubbs@…]

This discussion is about the existing instructions. That's OK and I'll check them all out when after I get the actual Makefile.lfs crafted. For what I want to do I'm finding it a bit tricky. For me, the shell script is easier, but in make, you need to think a little differently -- somewhat like lisp.

[Bryan Kadzban]

Replying to Krejzi:

And if it makes life easier, same problem was encountered by an user on LFS IRC. He just said his firmware won't load even tough it is present in /lib/firmware. I told him to try to symlink /usr/lib/firmware to /lib/firmware and then the firmware started loading.

Please don't paper over the problem with a symlink; LFS is *not* in the camp of "/usr must be the same partition as /", certainly not yet. Let's figure out why it's not working instead. (Though probably not on this bug.)

[bdubbs@…]

This was fairly involved as it needed coordinated changes to BLFS too.

Fixed as of revision 9908.