Re: [DNG] Ethernet names revisited
On Sun, 13 Dec 2020 10:45:56 +0100 Antony Stone wrote: > On Sunday 13 December 2020 at 09:25:24, terryc wrote: > > > Just add the line > > hwaddress mac:add:dress:in:usual:format > > > > to match eth2 & eth3 to the desired card. > > I think that's entirely the wrong way round. > > Setting hwaddress in /etc/network/interfaces changes the MAC address > of the interface according to its name (eth0, eth1, etc). Woops, my apologies. I'd completely forgotten about that feature. Personally,I have a strong bias against using the udev stuff as mostly it just kills my network when the OS HDDs were migrated to a new motherboard(usually after a mobo died) and less commonly NICs die, get upgraded or standardised. (66% of our systems are headless). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On 13/12 22:22, Antony Stone wrote: > On Sunday 13 December 2020 at 21:42:50, Simon Hobson wrote: > > > Hendrik Boom wrote: > > > I had to solve it by assigning new names to the interfaces (thus not eth0 > > > or eth1) and modifying all the config files mentioning those interface > > > names (I found them with grep) to use the new names instead. > > > > Not for the OPs reason, but a long time ago I started to use "meaningful > > names" like ethext, ethint, and so on. Making it clearer in config files > > what each interface is. > > Ironically enough, that is precisely what I have done on my own routers, > which > have interfaces named "Internet", "Clients", "Phones", "PubServers" and > "PriServers". > > I did that because by default they create VLAN interfaces called eth0.0, > eth0.1, eth0.2 etc, and so I used the rename facility in > /etc/network/interfaces to give them names which meant something to me. > > > I think removing the need to remember something is better than being good > > at remembering it (which I'm not anyway !) > > I completely agree with that, however in this case (wanting eth0 to be on the > motherboard and eth1/2 to be the PCI card), is close enough to "familiar" for > me not to get confused about it (once I get the machine to agree on the > names). One option could be to ensure tg3 is loaded before r8196 by mentioning them in that order in /etc/modules (or maybe it needs to be in /etc/initramfs-tools/modules). The tg3 would claim eth0 and r8196 would claim eth1 and eth2 (which probably would name its ports consistently in the desired order). Then yo don't even need that 70-.. udev file, which you did need for jessie so as to counteract its "predictable names" mangling. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On Sunday 13 December 2020 at 21:42:50, Simon Hobson wrote: > Hendrik Boom wrote: > > I had to solve it by assigning new names to the interfaces (thus not eth0 > > or eth1) and modifying all the config files mentioning those interface > > names (I found them with grep) to use the new names instead. > > Not for the OPs reason, but a long time ago I started to use "meaningful > names" like ethext, ethint, and so on. Making it clearer in config files > what each interface is. Ironically enough, that is precisely what I have done on my own routers, which have interfaces named "Internet", "Clients", "Phones", "PubServers" and "PriServers". I did that because by default they create VLAN interfaces called eth0.0, eth0.1, eth0.2 etc, and so I used the rename facility in /etc/network/interfaces to give them names which meant something to me. > I think removing the need to remember something is better than being good > at remembering it (which I'm not anyway !) I completely agree with that, however in this case (wanting eth0 to be on the motherboard and eth1/2 to be the PCI card), is close enough to "familiar" for me not to get confused about it (once I get the machine to agree on the names). Antony. -- I know I always wanted to be somebody, but I guess I should have been more specific. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On Sunday 13 December 2020 at 21:13:10, d...@d404.nl wrote:
> It looks like systemd again is responsible for this mess.
That is unexpected for me, since I am starting from a clean installation of
Devuan Beowulf - no upgrade, no crossover from Debian - just a totally new
install of Devuan (which I'm expecting to be ohne/sans/without systemd in any
form).
> From what I understand uses eudev the same files as systemd with udev. If so
> you should do
>
> ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
I guess I can try that, however you should be aware that when I started this
exercise (from the aforementioned fresh installation of Devuan Beowulf), the
directory /etc/udev/rules.d (a) existed and (b) was empty.
> to make sure (e)udev does not mess with the network devices. (/etc/udev
> seems to have priority above /lib/udev)
I can only say that searching /lib/udev revealed (a) nothing specific to my
network devices, and (b) no files more recent than January 1st 2020, on a
machine installed in December 2020, therefore I don't think there is anything
in there contributing to my problem.
> After that it is somewhat unclear to me. Or
> /etc/udev/rules.d/70-persistent-net.rules should work again. Or you
> should add a 70-net-name-slot.rules with the syntax of
> 80-net-name-slot.rules like
>
> SUBSYSTEM!="net", GOTO="net_setup_link_end"
> IMPORT{builtin}="path_id"
> ACTION!="add", GOTO="net_setup_link_end"
> IMPORT{builtin}="net_setup_link"
>
> NAME=="eth0", ENV{ID_NET_NAME_ONBOARD}!="",
> NAME="$env{ID_NET_NAME_ONBOARD}" NAME=="eth0", ENV{ID_NET_NAME_SLOT}!="",
> NAME="$env{ID_NET_NAME_SLOT}" NAME=="eth0", ENV{ID_NET_NAME_PATH}!="",
> NAME="$env{ID_NET_NAME_PATH}"
>
> LABEL="net_setup_link_end"
I'll give that go tomorrow (or perhaps Tuesday; tomorrow looks like a busy
work day for me).
> After adding net.ifnames=0 and biosdevname=0 your system should work as
> intended but I do not have the time to test it, hopes it helps in the
> right direction.
I shall report back.
Antony.
--
“If code doesn’t receive constant love, it turns to shit.”
- Brad Fitzpatrick, Google engineer
Please reply to the list;
please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
Hendrik Boom wrote: > I had to solve it by assigning new names to the interfaces (thus not eth0 or > eth1) and modifying all the config files mentioning those interface names (I > found them with grep) to use the new names instead. Not for the OPs reason, but a long time ago I started to use "meaningful names" like ethext, ethint, and so on. Making it clearer in config files what each interface is. On one box (router) I had a fair number of interfaces (I can recall at least 8 inc 3 PPP (VDSL2) networks) - made remembering what's what a heck of a lot easier. Also did the same thing with my Xen guests - gave the interfaces on the host meaningful names via the guest config files. I think removing the need to remember something is better than being good at remembering it (which I'm not anyway !) Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What I learned at Distrowatch
Le 13/12/2020 à 03:15, Steve Litt a écrit : > On Fri, 11 Dec 2020 15:53:35 +0100 > Didier Kryn wrote: > > >> I don't make it an argument against xdm. Just cheating about your >> own arguments (~: > Didier, why didn't you make that suggestion to me 15 years ago? It's a > brilliant way to guarantee that if somebody logs out of X, they have no > logged in shell to make mischief with. > > I should have thought of that myself. 15 years ago :-). > Yes you should have. But this is something everybody forgets all the time. We all imagine a program invocation like a function call, in which the caller is suspended until the callee returns; but actually when the shell is suspended waiting the application to return, it intentionnally waits, but can easily stop waiting. The artefact is that we must add an '&' to tell it not to wait in the first place. This is a semantic sugar to make it behave by default "as if" it was a function call. exec does not create a new process; instead it substitutes the new application to the current one (the shell). I had fun some years ago writing an application which opened an http connection to a server on standard input, read the http header, and then execed another application given in argument. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] godaddy (was Your system is not supported by certbot-auto anymore.)
Hendrik Boom wrote: > Know any domain registrars that don't mess with the user? You could take a look at mythic-beasts.com or portfast.net When I left my last place, I decided to move my domains away from them (as an employee I got "cost price" domains and free hosting) - knowing that the people left in charge are (staying polite) "ethics challenged" and "technically challenged". Good choice as it happened, because one "person" decided to just switch off* the remaining servers - "DNS will be OK, it's all mirrored at Portfast". I had mixed emotions when I heard that they'd been in a panic to setup about 100 remaining domains on their preferred hosting platform (with a truly horrible GUI for managing DNS) after a week when the secondary DNS servers expired all the records - a strong sense of schadenfreude as their own domain was one of them, but with my professional hat ot a distinct sense of anger that a) it had impacted clients, and b) they'd be told a bunch of lies as to why it had happened. * Didn't just switch off, but switched off, and ripped out of the rack and all the networking ripped apart - so couldn't just switch it back on again. Anyway, my personal domains are now mirrored at Portfast - they were before as we used them to mirror our primary (have a neat API to keep their list up to date with ours). And on a recommendation from someone in my local-ish LUG moved my registrations to Mythic Beasts. What I can say is that when we were setting up our secondary DNS service at Portfast, we had good support dealing with real people in technical roles - not support droids with a computer flowchart. We'd previously had a secondary service from another UK supplier (Gradwell) who'd decided to pull out of that side of things - and they arranged to transfer our service to an equivalent one with Portfast rather that the more typical approach of "we're turning your service off, bog off and find another service yourself". And I see that I'm now down to around 5 years left on my domains - so time to extend that back up to 9+ years. Like you, I don't subscribe to the "year by year and leave it late" renewals policy. We had clients with domain name problems caused by that. Of course, the alternative problem is that you "know" there's a long time left and the years can roll by faster than you realise :-( Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
Le 13/12/2020 à 01:09, Ralph Ronnquist via Dng a écrit : > On 13/12 00:40, Antony Stone wrote: >>> If it worked for you previously then, a) there would have been rules >>> for double renaming, >> Please point me at where I should find these. >> >> I only know that /etc/udev/rules.d/70-persistent-net.rules was the >> *only* file I needed to edit if I wanted to rearrange the naming of >> the interfaces under Jessie or earlier. > Well, the kernel modules makes the first naming, and assigns them as > eth0, eth1, eth2. That happens before udev starts. > > The kernel refuses any attempt to name an interface to, say, eth0 if > that name is taken. > > Those "facts" have been in effect since last millenium, so whatever > happened for you before would have happened within the eclipse of > those "facts". > >>> and b) any network management would have kicked >>> in late enough to let name fiddling happen before bringing up the >>> interfaces. As you know, one of the joys with parallel boot is the >>> random effects of things happening in parallel. >> I thought "parallel boot" was one of the evils that systemd was designed to >> bring in. In what way does Devuan do "parallel boot"? > afact 1) udev processes events (somewhat) in parallel, and 2) the > post-pivot boot runs init scripts in as much parallelism as is allowed > with respect to their declared dependencies. That latter thing is > something newish (10 years?) but current default. > Maybe Udev is parallelized, but the netlink is serialized by the kernel. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On 13-12-2020 14:20, Antony Stone wrote:
> On Sunday 13 December 2020 at 13:02:45, Florian Zieboll via Dng wrote:
>
>> Am 13. Dezember 2020 12:01:39 MEZ schrieb Antony Stone
> :
>>> Well, here's the output from "dmesg | grep eth". It shows the r8169
>>> interfaces being given names eth0, eth1 (the ones I want as eth1 and
>>> eth2), then the tg3 interface gets called eth2 (which I want as eth0).
>>>
>>> At 6 seconds in, you can see my 70-persistent-net.rules file kicking in
>>> and renaming then to xeth2, xeth1 and xeth0; then finally at 12 seconds,
>>> the second rename in /etc/network/interfaces sets them back to eth0,
>>> eth1 and eth2 in the order I want them.
>> So have you tried with 'ifnames=1'?
> I hadn't, but I've just done so now - it makes no difference - here's dmesg:
>
> [0.00] Linux version 4.19.0-10-amd64 (debian-ker...@lists.debian.org)
> (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24)
> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-amd64
> root=UUID=9cbc8bd3-4cb8-4ae1-92c5-5a3659e9aed6 ro net.ifnames=1 quiet
>
> [3.394364] r8169 :04:00.0 eth0: RTL8168e/8111e, 00:e0:4c:80:21:6b,
> XID
> 2c20, IRQ 30
> [3.394368] r8169 :04:00.0 eth0: jumbo features [frames: 9200 bytes,
> tx
> checksumming: ko]
> [3.450174] r8169 :05:00.0 eth1: RTL8168e/8111e, 00:e0:4c:80:21:6c,
> XID
> 2c20, IRQ 31
> [3.450177] r8169 :05:00.0 eth1: jumbo features [frames: 9200 bytes,
> tx
> checksumming: ko]
> [3.489342] tg3 :07:00.0 eth2: Tigon3 [partno(BCM95723) rev 5784100]
> (PCI Express) MAC address 78:ac:c0:f7:89:f7
> [3.489347] tg3 :07:00.0 eth2: attached PHY is 5784 (10/100/1000Base-T
> Ethernet) (WireSpeed[1], EEE[0])
> [3.489350] tg3 :07:00.0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0]
> ASF[0]
> TSOcap[1]
> [3.489352] tg3 :07:00.0 eth2: dma_rwctrl[7618] dma_mask[64-bit]
> [6.187233] tg3 :07:00.0 xeth0: renamed from eth2
> [6.231916] r8169 :05:00.0 xeth2: renamed from eth1
> [6.246745] r8169 :04:00.0 xeth1: renamed from eth0
>
>> And are you sure, that the 'hwaddress' lines in your
>> '/etc/network/interfaces' really define which NIC to use?
> I'm not using hwaddress in that file - that was a suggestion from terryc, and
> I
> think it's the wrong idea for exactly the following reason:
>
>> AFAICT this option just changes ("spoofs") the MAC address of the NIC for
>> which it is defined. Although the log confirms that finally eth0 is the tg3
>> NIC, this seems unusual (and very counterintuitive) to me.
>
> Thanks,
>
>
> Antony.
>
It looks like systemd again is responsible for this mess. From what I
understand uses eudev the same files as systemd with udev. If so you
should do
ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
to make sure (e)udev does not mess with the network devices. (/etc/udev
seems to have priority above /lib/udev)
After that it is somewhat unclear to me. Or
/etc/udev/rules.d/70-persistent-net.rules should work again. Or you
should add a 70-net-name-slot.rules with the syntax of
80-net-name-slot.rules like
SUBSYSTEM!="net", GOTO="net_setup_link_end"
IMPORT{builtin}="path_id"
ACTION!="add", GOTO="net_setup_link_end"
IMPORT{builtin}="net_setup_link"
NAME=="eth0", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}"
NAME=="eth0", ENV{ID_NET_NAME_SLOT}!="", NAME="$env{ID_NET_NAME_SLOT}"
NAME=="eth0", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}"
LABEL="net_setup_link_end"
After adding net.ifnames=0 and biosdevname=0 your system should work as
intended but I do not have the time to test it, hopes it helps in the
right direction.
Grtz.
Nick
signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
Le 13/12/2020 à 00:01, Ralph Ronnquist via Dng a écrit : > On 12/12 23:22, Antony Stone wrote: >> On Saturday 12 December 2020 at 23:11:25, Ralph Ronnquist via Dng wrote: >> ... >> >> 1. Why is this so totally different from what I could previously do using >> /etc/udev/rules.d/70-persistent-net.rules under jessie and earlier releases? >> >> 2. https://wiki.debian.org/NetworkInterfaceNames clearly says that if you >> upgraded a machine from jessie to stretch and to buster (which for these >> purposes I regard as the same as jessie to ascii to beowulf), then it will >> continue to work as before, so - what is the difference between doing those >> upgrades, and doing a fresh buster / beowulf installation? What needs to be >> changed on a beowulf machine to make it work the same as a jessie machine >> upgraded to ascii, upgraded to beowulf? > If it worked for you previously then, a) there would have been rules > for double renaming, and b) any network management would have kicked > in late enough to let name fiddling happen before bringing up the > interfaces. As you know, one of the joys with parallel boot is the > random effects of things happening in parallel. > Parallelism might be the issue. In the past, when the first interface was discovered by the kernel and named eth0, then Udev would immediately rename it, either to the same name if it matches the rule, or to ethX which still doesn't exist, then freeing the name eth0, and so on. The problem may now be that two interfaces are discovered simultaneously. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Oldstable and Archive timing expectations?
On 2020-12-13 08:39, Hendrik Boom wrote: On Sat, Dec 12, 2020 at 09:31:48PM -0600, goli...@devuan.org wrote: On 2020-12-12 21:04, Adrian Zaugg wrote: > On 04.12.20 19:43, goli...@devuan.org wrote: > > > You might want to have a look at Debian's release schedule: > > > > https://wiki.debian.org/DebianReleases > > > > Does Devuan not follow the LTS schedule? > > https://wiki.debian.org/LTS > > Because when Debian Releases X as stable, Devuan needs some time to > follow, as such Devuan stable stays for a while with Debian X-1, which > is then under LTS as oldstable. At least it was with Jessie very much > the case. With Jessie was this a coincidence or is that rather a rule? > > Regards, Adrian. > Yes. That is correct. The lag between Debian stable and the corresponding Devuan stable release is why we recommend using the release name rather that the suite name in /etc/apt/sources.list Please see https://www.devuan.org/os/releases for more information. Where the Devuan release codenames chart sems to be up-to-date, but the examples in the Codenames or suites? section still refer to Beowulf as testing. Which was probably correct "As of this writing" but is no longer correct and potentially confusing. -- hendrik Thanks for catching that, Hendrik! All updated now. golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Linux kernel boot causing screen to become unreadable.
Dear All, After the modesetting issue stopped manifesting itself for some days, it started again, and now, it is almost happening with every system boot. As the sceen is completely unreadable with unaligned pixels, I tried the modprobe command without a display and paying attention not to make typing mistakes, and attempted to load the i915 kernel module. The result was, the display returned to normal, but some modules were still missing, as I couldn't connect to a wifi. My conclusion is, for some reason, these modules are failing to load. A shell script checking for i915 and r6981 and loading the missing modules can solve the issue, but others may have better solutions. Suggestions for warkarounds, are most welcome. Thanks. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
Martin Steigerwald - 13.12.20, 16:07:10 CET: > Hendrik Boom - 13.12.20, 15:52:31 CET: > > On Sun, Dec 13, 2020 at 09:29:26AM +0100, Martin Steigerwald wrote: > > > I do not care about all the automatic changes by package upgrades. > > > > I care about the automatic changes by package upgrades when they > > conflict with my own. > > Well, dpkg warns me about these. And I forgot: I also see them with bzr / git diff. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
Hendrik Boom - 13.12.20, 15:52:31 CET: > On Sun, Dec 13, 2020 at 09:29:26AM +0100, Martin Steigerwald wrote: > > I do not care about all the automatic changes by package upgrades. > > I care about the automatic changes by package upgrades when they > conflict with my own. Well, dpkg warns me about these. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
On Sun, Dec 13, 2020 at 09:29:26AM +0100, Martin Steigerwald wrote: > > I do not care about all the automatic changes by package upgrades. I care about the automatic changes by package upgrades when they conflict with my own. It would also be useful to have a tool that compares a the configuration files to the ones provided by the current release, to find * discrepancies that have crept in unawares * discrepancies that indicate proper, deliberate changes. A kind of audit, I suppose, that would still have to be checed manually.. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Oldstable and Archive timing expectations?
On Sat, Dec 12, 2020 at 09:31:48PM -0600, goli...@devuan.org wrote: > On 2020-12-12 21:04, Adrian Zaugg wrote: > > On 04.12.20 19:43, goli...@devuan.org wrote: > > > > > You might want to have a look at Debian's release schedule: > > > > > > https://wiki.debian.org/DebianReleases > > > > > > > Does Devuan not follow the LTS schedule? > > > > https://wiki.debian.org/LTS > > > > Because when Debian Releases X as stable, Devuan needs some time to > > follow, as such Devuan stable stays for a while with Debian X-1, which > > is then under LTS as oldstable. At least it was with Jessie very much > > the case. With Jessie was this a coincidence or is that rather a rule? > > > > Regards, Adrian. > > > > Yes. That is correct. The lag between Debian stable and the corresponding > Devuan stable release is why we recommend using the release name rather that > the suite name in /etc/apt/sources.list > > Please see https://www.devuan.org/os/releases for more information. Where the Devuan release codenames chart sems to be up-to-date, but the examples in the Codenames or suites? section still refer to Beowulf as testing. Which was probaboly corect "As of this writing" but is no longer correct and potentially confusing. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On Sunday 13 December 2020 at 14:25:37, tito via Dng wrote: > On Sun, 13 Dec 2020 10:45:56 +0100 Antony Stone wrote: > > > > From Ascii onwards I get the errors: > > > > udevd[441]: Error changing net interface name eth2 to eth0: File > > exists udevd[441]: could not rename interface '4' from 'eth2' to > > 'eth0': File exists > > Hi, > they cannot be renamed because the name is already taken Yes, I can see that from dmesg. > NIC1 NIC2 NIC3 > eth0 eth1 eth2 (you have) > eth1 eth0 eth2 (you want) > > udevd[441]: Error changing net interface name eth2 to eth0: File exists > udevd[441]: could not rename interface '4' from 'eth2' to 'eth0': File > exists > > so renaming fails, use predictable names (remove ifnames=0) Makes no difference. > NIC1 NIC2 NIC3 > en1p1 en2p1 en3p1 (you have) > eth1 eth0 eth2 (you want) Those are not the names I get. It doesn't matter whether I have: net.ifnames=0 net.ifnames=1 no mention of net.ifnames at all In every case I get eth0, eth1 (PCI card) and eth2 (motherboard). Antony. -- Why are they called "The Rocky Mountains"? What are other mountains made of? Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On Sun, 13 Dec 2020 14:25:37 +0100
tito via Dng wrote:
> On Sun, 13 Dec 2020 10:45:56 +0100
> Antony Stone wrote:
>
> > On Sunday 13 December 2020 at 09:25:24, terryc wrote:
> >
> > > On Sat, 12 Dec 2020 14:15:53 +0100
> > >
> > > Antony Stone wrote:
> > > > Hi.
> > > >
> > > > I've just installed a couple of Beowulf systems, each of which
> > > > has three ethernet interfaces; one on the motherboard, and two
> > > > on a PCI card.
> > > >
> > > > I'm trying to work out how to give those interfaces the names I
> > > > want; the motherboard as eth0, and the PCI card as eth1 / eth2.
> > >
> > > Err, what is not clear in 'man interfaces'
> >
> > If you're referring to the "mapping" section, I've tried that and it
> > doesn't help.
> >
> > > FWIW, I've just had to do a fresh install of Beowulf and as I
> > > always do I manuay define /etc/network/interfaces, e.g.
> > >
> > > # The primary network interface
> > > allow-hotplug eth0
> > > iface eth0 inet static
> > > address 192.168.x.y
> > > netmask 255.255.0.0
> > > gateway 192.168.x.z
> > >
> > > Just add the line
> > > hwaddress mac:add:dress:in:usual:format
> > >
> > > to match eth2 & eth3 to the desired card.
> >
> > I think that's entirely the wrong way round.
> >
> > Setting hwaddress in /etc/network/interfaces changes the MAC address
> > of the interface according to its name (eth0, eth1, etc).
> >
> > I'm looking for the opposite - I want to make sure that the device
> > whose MAC address is 78:ac:c0:f7:89:f7 gets called "eth0" (instead
> > of "eth2", which is what I get from the kernel), and that the
> > devices with MAC addresses 00:e0:4c:80:21:6b and 00:e0:4c:80:21:6c
> > get called "eth1" and "eth2" respectively, instead of "eth0" and
> > "eth1".
> >
> > I can only repeat - under Jessie and earlier, this was all handled
> > by the settings in /etc/udev/rules.d/70-persistent-net.rules
> >
> > From Ascii onwards I get the errors:
> >
> > udevd[441]: Error changing net interface name eth2 to eth0: File
> > exists udevd[441]: could not rename interface '4' from 'eth2' to
> > 'eth0': File exists
>
> Hi,
> they cannot be renamed because the name is already taken
>
> NIC1 NIC2 NIC3
> eth0 eth1 eth2 (you have)
> eth1 eth0 eth2 (you want)
>
> udevd[441]: Error changing net interface name eth2 to eth0: File
> exists udevd[441]: could not rename interface '4' from 'eth2' to
> 'eth0': File exists
>
> so renaming fails, use predictable names (remove ifnames=0)
>
> NIC1 NIC2 NIC3
> en1p1 en2p1 en3p1 (you have)
> eth1 eth0 eth2 (you want)
>
> as there is no name clash the interfaces can be renamed by
> macaddress with udev rules
>
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:11:22:33:44:51", ATTR{type}=="1", KERNEL=="?*",
> NAME:="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:11:22:33:44:52", ATTR{type}=="1", KERNEL=="?*",
> NAME:="eth1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:11:22:33:44:53", ATTR{type}=="1", KERNEL=="?*",
> NAME:="eth2" This works for me on my devuan routers and I was bitten
> by what you are experiencing when I thought that adding ifname=0 was
> a good idea. It was not and at the next reboot the interfaces could
> not be reordered to my liking anymore and were assigned in a wrong
> way which locked me out of the router and broke internet for the joy
> of my coworkers.
>
> Ciao,
> Tito
P.S.: to make the renaming happen earlier you can add your persistent
net names file to the initrd in /usr/lib/udev/rules.d/ by hand but
probably this can be made automatic.
> > and so on.
> >
> >
> > Antony.
> >
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On Sun, 13 Dec 2020 10:45:56 +0100
Antony Stone wrote:
> On Sunday 13 December 2020 at 09:25:24, terryc wrote:
>
> > On Sat, 12 Dec 2020 14:15:53 +0100
> >
> > Antony Stone wrote:
> > > Hi.
> > >
> > > I've just installed a couple of Beowulf systems, each of which has
> > > three ethernet interfaces; one on the motherboard, and two on a
> > > PCI card.
> > >
> > > I'm trying to work out how to give those interfaces the names I
> > > want; the motherboard as eth0, and the PCI card as eth1 / eth2.
> >
> > Err, what is not clear in 'man interfaces'
>
> If you're referring to the "mapping" section, I've tried that and it
> doesn't help.
>
> > FWIW, I've just had to do a fresh install of Beowulf and as I
> > always do I manuay define /etc/network/interfaces, e.g.
> >
> > # The primary network interface
> > allow-hotplug eth0
> > iface eth0 inet static
> > address 192.168.x.y
> > netmask 255.255.0.0
> > gateway 192.168.x.z
> >
> > Just add the line
> > hwaddress mac:add:dress:in:usual:format
> >
> > to match eth2 & eth3 to the desired card.
>
> I think that's entirely the wrong way round.
>
> Setting hwaddress in /etc/network/interfaces changes the MAC address
> of the interface according to its name (eth0, eth1, etc).
>
> I'm looking for the opposite - I want to make sure that the device
> whose MAC address is 78:ac:c0:f7:89:f7 gets called "eth0" (instead of
> "eth2", which is what I get from the kernel), and that the devices
> with MAC addresses 00:e0:4c:80:21:6b and 00:e0:4c:80:21:6c get called
> "eth1" and "eth2" respectively, instead of "eth0" and "eth1".
>
> I can only repeat - under Jessie and earlier, this was all handled by
> the settings in /etc/udev/rules.d/70-persistent-net.rules
>
> From Ascii onwards I get the errors:
>
> udevd[441]: Error changing net interface name eth2 to eth0: File
> exists udevd[441]: could not rename interface '4' from 'eth2' to
> 'eth0': File exists
Hi,
they cannot be renamed because the name is already taken
NIC1 NIC2 NIC3
eth0 eth1 eth2 (you have)
eth1 eth0 eth2 (you want)
udevd[441]: Error changing net interface name eth2 to eth0: File exists
udevd[441]: could not rename interface '4' from 'eth2' to 'eth0': File
exists
so renaming fails, use predictable names (remove ifnames=0)
NIC1 NIC2 NIC3
en1p1 en2p1 en3p1 (you have)
eth1 eth0 eth2 (you want)
as there is no name clash the interfaces can be renamed by
macaddress with udev rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:11:22:33:44:51", ATTR{type}=="1", KERNEL=="?*", NAME:="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:11:22:33:44:52", ATTR{type}=="1", KERNEL=="?*", NAME:="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:11:22:33:44:53", ATTR{type}=="1", KERNEL=="?*", NAME:="eth2"
This works for me on my devuan routers and I was bitten by what you are
experiencing when I thought that adding ifname=0 was a good idea.
It was not and at the next reboot the interfaces could not be reordered to my
liking anymore and were assigned in a wrong way which locked
me out of the router and broke internet for the joy of my coworkers.
Ciao,
Tito
> and so on.
>
>
> Antony.
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On Sunday 13 December 2020 at 13:02:45, Florian Zieboll via Dng wrote:
> Am 13. Dezember 2020 12:01:39 MEZ schrieb Antony Stone
:
> > Well, here's the output from "dmesg | grep eth". It shows the r8169
> > interfaces being given names eth0, eth1 (the ones I want as eth1 and
> > eth2), then the tg3 interface gets called eth2 (which I want as eth0).
> >
> > At 6 seconds in, you can see my 70-persistent-net.rules file kicking in
> > and renaming then to xeth2, xeth1 and xeth0; then finally at 12 seconds,
> > the second rename in /etc/network/interfaces sets them back to eth0,
> > eth1 and eth2 in the order I want them.
>
> So have you tried with 'ifnames=1'?
I hadn't, but I've just done so now - it makes no difference - here's dmesg:
[0.00] Linux version 4.19.0-10-amd64 (debian-ker...@lists.debian.org)
(gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-amd64
root=UUID=9cbc8bd3-4cb8-4ae1-92c5-5a3659e9aed6 ro net.ifnames=1 quiet
[3.394364] r8169 :04:00.0 eth0: RTL8168e/8111e, 00:e0:4c:80:21:6b, XID
2c20, IRQ 30
[3.394368] r8169 :04:00.0 eth0: jumbo features [frames: 9200 bytes, tx
checksumming: ko]
[3.450174] r8169 :05:00.0 eth1: RTL8168e/8111e, 00:e0:4c:80:21:6c, XID
2c20, IRQ 31
[3.450177] r8169 :05:00.0 eth1: jumbo features [frames: 9200 bytes, tx
checksumming: ko]
[3.489342] tg3 :07:00.0 eth2: Tigon3 [partno(BCM95723) rev 5784100]
(PCI Express) MAC address 78:ac:c0:f7:89:f7
[3.489347] tg3 :07:00.0 eth2: attached PHY is 5784 (10/100/1000Base-T
Ethernet) (WireSpeed[1], EEE[0])
[3.489350] tg3 :07:00.0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0]
TSOcap[1]
[3.489352] tg3 :07:00.0 eth2: dma_rwctrl[7618] dma_mask[64-bit]
[6.187233] tg3 :07:00.0 xeth0: renamed from eth2
[6.231916] r8169 :05:00.0 xeth2: renamed from eth1
[6.246745] r8169 :04:00.0 xeth1: renamed from eth0
> And are you sure, that the 'hwaddress' lines in your
> '/etc/network/interfaces' really define which NIC to use?
I'm not using hwaddress in that file - that was a suggestion from terryc, and I
think it's the wrong idea for exactly the following reason:
> AFAICT this option just changes ("spoofs") the MAC address of the NIC for
> which it is defined. Although the log confirms that finally eth0 is the tg3
> NIC, this seems unusual (and very counterintuitive) to me.
Thanks,
Antony.
--
"I find the whole business of religion profoundly interesting. But it does
mystify me that otherwise intelligent people take it seriously."
- Douglas Adams
Please reply to the list;
please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
Am 13. Dezember 2020 12:01:39 MEZ schrieb Antony Stone
:
> Well, here's the output from "dmesg | grep eth". It shows the r8169
> interfaces being given names eth0, eth1 (the ones I want as eth1 and eth2),
> then the tg3 interface gets called eth2 (which I want as eth0).
>
> At 6 seconds in, you can see my 70-persistent-net.rules file kicking in and
> renaming then to xeth2, xeth1 and xeth0; then finally at 12 seconds, the
> second
> rename in /etc/network/interfaces sets them back to eth0, eth1 and eth2 in
> the
> order I want them.
So have you tried with 'ifnames=1'?
And are you sure, that the 'hwaddress' lines in your '/etc/network/interfaces'
really define which NIC to use? AFAICT this option just changes ("spoofs") the
MAC address of the NIC for which it is defined. Although the log confirms that
finally eth0 is the tg3 NIC, this seems unusual (and very counterintuitive) to
me.
libre Grüße,
Florian
--
Florian Zieboll
Hauptstraße 6a
D-68535 Edingen
Telefon: +49 6203 925 78 36
Mobil: +49 160 690 15 87
E-Mail: f.zieb...@web.de
PGP keyID: 0xEE454979FE441FD6
Chat / xmpp: f.zieb...@xabber.de
Chat / matrix: @florian_zieboll:feneas.org
WWW: https://www.zwischenspeicher.info
[message sent otg]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On Sunday 13 December 2020 at 11:23:21, Florian Zieboll via Dng wrote: > Am 13. Dezember 2020 10:45:56 MEZ schrieb Antony Stone: > > From Ascii onwards I get the errors: > > > > udevd[441]: Error changing net interface name eth2 to eth0: File exists > > udevd[441]: could not rename interface '4' from 'eth2' to 'eth0': File > > exists > > > > and so on. > > Does the bootlog give a hint, which service did assign the conflicting > ifnames udevd can't change? Well, here's the output from "dmesg | grep eth". It shows the r8169 interfaces being given names eth0, eth1 (the ones I want as eth1 and eth2), then the tg3 interface gets called eth2 (which I want as eth0). At 6 seconds in, you can see my 70-persistent-net.rules file kicking in and renaming then to xeth2, xeth1 and xeth0; then finally at 12 seconds, the second rename in /etc/network/interfaces sets them back to eth0, eth1 and eth2 in the order I want them. [3.374572] r8169 :04:00.0 eth0: RTL8168e/8111e, 00:e0:4c:80:21:6b, XID 2c20, IRQ 30 [3.374576] r8169 :04:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] [3.433052] r8169 :05:00.0 eth1: RTL8168e/8111e, 00:e0:4c:80:21:6c, XID 2c20, IRQ 31 [3.433056] r8169 :05:00.0 eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko] [3.488464] tg3 :07:00.0 eth2: Tigon3 [partno(BCM95723) rev 5784100] (PCI Express) MAC address 78:ac:c0:f7:89:f7 [3.488468] tg3 :07:00.0 eth2: attached PHY is 5784 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) [3.488471] tg3 :07:00.0 eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] [3.488474] tg3 :07:00.0 eth2: dma_rwctrl[7618] dma_mask[64-bit] [6.139566] r8169 :05:00.0 xeth2: renamed from eth1 [6.168205] r8169 :04:00.0 xeth1: renamed from eth0 [6.186586] tg3 :07:00.0 xeth0: renamed from eth2 [ 10.930250] IPv6: ADDRCONF(NETDEV_UP): xeth0: link is not ready [ 12.460422] tg3 :07:00.0 eth0: renamed from xeth0 [ 12.533793] r8169 :04:00.0 xeth1: unable to load firmware patch rtl_nic/rtl8168e-2.fw (-2) [ 12.645721] IPv6: ADDRCONF(NETDEV_UP): xeth1: link is not ready [ 12.672414] r8169 :04:00.0 eth1: renamed from xeth1 [ 12.742780] r8169 :05:00.0 xeth2: unable to load firmware patch rtl_nic/rtl8168e-2.fw (-2) [ 12.853714] IPv6: ADDRCONF(NETDEV_UP): xeth2: link is not ready [ 12.880384] r8169 :05:00.0 eth2: renamed from xeth2 [ 13.727991] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 13.961821] bond0: Enslaving eth1 as an active interface with a down link [ 14.081838] bond0: Enslaving eth2 as an active interface with a down link [ 16.522996] tg3 :07:00.0 eth0: Link is up at 1000 Mbps, full duplex [ 16.523020] tg3 :07:00.0 eth0: Flow control is on for TX and on for RX [ 16.523074] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready If I can post anything else which shows the detail you're after, please let me know where it would be recorded. Thanks, Antony. -- This email was created using 100% recycled electrons. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
Am 13. Dezember 2020 10:45:56 MEZ schrieb Antony Stone : > From Ascii onwards I get the errors: > > udevd[441]: Error changing net interface name eth2 to eth0: File exists > udevd[441]: could not rename interface '4' from 'eth2' to 'eth0': File exists > > and so on. Does the bootlog give a hint, which service did assign the conflicting ifnames udevd can't change? -- [message sent otg] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On Sunday 13 December 2020 at 09:25:24, terryc wrote: > On Sat, 12 Dec 2020 14:15:53 +0100 > > Antony Stone wrote: > > Hi. > > > > I've just installed a couple of Beowulf systems, each of which has > > three ethernet interfaces; one on the motherboard, and two on a PCI > > card. > > > > I'm trying to work out how to give those interfaces the names I want; > > the motherboard as eth0, and the PCI card as eth1 / eth2. > > Err, what is not clear in 'man interfaces' If you're referring to the "mapping" section, I've tried that and it doesn't help. > FWIW, I've just had to do a fresh install of Beowulf and as I always do > I manuay define /etc/network/interfaces, e.g. > > # The primary network interface > allow-hotplug eth0 > iface eth0 inet static > address 192.168.x.y > netmask 255.255.0.0 > gateway 192.168.x.z > > Just add the line > hwaddress mac:add:dress:in:usual:format > > to match eth2 & eth3 to the desired card. I think that's entirely the wrong way round. Setting hwaddress in /etc/network/interfaces changes the MAC address of the interface according to its name (eth0, eth1, etc). I'm looking for the opposite - I want to make sure that the device whose MAC address is 78:ac:c0:f7:89:f7 gets called "eth0" (instead of "eth2", which is what I get from the kernel), and that the devices with MAC addresses 00:e0:4c:80:21:6b and 00:e0:4c:80:21:6c get called "eth1" and "eth2" respectively, instead of "eth0" and "eth1". I can only repeat - under Jessie and earlier, this was all handled by the settings in /etc/udev/rules.d/70-persistent-net.rules From Ascii onwards I get the errors: udevd[441]: Error changing net interface name eth2 to eth0: File exists udevd[441]: could not rename interface '4' from 'eth2' to 'eth0': File exists and so on. Antony. -- Python is executable pseudocode. Perl is executable line noise. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
Martin Steigerwald - 13.12.20, 09:29:26 CET: > The history on this laptop dates back till May 2011. And I have older > machines where I used it. It may be that for this laptop I just cloned > the bzr branch of the older laptop, then did a diff to see which > files to adapt and continued with the bzr branch of the older laptop. > I still love to use brz – cause I prefer it usability wise -, but I > probably will switch to git for new machines. On the other hand, it > does not really matter. Lol, now I just read the first changelog entry. And no, I did not copy over the repo, at this time I decided to start from scratch. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
Olaf Meeuwissen via Dng - 13.12.20, 03:48:23 CET: > Hi Hendrik, > > Hendrik Boom writes: > > I wish everything user-configurable under /etc was under revision > > control. then we might even be able to have a vendor branch and a > > local branch. > Have a look at etckeeper. > > I've been using that for several years now on a variety of machines. > The log for the machine I'm writing this on goes back all the way to > its initial install on 2017-01-11 of Devuan's Jessie Official Beta2 > :-) > > You may want to keep your sensitive /etc/ files out of the repository > though, depending on your level of paranoia. I still do not use etckeeper, cause I prefer to just add the files to the repository that I actually change. This way, whenever I like to replicate the config onto another machine or even just look at what I changed, I can just clone the repository and have exactly a tree of those files that I adapted. Of course, Ansible would be also an alternative. I am just not completely sure whether it makes sense with just a few machines. I may start to use it with hosted virtual machines as it eases moving to a different provider if need be. I do not care about all the automatic changes by package upgrades. The history on this laptop dates back till May 2011. And I have older machines where I used it. It may be that for this laptop I just cloned the bzr branch of the older laptop, then did a diff to see which files to adapt and continued with the bzr branch of the older laptop. I still love to use brz – cause I prefer it usability wise -, but I probably will switch to git for new machines. On the other hand, it does not really matter. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
Olaf Meeuwissen via Dng wrote: > > Have a look at etckeeper. > was using it for years, but not anymore.. too much disk i/o, too many files, `git gc` never ran (only by hand), and it never really came handy during those years... maybe storing etckeeper repo it in a different backup disk makes more sense, but anyway..., backups, backups, backups. :) d. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ethernet names revisited
On Sat, 12 Dec 2020 14:15:53 +0100 Antony Stone wrote: > Hi. > > I've just installed a couple of Beowulf systems, each of which has > three ethernet interfaces; one on the motherboard, and two on a PCI > card. > > I'm trying to work out how to give those interfaces the names I want; > the motherboard as eth0, and the PCI card as eth1 / eth2. Err, what is not clear in 'man interfaces' FWIW, I've just had to do a fresh install of Beowulf and as I always do I manuay define /etc/network/interfaces, e.g. # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.x.y netmask 255.255.0.0 gateway 192.168.x.z Just add the line hwaddress mac:add:dress:in:usual:format to match eth2 & eth3 to the desired card. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
