When use eudev in new freshly installed system, udevd does not create persistent-net.rules. If start udev in debug mode - following messages appears: ***** May 20 14:45:09 router kernel: <31>udevd[2150]: 'write_net_rules'(err) 'info: unrecognized option '--run'' May 20 14:45:09 router kernel: <31>udevd[2152]: 'write_net_rules'(err) '+ RULES_FILE=/etc/udev/rules.d/70-persistent-net.rules' May 20 14:45:09 router kernel: <31>udevd[2152]: 'write_net_rules'(err) '+ . /lib/udev/rule_generator.functions' ***** May 20 14:45:09 router kernel: <31>udevd[2156]: passed -1 bytes to netlink monitor 0xa230f0 May 20 14:45:09 router kernel: <31>udevd[2156]: seq 2290 processed with 0 May 20 14:45:09 router kernel: <31>udevd[2150]: 'write_net_rules'(err) '+ RULES_FILE=/etc/udev/rules.d/70-persistent-net.rules' May 20 14:45:09 router kernel: <31>udevd[2151]: 'write_net_rules'(err) '+ RULES_FILE=/etc/udev/rules.d/70-persistent-net.rules' May 20 14:45:09 router kernel: <31>udevd[2150]: 'write_net_rules'(err) '+ . /lib/udev/rule_generator.functions' May 20 14:45:09 router kernel: <31>udevd[2150]: 'write_net_rules'(err) '++ PATH=/sbin:/bin' May 20 14:45:09 router kernel: <31>udevd[2150]: 'write_net_rules'(err) '++ PATH=/sbin:/bin' ****** When I create rules by hand, system startup hangs in "Waiting for uevents to be processed" on 2-3 seconds and i have interface "eth2.rename" instead of eth1. Nothing in logs about described above. Unfortunately, I can't reproduce this now (system not in my hands). But I can try reproduce it in my home system. I tried to research what can be happened and found that udevadm does not have option '--run' with command 'info'. Thanks for attention.
I'm working on a new release now. If you can give me cleaner steps to reproduce, I can probably nail it.
Oh wait, did you do rc-update add udev-postmount default?
(In reply to Anthony Basile from comment #1) >I'm working on a new release now. If you can give me cleaner steps to >reproduce, I can probably nail it. 1. Remove directory /etc/udev/rules.d 2. Reboot (reload/restart udev) reboot or restart/reload udev does not create persistent-net.rules In case with renaming create or modify existing persistent-net.rules and reboot (reload/restart udev). I don't know why, but 'udevadm trigger' does not sufficient for applying rules to device names. (In reply to Anthony Basile from comment #2) > Oh wait, did you do rc-update add udev-postmount default? Of course, I did it :)
(In reply to Alexey Prokopchuk from comment #3) > (In reply to Anthony Basile from comment #1) > >I'm working on a new release now. If you can give me cleaner steps to >reproduce, I can probably nail it. > > 1. Remove directory /etc/udev/rules.d > 2. Reboot (reload/restart udev) > > reboot or restart/reload udev does not create persistent-net.rules > > In case with renaming create or modify existing persistent-net.rules and > reboot (reload/restart udev). I don't know why, but 'udevadm trigger' does > not sufficient for applying rules to device names. > > (In reply to Anthony Basile from comment #2) > > Oh wait, did you do rc-update add udev-postmount default? > > Of course, I did it :) Okay we've go this working with eudev-9999. There were actually two things that were broken making it hard to find. We've tested along the lines described in bug #475276 and its good. Can you please test and let us know.
(In reply to Alexey Prokopchuk from comment #3) > 1. Remove directory /etc/udev/rules.d > Actually don't remove the directory, just its contents. We can work on making this more robust, but as of right now, if the directory isn't there, the 70-persistent-X rules are not written.
*** Bug 475276 has been marked as a duplicate of this bug. ***
(In reply to Anthony Basile from comment #5) > (In reply to Alexey Prokopchuk from comment #3) > > > 1. Remove directory /etc/udev/rules.d > > > > Actually don't remove the directory, just its contents. We can work on > making this more robust, but as of right now, if the directory isn't there, > the 70-persistent-X rules are not written. I think udev-postmount should probably create that dir if missing, in case a user does remove it on their own. Will commit a change to portage prior to the next release.
(In reply to Ian Stakenvicius from comment #7) > (In reply to Anthony Basile from comment #5) > > (In reply to Alexey Prokopchuk from comment #3) > > > > > 1. Remove directory /etc/udev/rules.d > > > > > > > Actually don't remove the directory, just its contents. We can work on > > making this more robust, but as of right now, if the directory isn't there, > > the 70-persistent-X rules are not written. > > I think udev-postmount should probably create that dir if missing, in case a > user does remove it on their own. Will commit a change to portage prior to > the next release. Yeah that works for me. I have mixed feelings about what to do when users go around deleting stuff installed by package. In this case, suppose I *want* this behavior?
(In reply to Anthony Basile from comment #8) > (In reply to Ian Stakenvicius from comment #7) > > (In reply to Anthony Basile from comment #5) > > > (In reply to Alexey Prokopchuk from comment #3) > > > > > > > 1. Remove directory /etc/udev/rules.d > > > > > > > > > > Actually don't remove the directory, just its contents. We can work on > > > making this more robust, but as of right now, if the directory isn't there, > > > the 70-persistent-X rules are not written. > > > > I think udev-postmount should probably create that dir if missing, in case a > > user does remove it on their own. Will commit a change to portage prior to > > the next release. > > Yeah that works for me. I have mixed feelings about what to do when users > go around deleting stuff installed by package. In this case, suppose I > *want* this behavior? It's a path-must-exist-at-runtime issue; if it doesn't (user did something silly), make sure it does. Even though we install that dir now as part of eudev's build system, if the user removes it then udev-postmount (as well as write_net_rules, probably?) will still fail. ..Actually I wonder if that means write_net_rules (or rule_generator.functions) should create that dir if it's missing...
(In reply to Ian Stakenvicius from comment #9) > (In reply to Anthony Basile from comment #8) > > (In reply to Ian Stakenvicius from comment #7) > > > (In reply to Anthony Basile from comment #5) > > > > (In reply to Alexey Prokopchuk from comment #3) > > > > > > > > > 1. Remove directory /etc/udev/rules.d > > > > > > > > > > > > > Actually don't remove the directory, just its contents. We can work on > > > > making this more robust, but as of right now, if the directory isn't there, > > > > the 70-persistent-X rules are not written. > > > > > > I think udev-postmount should probably create that dir if missing, in case a > > > user does remove it on their own. Will commit a change to portage prior to > > > the next release. > > > > Yeah that works for me. I have mixed feelings about what to do when users > > go around deleting stuff installed by package. In this case, suppose I > > *want* this behavior? > > It's a path-must-exist-at-runtime issue; if it doesn't (user did something > silly), make sure it does. Even though we install that dir now as part of > eudev's build system, if the user removes it then udev-postmount (as well as > write_net_rules, probably?) will still fail. > > ..Actually I wonder if that means write_net_rules (or > rule_generator.functions) should create that dir if it's missing... ..something along the lines of: --- a/rule_generator/rule_generator.functions +++ b/rule_generator/rule_generator.functions @@ -76,6 +76,10 @@ choose_rules_file() { local tmp_rules_file="$RUNDIR/tmp-rules--${RULES_FILE##*/}" [ -e "$RULES_FILE" -o -e "$tmp_rules_file" ] || PRINT_HEADER=1 + [ -d "${RULES_FILE%/*}" ] || if writeable ${RULES_FILE%/rules.d/*}; then + mkdir -p "${RULES_FILE%/*}" + fi + if writeable ${RULES_FILE%/*}; then RO_RULES_FILE='/dev/null' else .. good idea to apply, or no?
(In reply to Ian Stakenvicius from comment #10) > (In reply to Ian Stakenvicius from comment #9) > > (In reply to Anthony Basile from comment #8) > > > (In reply to Ian Stakenvicius from comment #7) > > > > (In reply to Anthony Basile from comment #5) > > > > > (In reply to Alexey Prokopchuk from comment #3) > > > > > > > > > > > 1. Remove directory /etc/udev/rules.d > > > > > > > > > > > > > > > > Actually don't remove the directory, just its contents. We can work on > > > > > making this more robust, but as of right now, if the directory isn't there, > > > > > the 70-persistent-X rules are not written. > > > > > > > > I think udev-postmount should probably create that dir if missing, in case a > > > > user does remove it on their own. Will commit a change to portage prior to > > > > the next release. > > > > > > Yeah that works for me. I have mixed feelings about what to do when users > > > go around deleting stuff installed by package. In this case, suppose I > > > *want* this behavior? > > > > It's a path-must-exist-at-runtime issue; if it doesn't (user did something > > silly), make sure it does. Even though we install that dir now as part of > > eudev's build system, if the user removes it then udev-postmount (as well as > > write_net_rules, probably?) will still fail. > > > > ..Actually I wonder if that means write_net_rules (or > > rule_generator.functions) should create that dir if it's missing... > > > ..something along the lines of: > > --- a/rule_generator/rule_generator.functions > +++ b/rule_generator/rule_generator.functions > @@ -76,6 +76,10 @@ choose_rules_file() { > local tmp_rules_file="$RUNDIR/tmp-rules--${RULES_FILE##*/}" > [ -e "$RULES_FILE" -o -e "$tmp_rules_file" ] || PRINT_HEADER=1 > > + [ -d "${RULES_FILE%/*}" ] || if writeable ${RULES_FILE%/rules.d/*}; > then > + mkdir -p "${RULES_FILE%/*}" > + fi > + > if writeable ${RULES_FILE%/*}; then > RO_RULES_FILE='/dev/null' > else > > > .. good idea to apply, or no? Yes please apply and then we'll test.
This should all be fixed with eudev-1.1 which is in the tree now. Thanks everyone! Please reopen if this is still an issue.
