Unable to set static ip address on rockpro64 from omv webui

  • Hello,



    My rockpro64 with omv is getting ip address from dhcp server (internet provider modem). When i change ip in webui and click apply I get below error.


    Code
    Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; systemctl start 'networking' 2>&1' with exit code '1': Job for networking.service failed because the control process exited with error code. See "systemctl status networking.service" and "journalctl -xe" for details.

    Below is output of "systemctl status networking.service"


    I was reading forums and one suggestion was to use omv-firstaid but when pressing enter on option no:1 I am getting bellow error. I am fine launching any other options.


    Code
    ERROR: dialog-like terminated due to an error: the dialog-like program exited with status 3 (which was passed to it as the DIALOG_ERROR environment variable). Sometimes, the reason is simply that dialog was given a height or width parameter that is too big for the terminal in use. Its output, with leading and trailing whitespace stripped, was:
    
    
    Error: Expected at least 5 tokens for --menu, have 4.
    Use --help to list options.

    Looking online I found that the issue was fixed in February release but I would like to stick with latest stable release which is 0.7.9 dated Jul 26, 2018.
    https://github.com/ayufan-rock64/linux-build/issues/306


    Code
    root@rockpro64:~# uname -a
    
    
    Linux rockpro64 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 GNU/Linux

    I tried below commands from ssh which I placed in file and made it executable, launched it but no changes.



    Bash
    #!/bin/bash
    ip addr flush dev eth0
    /etc/init.d/networking restart


    Is it possible to fix ip address change from webui in any manual way until stable release of rockpro64 will appear and i could use omv-firstaid?


    Thank you in advance for any advice

    • Offizieller Beitrag

    As I recently found:


    Network Manager is in control of network interfaces in Armbian images, which is the base OS for OMV on ARM devices. With Network Manger, the best thing to do is leave all references in the GUI's Network settings Tab blank (under System, Network, Interfaces Tab). Otherwise, if an address is configured in the GUI, an entry is made in /etc/network/interfaces where ifupdown gets involved.
    ((While I have no experience with it, I've been told ifupdown and Network Manager can conflict.))


    According to this -> thread; giving control back to Network Manager would mean deleting network interfaces, in the GUI, clearing all entries from /etc/network/interfaces and a reboot.
    ___________________________________________________________


    If you need a static address, it can be set up by using a reserved DHCP address at your router, or use nmtui.

  • Network Manager is in control of network interfaces in Armbian images, which is the base OS for OMV on ARM devices.

    No, there also exist the @ayufan images that are promoted on the Pine64 website for Pine64, Rock64 and RockPro64. For the first two boards also Armbian based images exist, for RockPro64 it's currently only ayufan. And here the issue is that the base image defines eth0 in a file below /etc/network/interfaces.d/ while OMV only wants to adjust /etc/network/interfaces itself. Once anything has happened in OMV UI wrt network conflicting entries exist but this has nothing to do with NetworkManager (also NetworkManager does not conflict with ifupdown since NM gracefully stops caring for interfaces defined by Debian's old ifupdown mechanism).


    https://github.com/openmediava…73#issuecomment-486080342


    To avoid such issues it would be great if users could be educated that we're living already in 2019 and not 1999 any more, that DNS exists for a few decades and there really is no need to 'assign static IP addresses' in this century at home. DHCP and dynamic DNS updates do the job just fine, in the meantime even Windows (10) can cope with ZeroConf and as such accessing a RockPro64 simply works by accessing either rockpro64 or rockpro64.local.


    @vecnar you could try to delete /etc/network/interfaces.d/eth0 and then use omv-firstaid. It looks like this on your install (please see how I access my RockPro64 -- by name and not by number since I'm a human being and don't need to remember silly IP addresses):

    • Offizieller Beitrag

    there really is no need to 'assign static IP addresses' in this century at home

    Unless you are port forwarding from your router to that system...

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Unless you are port forwarding from your router to that system...

    Not even then since why would any DHCP server assign a new address to a server machine that is always on by default? It becomes a problem if the DHCP address range is rather small compared to DHCP leases that were handed out and the OMV server will be stopped from time to time. Only then there's a chance that the DHCP server will assign a new address. Or the DHCP is server is really crappy and ignores the client's requested last IP address as part of a DHCPREQUEST (never seen this the last decade).

    • Offizieller Beitrag

    No, there also exist the @ayufan images that are promoted on the Pine64 website for Pine64, Rock64 and RockPro64.

    This is an exception (the ayufan image for the RockPro64) I was unaware of. I stand corrected.

    • Offizieller Beitrag

    Not even then since why would any DHCP server assign a new address to a server machine that is always on by default? It becomes a problem if the DHCP address range is rather small compared to DHCP leases that were handed out and the OMV server will be stopped from time to time. Only then there's a chance that the DHCP server will assign a new address. Or the DHCP is server is really crappy and ignores the client's requested last IP address as part of a DHCPREQUEST (never seen this the last decade).

    Why does it have to be always on? I've also seen plenty of home routers lose their lease table when they lose power. If you had mentioned static dhcp, that would be ok but relying on dhcp never changing the address is just being lazy.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • I've also seen plenty of home routers lose their lease table when they lose power.

    Fair point. Most probably situation here in Germany (majority of home users using something called Fritzbox which are 'routers that do not suck') doesn't apply to the rest of the world. Anyway: this 'assign static IP address' is the root cause of a lot of troubles and usually not necessary so it would be really great if users wouldn't be taught to set a static IP address in OMV and use IP addresses to access services. DNS works also in local networks. Since decades.

    • Offizieller Beitrag

    DNS works also in local networks. Since decades.

    This is not universally true. While DNS can work in local networks, the local router must support it. Not all routers do. On the other hand, static IP addressing does work universally.


    Even when using a router capable of local DNS:
    I'm in a situation right now where the gateway router/DHCP server is on the other side of a WiFi link, with a repeater in the middle. When the link is down, with static addressing, we can still access the server for documents reference and watch shows. The LAN still works, with or without the connection.


    This is just one real world instance where static IP addressing is required to support LAN operations. There are, without doubt, many more.

  • The following fixed it for me. This was an issue with openmediavault on the latest odroidxu4 image as well.
    It appears the auto in front of the devicename was causing all sorts of issues. It also increased my boot time a lot probably due to errors.
    I was running into this issue whether dhcp was on or not. I was trying to set a custom DNS for my omv.


    The gui and omv first aid will generate good interface configuration files now with this band aid.


    Edit:
    /usr/share/openmediavault/mkconf/interfaces.d/20ethernet


    Remove the line:
    -v "concat('auto ',devicename)" -n \

  • @vecnar you could try to delete /etc/network/interfaces.d/eth0 and then use omv-firstaid. It looks like this on your install (please see how I access my RockPro64 -- by name and not by number since I'm a human being and don't need to remember silly IP addresses):

    Apologies to everyone for not getting back on Friday, i am not sure why i am not getting notifications by email if someone replies to the thread (found setting in account settings>notifications) and i forgot to add calendar reminder.


    I tried deleting interface in webui, and deleting all from /etc/network/interface.d/ by executing "rm -r /etc/network/interfaces.d/*" and rebooting, it didn't work. I still had eth0 in /etc/network/interface.d/ directory after reboot.
    But after a few restarts and power offs as i was messing with sata card, now i am able to set ip address in webui. So not sure why it wasn't working before.
    I am not able to run omv-firstaid command as per my first post.
    Omv still gets ip address from dhcp server, so it can be accessed using both ip addresses and they both point to same mac address but name resolution resolves to static ip address configured, which is good.


    I am leaning towards static ip addresses, just past habit and for different reasons. The biggest one is power outage, router/firewall may take longer to boot than computer devices and static ip address gives you guarantee to connect to device especially if you are connecting from somewhere else and you need port forwarding. I am not sure if linux dhcp client tries to resend dhcp request every x minutes but from past experience when i needed to connected to device as soon as possible after power outage static ip always worked.


    I do not have problems with boot time but i tried removing it to see if it sets only 1 ip address but it is not, it sets secondary to ip address received from dhcp server.

  • I tried deleting interface in webui, and deleting all from /etc/network/interface.d/ by executing "rm -r /etc/network/interfaces.d/*" and rebooting, it didn't work. I still had eth0 in /etc/network/interface.d/ directory after reboot.

    Well, then you did not follow the advice to delete /etc/network/interfaces.d/eth0 as suggested. If the file is still there it has not been deleted. And now you have conflicting settings and things might not work as expected again...


    And of course 'static IP adresses' work if the administrator of the network took care of correct settings everywhere. But obviously the average OMV user is not a network administrator and issues like yours clearly demonstrate the problems in trying to set static IP addresses.


    If it's not about port forwarding but 'link-local' accesses all of the potential problems have been solved for a long time. There exists the 169.254.0.0/16 network range for link-local addresses and there exist mechanisms for service propagation and discovery. Fortunately even Microsoft after one decade of ignorance now supports all of this in Windows 10 so for such scenarios not even a DHCP server would be needed since all the devices happily choose an IP address on their own and announce the services they provide.

  • This was an issue with openmediavault on the latest odroidxu4 image as well

    As already explained in this thread the OMV images for most ARM boards are based on Armbian which relies on NetworkManager for the basic networking stuff. If you want to set a 'custom DNS' there you would better have called nmtui (which adjusts NetworkManager behavior). Your problems started when using the OMV UI (and then the interface handled by Debian's ifupdown mechanism) and the idea to 'fix' stuff by editing OMV's code is a bit weird since next OMV update might revert your changes.

  • Well, then you did not follow the advice to delete /etc/network/interfaces.d/eth0 as suggested. If the file is still there it has not been deleted. And now you have conflicting settings and things might not work as expected again...

    I did not have access to monitor/TV with HDMI input at that time so I tried to do things from a few lines of script.
    I was disconnected right away from SSH session when I executed below command
    rm -r /etc/network/interfaces.d/* so i assumed it was removed and just added reboot command.
    Could it be that I was not able to execute omv-firstaid option one and this was the reason why it was not fixed after deleting eth0?
    The above is just to list what I tried and not to contradict anyone's comments. It is working for me now, thank you for your help

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!