Bug 199242
| Summary: | Xen: infinite loop in /lib/udev/rename_device | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mark McLoughlin <markmc> | ||||
| Component: | initscripts | Assignee: | Bill Nottingham <notting> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | CC: | rvokal | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2006-07-19 14:47:22 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 132594 [details]
initscripts-rename-device-xen-guest.patch
Oh, and while you're fixing that, it would probably be safer to do:
- mv /dev/.dhclient-${DEVICE}.leases /var/lib/dhclient/dhclient-${DEVICE}.leases
+ mv -f /dev/.dhclient-${DEVICE}.leases
/var/lib/dhclient/dhclient-${DEVICE}.leases
Added in CVS, will be in the next build. |
For whatever reason, in a Xen guest, ifcfg-vif0.[0-7] all contain HWADDR=FE:FF:FF:FF:FF:FF Now that may be a bug in itself, but it also causes an infinite loop in /lib/udev/rename_device Basically, with e.g. vif0.0 rename_device picks the first device with HWADDR=FE:FF:FF:FF:FF:FF which might be e.g. vif0.6 and keeps trying to rename vif0.0 to vif6.0, which obviously fails Attaching a patch which recognises the possibility that other devices might be configured with the same HWADDR as the one we're being asked to rename This lops a whole 60 seconds off my domU boot time (Also, fixes an fd leak ... it was running out of fds) (I like your sighandler() { exit(1) }; alarm(10); loop catcher btw ... it made it nice and challenging to realize there actually was a loop somewhere :-)