Re: [arch-general] [arch-dev-public] [signoff] udev-174-1

older
[arch-general] Can't upgrade GCC...

Myra Nelson

20 Oct 2011 20 Oct '11

7:41 a.m.

On Thu, Oct 20, 2011 at 02:00, Tom Gundersen wrote:

Hi Dave,

On Thu, Oct 20, 2011 at 3:09 AM, Dave Reisner wrote:

...
I'll push a new mkinitcpio this weekend to adjust for the path changes and the *_id helpers going away. It's not crucial as image creation continues to work just fine, but I'm sure there will be some noise about the missing file errors if I don't tag a new rel. I've also been meaning to get busybox 1.19.2 out, but it requires a minor change to init as well...

I forgot to warn about the ERRORS for missing files. They are harmless as you say, but a bit scary.

When you push the next busybox could you include the init app (if it is not already switched on). Also, what is the status of Thomas' cp -x patch? It would be nice to have that too for the shutdown hook (and hence the /usr hook) to finally work.

Cheers,

Tom

Error messages yes, but no warning about problems with the image and the image is created and boots fine. Keeping up with the mailing list makes all the difference in the world. Keep up the good work. Myra -- Life's fun when your sick and psychotic!

Show replies by date

clemens fischer

25 Oct 25 Oct

12:56 p.m.

New subject: [arch-general] [arch-dev-public] [signoff] udev-174-1

'uname -rms' -> "Linux 3.0.7-spott x86_64" On Thu-2011/10/20-09:41 Myra Nelson wrote:

...

Error messages yes, but no warning about problems with the image and the image is created and boots fine. Keeping up with the mailing list makes all the difference in the world.

My system broke with udev-174-1. I have rules renaming eth* according to their MACs for consistency, guarding against dependency on order-of-detection, plus rules to customize a wlan running on an USB device. These rules didn't run. Basically, there is one rule file[1] calling out to a number of local "simple" rules. These in turn are very short, containing only (LOCAL_) "RUN"/"NAME" commands. The main rule assembles a name out of subsystem, addresses, interfaces etc. This name points into a separate directory "/etc/udev-local" where the appropriate one- or two liners live, and there's a logging rule telling me what file names to use if there's anything missing. All this is less complex than eg. udisks and relies only on udevd. Are rules in /etc/udev ever called in the new version? Do I need some compatibility to make this happen? I didn't have the old udev package to downgrade to, but a backup from where the old binaries and lib/udev stuff could be restored. Otherwise I couldn't even post this. clemens [1] /etc/udev/rules.d/99-local-simple.rules # /root/udev-rules/99-local-simple.rules # == /etc/udev/rules.d/99-local-simple.rules # _date: 20091002-1615_ # see ENV{iam} = "99-local-simple" ENV{LOCAL_LOGG} = "/usr/bin/logger -p daemon.info --" ACTION == "add", ENV{.cmd} = "add", GOTO = "local_simple_check_subsys" ACTION == "change", ENV{.cmd} = "change", GOTO = "local_simple_check_subsys" ACTION == "remove", ENV{.cmd} = "remove", GOTO = "local_simple_check_subsys" GOTO = "local_simple_end" LABEL = "local_simple_check_subsys" SUBSYSTEM == "block", ENV{DEVTYPE} == "partition", GOTO = "local_collect_disk_args" SUBSYSTEM == "bluetooth", ENV{.subsystem} = "bluetooth", GOTO = "local_collect_if_args" SUBSYSTEM == "net", ENV{.subsystem} = "net", GOTO = "local_collect_if_args" SUBSYSTEM == "rfkill", ENV{.subsystem} = "rfkill", GOTO = "local_collect_if_args" GOTO = "local_simple_end" LABEL = "local_collect_disk_args" # should anybody have setup site specific values, get them IMPORT{parent} = "SPOTT_*" #IMPORT{parent} = "PCI_*" #IMPORT{parent} = "HID_*" IMPORT{parent} = "ID_*" ENV{.devtype} = "partition" ENV{.subsystem} = "block" ENV{ID_FS_TYPE} == "", ENV{LOCAL_EX} = "no filesystem", GOTO = "local_simple_exerr" ENV{ID_FS_UUID} == "", ENV{ID_FS_LABEL} == "", ENV{LOCAL_EX} = "neither label nor uuid", GOTO = "local_simple_exerr" ENV{ID_FS_UUID} == "?*", ENV{.fs} = "$env{ID_FS_TYPE}-$env{ID_FS_UUID}" ENV{ID_FS_LABEL} == "?*", ENV{.fs} = "$env{ID_FS_TYPE}-$env{ID_FS_LABEL}" ENV{.devid} = "$env{.devtype}-$env{.fs}" ENV{LOCAL_EX} = "$env{.cmd} $env{.subsystem} $env{.devid}" ENV{LOCAL_LOGG} == "?*", RUN += "$env{LOCAL_LOGG} $env{iam}: msg: $env{LOCAL_EX}" GOTO = "local_get_controls" LABEL = "local_collect_if_args" # should anybody have setup site specific values, get them IMPORT{parent} = "SPOTT_*" #IMPORT{parent} = "PCI_*" #IMPORT{parent} = "HID_*" IMPORT{parent} = "ID_*" ENV{.devtype} = "unknown" ATTR{address} == "?*", ENV{.devtype} = "$attr{address}" ENV{.devtype} == "unknown", ATTR{name} == "?*", ENV{.devtype} = "$attr{name}" #ENV{.devtype} == "unknown", ENV{PRODUCT} == "?*", ENV{.devtype} = "$env{PRODUCT}" ENV{.devtype} == "unknown", ENV{.devtype} = "$kernel" ENV{.devid} = "$env{.devtype}" ENV{LOCAL_EX} = "$env{.cmd} $env{.subsystem} $env{.devid}" ENV{LOCAL_LOGG} == "?*", RUN += "$env{LOCAL_LOGG} $env{iam}: msg: $env{LOCAL_EX}" #GOTO = "local_get_controls" LABEL = "local_get_controls" # to make all this configurable, either an external program or the # "test-trick" is necessary, because the "==" operator can only match on # literals! ENV{LOCAL_DEV} = "/etc/udev-local/$env{iam}-$env{.subsystem}-$env{.devid}-$env{.cmd}" TEST != "$env{LOCAL_DEV}", ENV{LOCAL_EX} = "no $env{LOCAL_DEV}", GOTO = "local_simple_exerr" IMPORT = "$env{LOCAL_DEV}" ENV{LOCAL_LOGG} == "?*", RUN += "$env{LOCAL_LOGG} LOCAL_DEV:$env{LOCAL_DEV} LOCAL_RUN:$env{LOCAL_RUN}" ENV{LOCAL_OPT_last_rule} == "?*", GOTO = "local_simple_lastrule" ENV{LOCAL_GROUP} == "?*", GROUP = "$env{LOCAL_GROUP}" ENV{LOCAL_MODE} == "?*", MODE = "$env{LOCAL_MODE}" ENV{LOCAL_NAME} == "?*", NAME = "$env{LOCAL_NAME}" ENV{LOCAL_OWNER} == "?*", OWNER = "$env{LOCAL_OWNER}" ENV{LOCAL_PROGRAM} == "?*", PROGRAM = "$env{LOCAL_PROGRAM}", ENV{.result} = "%c" ENV{LOCAL_LOGG} == "?*", ENV{.result} == "?*", RUN += "$env{LOCAL_LOGG} LOCAL_DEV:$env{LOCAL_DEV} RESULT:$env{.result}" ENV{LOCAL_RUN} == "?*", RUN += "$env{LOCAL_RUN}" ENV{LOCAL_SYMLINK} == "?*", SYMLINK += "$env{LOCAL_SYMLINK}" GOTO = "local_simple_end" LABEL = "local_simple_lastrule" ENV{LOCAL_GROUP} == "?*", GROUP = "$env{LOCAL_GROUP}", OPTIONS="last_rule" ENV{LOCAL_MODE} == "?*", MODE = "$env{LOCAL_MODE}", OPTIONS="last_rule" ENV{LOCAL_NAME} == "?*", NAME = "$env{LOCAL_NAME}", OPTIONS="last_rule" ENV{LOCAL_OWNER} == "?*", OWNER = "$env{LOCAL_OWNER}", OPTIONS="last_rule" ENV{LOCAL_PROGRAM} == "?*", PROGRAM = "$env{LOCAL_PROGRAM}", ENV{.result} = "%c" ENV{LOCAL_LOGG} == "?*", ENV{.result} == "?*", RUN += "$env{LOCAL_LOGG} LOCAL_DEV:$env{LOCAL_DEV} RESULT:$env{.result}" ENV{LOCAL_RUN} == "?*", RUN += "$env{LOCAL_RUN}", OPTIONS="last_rule" ENV{LOCAL_SYMLINK} == "?*", SYMLINK += "$env{LOCAL_SYMLINK}" GOTO = "local_simple_end" # error checking LABEL = "local_simple_exerr" ENV{LOCAL_LOGG} == "?*", RUN += "$env{LOCAL_LOGG} $env{iam}: error: $env{LOCAL_EX}" LABEL="local_simple_end"

