Diagnostics | Performance Statistics | Network Interfaces

1st Official Post
    • New

    Solution found:


    1. Go to Network | Interfaces

    2. Add +, Select Ethernet

    3. Select device - end0, select Method DHCP

    4. Save


    Now we have end0 in Diagnostics | Performance Statistics | Network Interfaces

    Now eth0 could be deleted.


    Case closed.

    • New
    Quote from crashtest

    Out of curiosity, is this an R-PI or an Armbian SBC?
    (AND)
    Did you do an upgrade, like OMV6 to OMV7?

    Version

    7.7.5-1 (Sandworm)

    Processor
    Raspberry Pi 5 Model B Rev 1.1

    Kernel
    Linux 6.12.20+rpt-rpi-2712


    So this is my new RasPI 5 with latest RaspiOS Lite (2024-11-19) and as fresh installation. No upgrades, all things are proudly new installed. :o)

    • New
    • Official Post

    Did you follow this -> installation process?

    And run the following from the CLI?

    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash


    (The above is part of the referenced install process.)

    • New
    Quote from crashtest

    Did you follow this -> installation process?

    And run the following from the CLI?

    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash


    (The above is part of the referenced install process.)

    Yes. Sure.

    Exactly this way.

    I had experience with RPI4 since 2020 and have started with OMV5 and then OMV6 before.

    What are you trying to investigate? Interface end0? :o)

    • New
    Quote from crashtest

    Yep.

    Navigate to /etc/systemd/network Use the command ls and tell me if you see the following file:

    10-persistent-eth0.link

    No. I do not see it. I see just 73-usb-net-by-mac.link

    May be it was there, but as i mentioned before, eth0 could be deleted after end0 is created/added to Interfaces. And so i did. :o)


    P.S. end0 - is a physical interface, with real MAC-address. I believe, OMV did renamed/created it during installation process, but leaves eth0 - that's why we see it with no data-traffic.

    • New
    • Official Post

    Thanks for doing that. It was helpful.
    As a side note, the file 73-usb-net-by-mac.link is an R-PI default. The purpose of the 10-persistent-eth0.link is to override the Predictable Network Interface Naming scheme which creates a networking problem on R-PI's .
    ________________________________________________________________

    Now I have a couple more questions and a caution. Let me start with the caution statement. Your install may be in a precarious state.

    I believe the reason why you're NOT having trouble is:
    - You're running DHCP
    (AND)
    - You haven't made any changes to networking. (Like setting a static IP, setting a DNS server, etc.)

    My recommendation is that you DO NOT change any network settings under, Network, Interfaces If you do, it's likely that your R-PI will stop responding to the network. (Which, while it might be possible to fix it, the most time efficient way to "fix the issue" is a rebuild.)

    _________________________________________________________________

    What I can't explain is why your install reverted back to end0.

    When you built your R-PI, the following script creates 10-persistent-eth0.link. Then the script checks for the MAC address of your R-PI's wired interface and names it eth0, by adding the appropriator entries in the 10-persistent-eth0.link .

    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash

    (BTW: The higher priority, from the lower number "10", overrides the 73-* and other files that may exist with larger numbers. This prevents Predictive Naming from taking over.) After the recommended reboot, the OMV install is next and it picks the interface name eth0 from the 10-persistent-eth0.link.

    With the above noted:
    You said that you built from scratch and I have to believe that you ran the script because, at one point, your R-PI's interface name was eth0 - OMV picked that name up and wrote to it's DB. (What you did was rewrite the DB by manually adding the reverted name and deleting the nonexistent eth0.)

    The questions would be:
    - Did you notice when the name reverted to end0?
    - Was it after a kernel upgrade or some other system software upgrade (maybe a new networking package for example)?
    - Did you add an extra Ethernet or wireless interface, using a hardware USB dongle?


    I'm looking for an event that set the contents of the folder /etc/systemd/network back to it's default (removing 10-persistent-eth0.link). For testing, anything you may remember might be helpful. So far, all I'm aware of that resets that folder is a release version upgrade such as going from OMV6 to OMV7.

    • New
    Quote from crashtest

    The questions would be:
    - Did you notice when the name reverted to end0?
    - Was it after a kernel upgrade or some other system software upgrade (maybe a new networking package for example)?
    - Did you add an extra Ethernet or wireless interface, using a hardware USB dongle?


    I'm looking for an event that set the contents of the folder /etc/systemd/network back to it's default (removing 10-persistent-eth0.link). For testing, anything you may remember might be helpful. So far, all I'm aware of that resets that folder is a release version upgrade such as going from OMV6 to OMV7.

    - It is not reverted, it always been there after fresh install. See my initial post - end0 already there and functional. The same end0 was on my old RPI4.

    - Only "upgrades" i did are - sudo apt-get update -y && sudo apt-get full-upgrade -y, sudo rpi-eeprom-update and sudo rpi-eeprom-update -d -a at first ssh session and before OMV install.

    - Yes, i had USB-LAN Adapter once, connected in order to restore connectivity, after i have added end0 as "bridge" interface and lost connection. With usb-lan i had connection back and deleted failed "bridge" interface, added end0 as "ethernet" interface and then deleted eth0 because it has usb-lan-adapter MAC. And then switched back to onboard LAN.

    And now it works. Even with no DHCP with fixed IP.


    I still have my RPI4 and could install OMV "from scratch" for testing purposes.

    • New
    Quote from Dr_Werdenhoff

    at first ssh session and before OMV install.

    Before OMV install, the guide tell to run a "pre-install" script that would clear any post-install issues.


    That's what should be done.

    • New
    Quote from Soma

    Before OMV install, the guide tell to run a "pre-install" script that would clear any post-install issues.


    That's what should be done.

    Yes. This time i have did it. But i have never did it before, because i did not even seen it. Official page leads to docs., docs. leads to GitHub and there is only install-script and no pre-install script mentioned as mandatory. It would be better to make a remark there about it. But this is may be my fault too, that i have missed full guide but now i am enlightened.:)

    So, i did two installations today:

    1. First install: Run with pre-install script, install-script and i had proper eth0 in "Dashboard", "Network | Interfaces" and "Monitoring" and no another intrfaces available.


    2. Second install: Run only install-script and i had end0 in "Dashboard", no eth0 in "Dashboard" but empty in "Network | Interfaces" type as "Bond", without MAC, IP etc. and empty data in "Monitoring", Interface end0 is available as "new" in "Network | Interfaces". So i have added end0 as "Ethernet" & DHCP and now i have two interfaces:


    Now i am going to delete empty "Bond" eth0:


    Now i have only end0 and looks like it runs properly. Even in Static mode:

    • New
    Quote from Dr_Werdenhoff

    This time i have did it. But i have never did it before, because i did not even seen it.

    It's on the wiki and well mentioned.


    Quote from Dr_Werdenhoff

    Official page leads to docs., docs. leads to GitHub and there is only install-script and no pre-install script mentioned as mandatory.

    This is all done by volunteers.

    Keeping info up-to-date is not easy nor always possible.

    And Raspberry foundation makes changes to it's image that require some time to confirm that doesn't "break" other stuff.

    And yet, after a (can't remember which date) image update, one user ( crashtest ) figured out that running that specific script (pre-install) would prevent issues with the un/predictable network names.


    This info regarding similar situations can be searched on the forum although not easy.


    Perhaps by searching "predictable network"

    Suche - openmediavault

    • New
    • Official Post
    Quote from Dr_Werdenhoff

    Official page leads to docs., docs. leads to GitHub and there is only install-script and no pre-install script mentioned as mandatory. It would be better to make a remark there about it. But this is may be my fault too, that i have missed full guide but now i am enlightened. :)

    Noted. ryecoaaron might want to ref the pre-install script, for R-PI's on git-hub.

    Quote from Dr_Werdenhoff

    Now i have only end0 and looks like it runs properly. Even in Static mode:

    Here's the issue as I see it. I can't replicate what you seem to have (and I don't think aaron can either). Further it's simply not possible to build R-PI's with all the flavors of Debian and OMV, in all possible build combinations. (We had one user build using straight Debian arm64, unoptimized for his R-PI, then he came here with his issues.) In the recommended build, the preinstall script is not optional. Without it, there's no knowing when an update, a setting change, etc., might trigger the loss of networking.

    If you're running without the 10-persistent-eth0.link file.
    That's created by running the preinstall script
    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash 
    (followed a reboot) You have an unsupported build.

    Keep this in mind, if you lose your network connection. (In that event, to connect with the R-PI, you'll need to use the R-PI's HDMI console port.)

    • New

    crashtest  Soma

    TY guys for your advices and support!

    Now just FYI, may be helpful:

    Today i ran pre-install script on this RPI4 installation with this "precarious" end0 interface. It returned:

    _______________________________________________________________

    100%[===========]

    2025-04-30 23:44:19 (13.9 MB/s) - written to stdout [603/603]


    Reading package lists... Done

    Building dependency tree... Done

    Reading state information... Done

    jq is already the newest version (1.6-2.1).

    jq set to manually installed.

    0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

    Device "eth0" does not exist.

    mac - e4:5f:01: ...

    Please reboot the system now.

    _______________________________________________________________

    Rebooted.

    RPI4 restarted normally. Now main interface is eth0:

    end0 is no more operational, with no MAC and data transfer.

    eth0 is now available as new to add in Network | Interfaces:

    Successfully added with DHCP method and now monitored.

    end0 removed.

    Directory /etc/systemd/network now have both 10-persistent-eth0.link and 73-usb-net-by-mac.link.

    Success. Installation is now reverted to stable state.


    TY guys one more time! :thumbup:


    P.S. Just did the same on my main RPI5 installation with end0. Success!

    • New
    • Official Post

    I find it interesting that "something" erased the "10-persist*" file or, possibly, reset the contents of /etc/systemd/network back to the raspberrypios default. I'd like to know what caused it but, in computing, inexplicable "one off" scenarios happen on occasion.

    Quote from Dr_Werdenhoff

    Success. Installation is now reverted to stable state.

    I believe you're better off with eth0 fix. With this setup, you'll be in a larger R-PI group with a known build. If something happens, on a broad scale, the potential fix would apply to your build.

    Since "stuff" like this can happen, consider reading over the section on -> OS backup and -> cloning your SD-card.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login