• Re: Cubox-i bullseye -> bookworm Upgrade failure

    From RobJE Debian ARM@21:1/5 to Rainer Dorsch on Fri Aug 4 10:10:01 2023
    Hi,

    On 04-08-2023 08:55, Rainer Dorsch wrote:
    Hi,

    I did a test installation with a bullseye installer on a cubox-i and then upgraded to bookworm. After the upgrade the network was gone. Even booting with the previous kernel 5.10.0-23-armmp does not bring the network back.

    Any hints and ideas are welcome.

    I'd check if /etc/network/interfaces has end0 or something else (like
    eth0). Probably the network interface got renamed as part of the upgrade.

    root@test-machine:~# uname -a
    Linux test-machine 6.1.0-10-armmp #1 SMP Debian 6.1.38-2 (2023-07-27) armv7l GNU/Linux
    root@test-machine:~#

    root@test-machine:~# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
    valid_lft forever preferred_lft forever
    2: end0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether d0:63:b4:00:2b:ac brd ff:ff:ff:ff:ff:ff
    root@test-machine:~#

    ifup does not seem to know end0:
    root@test-machine:~# ifup end0
    ifup: unknown interface end0
    root@test-machine:~#
    [SNIP]


    Many thanks
    Rainer


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Reco@21:1/5 to Rainer Dorsch on Fri Aug 4 10:30:01 2023
    Hi.

    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.

    Reco

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Dorsch@21:1/5 to All on Mon Aug 7 09:40:01 2023
    Am Freitag, 4. August 2023, 09:57:18 CEST schrieb RobJE Debian ARM:
    Hi,

    On 04-08-2023 08:55, Rainer Dorsch wrote:
    Hi,

    I did a test installation with a bullseye installer on a cubox-i and then upgraded to bookworm. After the upgrade the network was gone. Even booting with the previous kernel 5.10.0-23-armmp does not bring the network back.

    Any hints and ideas are welcome.

    I'd check if /etc/network/interfaces has end0 or something else (like
    eth0). Probably the network interface got renamed as part of the upgrade.

    Good that my devices have a serial console. But I remember that there are also cubox-i devices out there without. Thus if they try to update, they will fail and have to reinstall.

    Should Reco's comment

    Try adding "net.ifnames=0" to kernel's commandline.

    go into the release notes for armhf?

    Thanks
    Rainer

    --
    Rainer Dorsch
    http://bokomoko.de/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Langasek@21:1/5 to Reco on Mon Aug 14 00:10:11 2023
    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.

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

    --
    Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmTZUMMACgkQVo0w8yGy Ez1oKg//a2CUdSxySFcllJfbaIsboTtDQxqDFX+3yezmIN7qFrNsO4nhVfccC0uz 810LmIaOAG6Eh6FpE5xkqSkGz9ZqHg60xL7CCrzgSIDskvOstTkFwfpR5XvpHli+ PNo+Ui/EYH33JKM0FaugSm+TJXi7UhaZ1Y0aXxDQHoZywD18hpsVG1G5lD8Xiu5u EejTuDqynOnL1EnEzoEGL8b/Qa5RFi/dAvdM3NDrEZgl8V64A95LQwgwl5svrz30 6Ccec3acOiHcAMRUDzhiVGpqu4afqI8Pa+KmPNuwauma+wjK7IMgXNiCwEnLz9vE TXny1365m9KPL7vl5OdN1gYqHQkaV5/gs81BAFjEBygj0yiCGiAtlUanabpR5SCg AcxzhgqSOFZ4B5W4Dtknf2xfQaUv3bGmnnGioSojZnJO0IhW6YB3tLu1U91FK7+y kSWMCN67lYWOTYmHk2qpZH8Egm7jEwUErtvsiK1n/wLHE0XEkIXcgmmBGnjpmIzp C1eq02Yqq3JWs4LYJ6XBeLujCX1AUrpJQSbOMAgYeXTYgyvmVakahhbeVU434m/O Yjj9uCH5BWG1sTdJU1il
  • From Reco@21:1/5 to Steve Langasek on Mon Aug 14 07:10:01 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Langasek@21:1/5 to Reco on Tue Aug 15 21:40:01 2023
    On Mon, Aug 14, 2023 at 08:02:32AM +0300, Reco wrote:
    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 :)

    Can one not? That seems like something that should be addressed in
    general, then.

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

    So is breaking user's setup.

    Yes, but *having done so*, trying to roll back the new default behavior
    instead of leaning into it is just going to cause more problems down the
    line.

    You have to make changes to config files in response to this change, so it might as well be /etc/network/interfaces instead of your bootloader config.

    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 ;)

    I think that's a very good idea. https://bugs.debian.org/release-notes ?

    --
    Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmTb0qAACgkQVo0w8yGy Ez2hxg//cojNZrQ8eXfiRpwqDImckVYjBw5lr4uVQljBVRqGszQeeJ6Ass6RSMel AYtdH5L2ubbaNdfKkqxqCkt8ZfdqDmRHraLq5TfhfrvkXA2xqdGnfvUQAKR2ePc9 HKgcWBDP2fyWV61wVfii46L0OJtNKl2eZGMxdzPM2RELSoKZq7CR9CUu3Rd43m9I wDxr13x6YurIug7VJjBgahomCVTxYD0v2Lb/yyfoY3DxFheHLdtLVK3uFSIdrIdo Yaozx0oLcA22C1ow/EIYgW4e8rVFG+QhoxEKKaSAoqZg4hD/lC2xxYjuc7ExhUb5 EX1bAH34fHT3ZOohAgN+gqPhXpLOeHL53afmf8KwOVos8cNI+extWSM7NGdF18cR m3ZA7QSqZNdqN6mFlR9vIpCbYjbuK9H/IpyJMIooPCnH3NRHDpJx5aY7yXtAOGc6 hoHM6Iiav6tj+iBnHN18RIeDAo5cJG36YM64f3l5yDB6FlRvdwZhVa5N2o/ZQVNX fZdIZzQ1ZiRyVw/73TJcHgtsz42Bq6+by5+M/YKecNxTX9GC5cby6/aHaxMvx4OU uHyAdrQ/a/nB2O4tah6d
  • From Paul Wise@21:1/5 to Reco on Wed Aug 16 05:20:01 2023
    On Fri, 2023-08-04 at 10:55 +0300, Reco wrote:

    Enjoy your (un)Predictable Interface Names.
    Try adding "net.ifnames=0" to kernel's commandline.

    Personally, I would switch away from hardcoding interface names.
    ifupdown can do interface name wildcards and mac matching.

    The other solutions for this problem (systemd-networkd, NetworkManager, ifupdown-ng, probably ifupdown2) are much more flexible though.

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmTcP3AACgkQMRa6Xp/6 aaMi+A/6A67DYOyyvr7qYEDwXlLoQ17qrnb44/iPM9ncUkQTkkHKh08l6TNIulpJ aVvyTEXyV7loTMu+hgo4aYjSZ7Uo+C8bVPkr/NQ2VQb14gWrK3oo7SlIq0DiYlz8 NyI6vD/iNYuIkx5QJYyVqncxIdMCjjNX3wLVCC8kqHiHcDKWEgP6l9/pqZ0DXdXM A3MQVohZIGZwy1I8fArcxRi4eHFQ1nUDb6/KNNNZjkrTlZ4blCRMFircH4/PPOcE OfakYywFGDbW3JC4qfGpGiU19G8Yrr2hkw2rqQdp7Oa0I/C6+veelucriAFKCY09 wv7FSPnqQyPZokCxo+G7AoONTu9AbcmIhWJCeKpXbu64Abhvjt31/qpY9RLiL3mW suigl3oq6ewX84pqVQtrKKs1JFdGVgSNtL8pUp2znzC2Y/xN9U3g9sbShdpDKhId WG5r19F8Y4epKYlsUg8FDlvunCqI6TuqvTcgoTkLD1Voa1/UrYz+TkCqruuaQ/9T z3CkaQm5fNAK1+y2+C/iYgDm1ahgQJ4GT0cMnYPmIFFabdI26q3Jzz97AKSBTr66 GNIE7p92Ub/26XMt2tPNMq9f6aew+vN9xMaI1vyU4LjbfJuu/szAFF5stym8sWj/ Bks0bnXFS1ExhiK3T8wmf/fQXcr20s9QOVPA4bS/adzJD0+R9no=
    =vvh9
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Dorsch@21:1/5 to All on Tue Aug 29 14:40:01 2023
    Am Dienstag, 15. August 2023, 21:31:50 CEST schrieb Steve Langasek:
    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 ;)

    I think that's a very good idea. https://bugs.debian.org/release-notes ?

    That would be an improvement over the current status. Should I open a bug report?

    Though if there would a meaningful (=not many false positives and false negatives) message during the upgrade, that would be much better. Users tend not to read release notes...

    Also I think the issue goes much beyond ifupdown, e.g. shorewall uses network interface names in its config files as well.

    Thanks
    Rainer

    --
    Rainer Dorsch
    http://bokomoko.de/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Langasek@21:1/5 to Rainer Dorsch on Tue Aug 29 17:30:02 2023
    On Tue, Aug 29, 2023 at 02:38:20PM +0200, Rainer Dorsch wrote:
    Am Dienstag, 15. August 2023, 21:31:50 CEST schrieb Steve Langasek:
    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 ;)

    I think that's a very good idea. https://bugs.debian.org/release-notes ?

    That would be an improvement over the current status. Should I open a bug report?

    I would encourage this, yes.

    --
    Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmTuDa0ACgkQVo0w8yGy Ez3TRQ//cthiUW8N351oGVfILtfX+FzvuI3AFlysXhOmX/Sxw7wpE93kYP9XtqKU b+PeufhxP1knVsDCUuOrCb/cLDcaLrUALd9D00FGbH4lgqeceocibBqK0V0Kxhdk gVy21T0Aub6Mepj5r0u/neYDzBiF97d+OHrlsqcs+/uhgAMFL4VlW9FpmGk+yjmK MSV+4SjZQTb5GSYGbpsUiv1BcRGlfY+9V9KpCec65X5pisVb91d/vEPYuDLA+ghh CclaT8R98cAILWScaMCb2I0PsCTJu5UoTqzTq11b9rCmImw5PJsvWhp4B2Y5PRAi XHX7tTULddtfruqFcglfvjM5Hw2k0gVTI8wra7bdSeWtrCVN4jzauosfh2cDxkqf VVDejXvD1RVv+wH4EW3ZhxblO5t952/TdZGMEgTsXd+atmMnrkfbHqaIJ2S+ZFs9 P68iNSjZd5B9K+aeznT8mJaQhX5aOd7eGood/2sobk9urXpw3GYOZScTqYVJIXiG ga8D43R1N+uiKwpUmt7Rf6+yUaXjgv8vo3Y/VkvHTc6QLuZTChpgE8DM4WLCL62X 4nr1pNMY6T6DbtgHUkBL
  • From Rainer Dorsch@21:1/5 to All on Wed Aug 30 09:40:01 2023
    Am Dienstag, 29. August 2023, 17:24:30 CEST schrieb Steve Langasek:
    On Tue, Aug 29, 2023 at 02:38:20PM +0200, Rainer Dorsch wrote:
    Am Dienstag, 15. August 2023, 21:31:50 CEST schrieb Steve Langasek:
    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 ;)

    I think that's a very good idea. https://bugs.debian.org/release-notes
    ?

    That would be an improvement over the current status. Should I open a bug report?

    I would encourage this, yes.

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050833

    Justin followed up with a question:

    Are you saying that armhf machines still used one of the old interface
    naming schemes (https://wiki.debian.org/NetworkInterfaceNames) on
    bullseye, and hadn't yet switched over to "predictable" names?

    That is what I observed after installing bullseye and upgrading to bookworm.
    If anybody has insight why armhf did that later, please share there. Also any other follow-up discussion probably should happen in the bugreport.

    Many thanks
    Rainer

    --
    Rainer Dorsch
    http://bokomoko.de/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)