Tom Gundersen

3:32 p.m.

New subject: [arch-general] [arch-dev-public] [signoff] udev-174-1

On Tue, Oct 25, 2011 at 2:56 PM, clemens fischer wrote:

...

My system broke with udev-174-1. I have rules renaming eth* according to their MACs for consistency, guarding against dependency on order-of-detection, plus rules to customize a wlan running on an USB device. These rules didn't run.

Could you have a look in your logs (dmesg in particular) for any messages? Make sure that logging is turned on in /etc/udev.conf. If a rule does not work, a warning/error should be printed to dmesg.

...

Basically, there is one rule file[1] calling out to a number of local "simple" rules. These in turn are very short, containing only (LOCAL_) "RUN"/"NAME" commands. The main rule assembles a name out of subsystem, addresses, interfaces etc. This name points into a separate directory "/etc/udev-local" where the appropriate one- or two liners live, and there's a logging rule telling me what file names to use if there's anything missing. All this is less complex than eg. udisks and relies only on udevd.

I can't see what is wrong off-hand, so please file a bug report about this so it is not forgotten. (I didn't figure out how your rules are supposed to work, so there might be something obvious that I missed...).

...

Are rules in /etc/udev ever called in the new version?

Yes, /etc/udev/rules.d/ are called and take precedence over /lib/udev/rules.d/ as always.

...

Do I need some compatibility to make this happen?

Shouldn't be needed. Note that some deprecated things were removed in 174, but you should have been seeing warnings about this for years, so that probably is not the problem here (see the NEWS file for details). Cheers, Tom

clemens fischer

6:54 p.m.

New subject: [arch-general] [arch-dev-public] [signoff] udev-174-1

Tom Gundersen wrote:

...

On Tue, Oct 25, 2011 at 2:56 PM, clemens fischer <...> wrote:

...
My system broke with udev-174-1. I have rules renaming eth* according to their MACs for consistency, guarding against dependency on order-of-detection, plus rules to customize a wlan running on an USB device. These rules didn't run.

Could you have a look in your logs (dmesg in particular) for any messages? Make sure that logging is turned on in /etc/udev.conf. If a rule does not work, a warning/error should be printed to dmesg.

Nothing wrong with any rules (sigh).

...

...
Basically, there is one rule file[1] calling out to a number of local "simple" rules. These in turn are very short, containing only (LOCAL_) "RUN"/"NAME" commands. The main rule assembles a name out of subsystem, addresses, interfaces etc. This name points into a separate directory "/etc/udev-local" where the appropriate one- or two liners live, and there's a logging rule telling me what file names to use if there's anything missing. All this is less complex than eg. udisks and relies only on udevd.

I can't see what is wrong off-hand, so please file a bug report about this so it is not forgotten. (I didn't figure out how your rules are supposed to work, so there might be something obvious that I missed...).

