Fix udev issue where temporary persistent rules are written in one
place and read from another. The upstream udev release placed dynamic
persistent rules (ones that get deleted every reboot) in /dev/.udev/,
but the actual udev daemon read these rules out of
/dev/.udev/rules.d/. The side effect of this is that if the static
directory (/etc/udev/rules.d) is not writeable (read-only root
filesystem, for example), device interfaces keep getting renamed
wlan0, wlan1, wlan2, etc, if they are plugged and unplugged or if
udevd restarts.
In addition to the directory being incorrect, the actual filename was
incorrect as well -- the filename was set to begin with "tmp-", which
breaks the lexical sorting rules that udevd uses, so even if the file
was in the right directory, the 75-persistent-net-generator.rules
would fire first, and increment the device number anyway.
I've tested this patch to apply clieanly to udev-146 and udev-156.
Note that this change by itself won't work on most distributions (with
read only fses) unless they they also make sure that the
/dev/.udev/rules.d directory is created before udevd starts up, since
otherwise the inotify will never trigger for that directory since it
didn't exist when the inotify call was made.
--- extras/rule_generator/rule_generator.functions.orig 2008-10-23
06:33:41.000000000 -0700
+++ extras/rule_generator/rule_generator.functions 2010-05-26
10:26:20.000000000 -0700
@@ -57,7 +57,9 @@
# Choose the real rules file if it is writeable or a temporary file if not.
# Both files should be checked later when looking for existing rules.
choose_rules_file() {
- local tmp_rules_file="/dev/.udev/tmp-rules--${RULES_FILE##*/}"
+ local orig_rules_base=${RULES_FILE##*/}
+ local tmp_rules_base=${orig_rules_base%%.rules}--tmp.rules
+ local tmp_rules_file="/dev/.udev/rules.d/$tmp_rules_base"
[ -e "$RULES_FILE" -o -e "$tmp_rules_file" ] || PRINT_HEADER=1
if writeable ${RULES_FILE%/*}; then
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
