Re: device name changed after upgrade to bookworm [was: Cubox-i bullseye -> bookworm Upgrade failure]
On 2023-08-04 10:01, Rainer Dorsch wrote:
I found the root cause of the issue myself:
In /etc/network/interfaces I had to replace eth0 with end0:
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto
I hope that helps somebody to debug his network issues.
Rainer
I hope that helps somebody to debug his network issues.
Rainer, Thank you very much for reporting your issue and workaround fix.
A couple days ago I had the same network issue after upgrading Debian
testing on Pine64 H64B (previous discussion:
https://lists.debian.org/debian-arm/2021/09/msg00001.html ). This is an
arm64 system. I was eventually able to get it running Debian testing,
but it had later stopped responding to remote logins after an upgrade
some weeks or months ago. So a couple days ago, I finally connected it
to a monitor and saw it was dropping to "emergency mode" when rebooted.
Oddly, logging in as root, doing essentially nothing except looking at
logs, df -h, etc, then continuing, it ran OK long enough to do an
upgrade that ran into the renamed ethernet interface issue. The good
news is: After renaming from eth0 to end0 in interfaces, ethernet worked
again. The bad news is: After upgrading another time, the system drops
to "emergency mode" after every reboot. I haven't had time to find
anything obvious in logs, or to add a comment to your bug report.
I have several other headless SBCs, mostly raspberry pis from 1 through
4. After getting them all running Debian testing, they have all slowly
stopped responding over the network after upgrades. One of them, also
just checked with a display, acts like it has a bad sd card, but I
expect others may be having this renamed interface issue, because they
were all originally set up with the same interfaces file using "eth0",
IIRC.
I know it's called "testing" for a reason, but for the most part my
experiences with testing on x86_64 desktop systems has been much more
stable, probably because network "just worked" without hand file
editing. :)
I'll be looking for better ways of setting up headless SBCs if anyone
has good pointers. Thanks!
Reply to: