[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: