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.

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:??:??:??"

Personally I think this naming thing is the tail wagging the dog. It's only needed when there is more than one network card and I suspect 99% of systems only have one nic.


See
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

[ paragraphs of point by point refutation mercifully deleted ]


BTW, typo in LFS' /lib/udev/init-net-rules.sh:

if ! mountpoint -q /sys; then
   msg="/sys mut be mounted"
   usage
fi

if ! mountpoint -q /proc; then
   msg="/proc mut be mounted"
   usage
fi

Interesting. Those typos have been there since July 2012 and no one has noticed before. Perhaps because /sys and /proc have been mounted.

  -- Bruce

--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to