Example: # /etc/udev-local/99-local-simple-net-00:11:22:33:44:55-add # _date: 20091003-2228_ LOCAL_NAME=nicX LOCAL_OPT_last_rule=yes My rule file sees an "add" event for the "net" device with MAC "00:11:22:33:44:55" and calls up the short thing above. Another one: # /etc/udev-local/99-local-simple-net-00:1f:1f:55:99:33-add # _date: 20100520-0032_ # #LOCAL_RUN="/bin/sh -c '{ /usr/bin/env; echo 00-done; } >> /tmp/netif.txt'" LOCAL_RUN="/root/bin/wlan-dev.sh add" The script wlan-dev.sh does the setup for an adhoc wlan (that USB thing cannot be used as a WPA2 AP). -or- # /etc/udev-local/99-local-simple-block-partition-vfat-7000-F3A3-add # _date: 20100104-1948_ LOCAL_RUN=/bin/mount -t vfat -o defaults,nodev,noexec /dev/disk/by-uuid/7000-F3A3 /home/ino/Desktop/usb-stick-7000-F3A3 # /etc/udev-local/99-local-simple-block-partition-vfat-7000-F3A3-remove # _date: 20100104-1950_ LOCAL_RUN=/bin/umount -v /home/ino/Desktop/usb-stick-7000-F3A3 As mentioned, no dependencies other than udevd(8) to get all sorts of automatix without ever touching udev-rules. This was way easier to setup and use then any of the chubby gimmix like ifplugd(8), udisks(1) etc. Of course the magic lies in the file names in etc/udev-local/, so the main rule file gives a warning mentioning the precise file name it cooked up to find it.

...

...
Are rules in /etc/udev ever called in the new version?

Yes, /etc/udev/rules.d/ are called and take precedence over /lib/udev/rules.d/ as always.

Stupid me, the udev log tells whenever any rule files are touched, so I could have seen this myself. clemens

clemens fischer

27 Oct 27 Oct

8:24 a.m.

New subject: [arch-general] SOLVED: udev-174-1 problem (Re: [arch-dev-public] [signoff] udev-174-1)

On Tue-2011/10/25-14:56 clemens fischer wrote:

...

My system broke with udev-174-1. I have rules renaming eth* according to their MACs for consistency, guarding against dependency on order-of-detection, plus rules to customize a wlan running on an USB device. These rules didn't run.

The initcpio (mkinitcpio(8)) on my homegrown initramfs image was udev-173, which didn't match the udev-174 in the "full" system. I didn't expect this, because I don't have any custom hooks or udev rules besides my "simple-atomatics" one, which is only one rule not interfering with anything else. The initramfs is all archlinux, so to speak. Yesterday I compiled the new 3.0.8 stable kernel, and the script also invoked mkinitcpio(8), which eventually puts the new udev-174 into the initramfs image. Thereafter the udev in the image and on the full system match, and my problem was gone 8-). clemens

Auguste Pop

8:55 a.m.

New subject: [arch-general] SOLVED: udev-174-1 problem (Re: [arch-dev-public] [signoff] udev-174-1)

On Thu, Oct 27, 2011 at 4:24 PM, clemens fischer wrote:

...

On Tue-2011/10/25-14:56 clemens fischer wrote:

...
My system broke with udev-174-1. I have rules renaming eth* according to their MACs for consistency, guarding against dependency on order-of-detection, plus rules to customize a wlan running on an USB device. These rules didn't run.

The initcpio (mkinitcpio(8)) on my homegrown initramfs image was udev-173, which didn't match the udev-174 in the "full" system.

I didn't expect this, because I don't have any custom hooks or udev rules besides my "simple-atomatics" one, which is only one rule not interfering with anything else. The initramfs is all archlinux, so to speak.

Yesterday I compiled the new 3.0.8 stable kernel, and the script also invoked mkinitcpio(8), which eventually puts the new udev-174 into the initramfs image. Thereafter the udev in the image and on the full system match, and my problem was gone 8-).

clemens

have you tried manually run mkinitcpio?

clemens fischer

28 Oct 28 Oct

9:40 p.m.

New subject: [arch-general] SOLVED: udev-174-1 problem (Re: [arch-dev-public] [signoff] udev-174-1)

Auguste Pop wrote:

...

On Thu, Oct 27, 2011 at 4:24 PM, clemens fischer <...> wrote:

...
Yesterday I compiled the new 3.0.8 stable kernel, and the script also invoked mkinitcpio(8), which eventually puts the new udev-174 into the initramfs image. Thereafter the udev in the image and on the full system match, and my problem was gone 8-).

have you tried manually run mkinitcpio?

Yes, like I said: the builder script did that. I wonder why this has to be done, though. The initramfs runs udevd, and etc/rc.sysinit does, too, after switch_root. So I thought at least the latter invocation would find and execute my rule irrespective of the version used. clemens

4563

Age (days ago)

4571

Last active (days ago)

List overview

Download

6 comments

4 participants

participants (4)

Auguste Pop
clemens fischer
Myra Nelson
Tom Gundersen