but for me this is not a solution, because my script should run on several different RPis, without knowledge of their MAC addresses and without possibility to reconfigure and restart network adapters. the script needs to catch the RPi built-in ethernet adapter.
Code: Select all
$ ip link add link enb827eb351305 name eth0 type macvlan
no, does not help, because that would need to prepare the RPi first, to be able to use the script.
"Those responsible for the sacking have been sacked"
The idea itself is sound - I have run into the issues it is intended to overcome. The problem is that it's a change rather than addition, and quite a major change.
History is too fresh to be rewritten yet.
That I agree is a fair point.
I don't think it is stupid as it does seem to me to do exactly what it is intended to do, but I'm not here to defend that decision.
I must admit that I have wondered why no one at the Foundation, any of those beta testing or already upgraded to Stretch, had reported any problems or concerns relating to this issue, when it does seem to be a major problem and inconvenience for many. It does seem to have taken every one by surprise.
I don't feel it's so much of a problem to take any decision now. The predictable naming can already be easily turned off and the Foundation indicates it will be in forthcoming installations. I will let them decide what the future holds before I consider whether I will change to something else.
Except for every existing program that deals with network interfaces, which would suddenly see twice as many and have no reason to suspect that half of them are duplicates. Your proposal requires changing the kernel interface, and everything that uses it.
Anything that requires manual udev rules is unusably broken. The auto-generated rules were okay, but there was no guarantee they would be the same across multiple installs. (If you had upgraded to stretch instead of reinstalling, you would still have your persistent eth0 rule from jessie.)
Same kind of 'weird' as the USB issues when RPis were first released. Despite apparently 50 to 100 pre-production ones being in the hands of testers beforehand, that lots of paying customers* immediately on receipt found that their USB keyboards did not work properly came as a complete surprise to RPF.
Yes, but that underscores a problem: That what you get by "upgrading" from a previous version is not the same as what you get with a "fresh" install. This to me is a bad state of affairs - for a variety of what should be pretty obvious reasons.Thinking about it ...
That's absolutely correct. I have eight machines running Stretch with eth0/wlan0. I'm going to strip the /etc/network/interfaces file down to match the one shipped with Stretch to get the predictable names stuff running as that seems to be the direction that ALL distros (RedHat, SuSE, Ubuntu, Debian) are heading in and as far as I'm concerned is a good thing rather than anything retrograde.hippy wrote: ↑Tue Aug 22, 2017 3:43 pmThinking about it ... Most users beta-testing Stretch or installing early have probably gone through an upgrade rather than install process. From what I have read, that won't bring in any predictable name changes. That could explain why it wasn't spotted by those folk.
Indeed. I would expect the issue got overlooked, or forgotten about, that 'it works okay for me, works for everyone here, works for everyone else, including people like Dougie who have multiple Pi's in various configurations' led to a belief that there was not and would not be such an issue upon release.
Users browsing this forum: procount and 64 guests