meta-lxatac-bsp: lxatac-factory-data: reload udev rules on completion #107
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The lxatac-factory-data script generates a tac-bridge.link file, which sets the MAC address to use on the tac-bridge network interface, which is a bridge created by NetworkManager.
We have noticed that on some boots this MAC address is not correct. On these boots we can also see that udev (which reads the .link files) did not take the link file into account (even though it exists):
Normal boot:
Boot with wrong MAC address:
This hints at some sort of race condition between lxatac-factory-data, udev reading its rules and NetworkManager setting up the bridge device.
Run
udevadm control --reload-rules
after creating the link file to hopefully solve the race condition.I did some "statistical" testing of this change by running our labgrid pytest test in a loop, which checks if the MAC is correct:
The tests indicate that the fix works, but are not 100% clear as to it working for the correct reasons (because just waiting also helps a bit).