Hi Paul,
On 04/28/2016 02:42 AM, Bruce Dubbs wrote:
Paul Rogers wrote:
The only place I've heard of changing MAC addresses is in a
virtual environment and the script does not create the rules file
in that case.
Then here's a new one for you. This is not virtual, a evidenced by
the fact that I _am_ getting a 70-persistent-net.rules that's causing
network startup to fail. It's a VIA mini-ITX board with an RTL8169
and AMI BIOS.
This could be a problem with that ethernet interface not an issue with
udev. Take a look at this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575805
If this is the case, your MAC is OK on cold boot but partially zeroed
when rebooting. You can check that in your machine.
You can try removing the rules, but the name may then be something
like enp0s1 instead of eth0. If there are other network cards, then
you need to do something for consistent names.
In this case it's certainly not possible, because there are no
slots. (Like a laptop.)
What does the user know? The NIC/chipset is known or knowable. What he
can't account for is udev being quixotic. How can we tell udev to
assign _this_ chipset to _that_ interface and not make up it's own?
If there is only one, then you can add net.ifnames=0 on the kernel
command line.
Bad idea. It needs to be something the init script can handle on its
own.
Why? If the kernel gets it right at the start, then the init scripts or
udev don't need to address the name at all.
If you really need udev to handle it and there is only one network
drive, try removing the test ATTR{address}=="40:8d:5c:1f:92:99"
completely or make it something like ATTR{address}=="40:8d:5c:??:??:??"
Why don't you try that? Yours could read something like this:
ATTR{address}=="??:??:??:??:96:06"
If you confirm that issue in your machine, this could handle the zeroing
of the first four octets.
Regards.
Alz.
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
