Re: [arch-general] [arch-dev-public] [signoff] udev-174-1
On Thu, Oct 20, 2011 at 02:00, Tom Gundersen <teg@jklm.no> wrote:
Hi Dave,
On Thu, Oct 20, 2011 at 3:09 AM, Dave Reisner <d@falconindy.com> 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!
'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 <url:man:7 udev> 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"
On Tue, Oct 25, 2011 at 2:56 PM, clemens fischer <ino-news@spotteswoode.dnsalias.org> 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
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
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
On Thu, Oct 27, 2011 at 4:24 PM, clemens fischer <ino-news@spotteswoode.dnsalias.org> 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?
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
participants (4)
-
Auguste Pop
-
clemens fischer
-
Myra Nelson
-
Tom Gundersen