2023-03-04, Jeffrey Walton <noloa...@gmail.com> wrote:
> On Sat, Mar 4, 2023 at 12:12 PM David Wright <deb...@lionunicorn.co.uk> wrote:
>>
>> On Sat 04 Mar 2023 at 01:02:54 (-0500), Jeffrey Walton wrote:
>> > On Fri, Mar 3, 2023 at 6:10 PM Greg Wooledge <g...@wooledge.org> wrote:
>> > > On Fri, Mar 03, 2023 at 05:45:54PM -0500, Jeffrey Walton wrote:
>> > > > The 'p' is a pci bus, the 's' is a slot number. Since the interface
>> > > > does not move around once installed, the interface will always have
>> > > > the same name like 'enp4s0'.
>> > >
>> > > That's a wonderful idea, but it doesn't quite work in practice. There
>> > > are
>> > > ways that a "predictable" interface name may change. A BIOS/firmware
>> > > upgrade can do it. Adding or removing devices can also do it, in
>> > > some cases. They don't even have to be network interfaces.
>> >
>> > Yeah, that's udev and systemd screwing things up.
>>
>> Not really. You've got plenty of choice:
>>
>> net.ifnames=0, biosdevname=0 (on Dell), and
>> NamePolicy={kernel,database,onboard,slot,path,mac,keep}
>
> If you are creating the problem you should not be surprised there is a
> problem.
>
> Jeff
>
>
https://wiki.debian.org/NetworkInterfaceNames
* UNPREDICTABILITY
it turns out even after all this [**an enumeration of complications and corner
cases**] there are still reported cases of interfaces changing their name on a
reboot. All that needs to happen is that some buggy BIOS (or some new, less
buggy version of a driver module, or systemd's naming policy) changes its mind
about some detail like whether or not your hardware counts as the kind that
should have an ONBOARD name. There are even multiple reports of devices
changing their PCI-port numbering due to other hardware being installed.
