Re: Cubox-i bullseye -> bookworm Upgrade failure

[Reco <recoverym4n@enotuniq.net>]

	Hi.

On Sun, Aug 13, 2023 at 04:53:13PM -0500, Steve Langasek wrote:
> On Fri, Aug 04, 2023 at 10:55:44AM +0300, Reco wrote:
> > On Fri, Aug 04, 2023 at 08:55:21AM +0200, Rainer Dorsch wrote:
> > > dmesg reports for end0:
> > > [    7.771809] fec 2188000.ethernet eth0: registered PHC device 0
> > > [    7.942031] fec 2188000.ethernet end0: renamed from eth0
> 
> > Enjoy your (un)Predictable Interface Names.
> > Try adding "net.ifnames=0" to kernel's commandline.
> 
> They're perfectly predictable, they're just not backwards-compatible.

If one cannot predict the interface name after the reboot then obviously
Predictable Interface Names are not that predictable :)
I'm well aware of the limitations of systemd's "interface naming
scheme", and breaking user's setup on udev upgrade is only one of them.


> Forcing systems to use the legacy naming scheme to avoid the transition is
> short-sighted.

So is breaking user's setup.

How about alerting end-user that "did you know your interface name
will change after the reboot thus possibly breaking your network
configuration?". I heard there are certain Release Notes that were used
to say things like that in the past ;)

Or, how about adding debconf question to udev that will ask the user
"would you like to keep your current interface(s) name(s)"?

Or, since the kernel is actually capable of using alternative nic names,
how about teaching ifupdown using those?

Reco