/etc/udev/rules.d/hostname_netinterface.rules파일에 9개의 네트워크 인터페이스 udev 규칙이 있습니다. 이것은 esxi의 가상 머신입니다. 재부팅 후에도 인터페이스가 계속 변경된 후 이 파일을 만들었습니다. 한동안 작동했지만 몇 달 후에 다시 시작하면 작동하던 동일한 파일이 갑자기 중지되었습니다.
파일 형식은 총 9개입니다.
file: /etc/udev/rules.d/hostname_netinterface.rules
KERNEL=="eth*", SYSFS{address}=="22:22:33:44:33:22", NAME="eth0"
KERNEL=="eth*", SYSFS{address}=="22:22:33:44:33:44", NAME="eth1"
KERNEL=="eth*", SYSFS{address}=="22:22:33:44:33:55", NAME="eth2"
and so on up until eth9
syslog를 확인했는데 라인 1-9에 대해 다음과 같이 표시됩니다.
unknown key 'SYSFS{address}' in /etc/udev/rules.d/010_netinterfaces.rules:9
이는 데비안의 무인 보안 업데이트로 인해 발생했을 것입니다. 이 업데이트는 몇 달 동안 작동해 왔기 때문입니다. 도와주세요.
답변1
왜 작동하는지 모르겠지만, 이 작업을 수행하는 경우 udev의 네트워크 인터페이스를 확인하는 것입니다.
user@host:~$ udevadm info -a -p /sys/class/net/eth0 |grep address
ATTR{address}=="22:22:33:44:33:22"
주소 ATTR앞에는 , 대신 가 붙어 있으니 참고하세요 SYSFS. 파일을 변경하고 교체했더니 SYSFS해결 ATTR되었습니다.
KERNEL=="eth*", ATTR{address}=="22:22:33:44:33:22", NAME="eth0"
이것은 이전에 작동했기 때문에 "의도하지 않은 업그레이드"로 인해 udev가 변경되었다고 가정합니다.
답변2
비슷한 문제에 직면 해 있습니다. 제 경우에는 .rules 파일을 로컬에서 대상으로 푸시했습니다. udev 규칙이 다시 로드되면 작동합니다. 그러나 대상을 다시 시작하면 규칙이 적용되지 않습니다. Soln: 업데이트된 .rules 파일로 이미지를 다시 빌드하세요. 이것은 나에게 효과적입니다. udev 데몬이 .rules 파일의 빌드 시간 체크섬을 확인하는 것 같습니다. 따라서 로컬에서 수정되고 푸시된 새 규칙 파일은 로드되지 않습니다.