Mostly because it looked like this thread had died with the issue magically solving itself without a clear path to follow to fix. So rather than hijacking this thread with my issue, I thought I'd respond to this one to see if the OP would come back with an update, whilst at the same time post a new thread as - re-reading the issue here mine is slightly different. The OP says their system crashes, whereas mine does not crash, the network dies. Two different issues, hence, this seems to warrant a new thread.
Beiträge von prupert
-
-
So, the reason I am thinking it is the HC2 is since replugging the cable fixes the connection, this implies somethings killed the connection and replugging it resets that - though yeah, could also be the cable so I shall try an alternative cable.
Here is the syslog when the connection dies:
Code
Alles anzeigenJun 26 20:30:01 omv CRON[21877]: (root) CMD (/usr/sbin/omv-mkrrdgraph >/dev/null 2>&1) Jun 26 20:35:01 omv CRON[22042]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Jun 26 20:36:13 omv avahi-daemon[914]: Withdrawing address record for 192.168.1.22 on enx001e06328264. Jun 26 20:36:13 omv avahi-daemon[914]: Leaving mDNS multicast group on interface enx001e06328264.IPv4 with address 192.168.1.22. Jun 26 20:36:13 omv avahi-daemon[914]: Interface enx001e06328264.IPv4 no longer relevant for mDNS. Jun 26 20:36:15 omv ntpd[1497]: Deleting interface #11 enx001e06328264, 192.168.1.22#123, interface stats: received=117, sent=119, dropped=0, active_time=59759 secs Jun 26 20:36:15 omv ntpd[1497]: 88.150.240.202 local addr 192.168.1.22 -> <null> Jun 26 20:36:42 omv monit[1495]: Cannot translate '127.0.0.1' to IP address -- Address family for hostname not supported Jun 26 20:36:42 omv monit[1495]: 'nginx' failed protocol test [HTTP] at [127.0.0.1]:80 [TCP/IP] -- Cannot resolve [127.0.0.1]:80 Jun 26 20:37:12 omv monit[1495]: Cannot translate '127.0.0.1' to IP address -- Address family for hostname not supported Jun 26 20:37:12 omv monit[1495]: 'nginx' failed protocol test [HTTP] at [127.0.0.1]:80 [TCP/IP] -- Cannot resolve [127.0.0.1]:80 Jun 26 20:37:12 omv monit[1495]: 'nginx' trying to restart Jun 26 20:37:12 omv monit[1495]: 'nginx' stop: '/bin/systemctl stop nginx' Jun 26 20:37:13 omv systemd[1]: Stopping A high performance web server and a reverse proxy server... Jun 26 20:37:13 omv systemd[1]: Stopped A high performance web server and a reverse proxy server. Jun 26 20:37:13 omv monit[1495]: 'nginx' start: '/bin/systemctl start nginx' Jun 26 20:37:13 omv systemd[1]: Starting A high performance web server and a reverse proxy server... Jun 26 20:37:13 omv systemd[1]: Started A high performance web server and a reverse proxy server. Jun 26 20:37:43 omv monit[1495]: Cannot translate '127.0.0.1' to IP address -- Address family for hostname not supported Jun 26 20:37:43 omv monit[1495]: 'nginx' failed protocol test [HTTP] at [127.0.0.1]:80 [TCP/IP] -- Cannot resolve [127.0.0.1]:80 Jun 26 20:37:43 omv monit[1495]: 'nginx' trying to restart Jun 26 20:37:43 omv monit[1495]: 'nginx' stop: '/bin/systemctl stop nginx'For whatever reason the interface gets removed, which then causes nginx to go nuts as it can't host the OMV pages and then the rest of the log is full with nginx trying to recover. As you can see though, there is nothing unusual prior to avahi-daemon removing the address record (line 5) which is odd. Are there any other logs to look at other than syslog that might shed some light on this?
I've got a USB-UART bridge so can putty in that way and can see the system is still up, so its network specific this issue.
Ifconfig -a when the network appears broken gives:
Code
Alles anzeigenenx001e06328264: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::18f2:23a8:13f4:7e0 prefixlen 64 scopeid 0x20<link> ether 00:1e:06:32:82:64 txqueuelen 1000 (Ethernet) RX packets 1898701 bytes 1512931116 (1.4 GiB) RX errors 0 dropped 162 overruns 0 frame 0 TX packets 1238354 bytes 2613134175 (2.4 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Local Loopback) RX packets 73373 bytes 8291469 (7.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 73373 bytes 8291469 (7.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Its then possible to fix the network connection (via UART) by bringing the interface down and then up. So, by running these two commands:
ip link set dev enx001e06328264 down
ip link set dev enx001e06328264 upThe log now shows:
Code
Alles anzeigenJun 26 23:28:17 omv NetworkManager[884]: <info> [1530052097.5260] device (enx001e06328264): state change: activated -> unavailable (reason 'carrier-changed') [100 20 40] Jun 26 23:28:17 omv NetworkManager[884]: <info> [1530052097.5377] manager: NetworkManager state is now CONNECTED_LOCAL Jun 26 23:28:17 omv NetworkManager[884]: <info> [1530052097.5432] manager: NetworkManager state is now DISCONNECTED Jun 26 23:28:18 omv kernel: [304764.028268] IPv6: ADDRCONF(NETDEV_UP): enx001e06328264: link is not ready Jun 26 23:28:18 omv kernel: [304764.043939] r8152 6-1:1.0 enx001e06328264: carrier on Jun 26 23:28:18 omv kernel: [304764.044056] IPv6: ADDRCONF(NETDEV_CHANGE): enx001e06328264: link becomes ready Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.0669] device (enx001e06328264): link connected Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.0687] device (enx001e06328264): state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40] Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.0709] policy: auto-activating connection 'Wired connection 1' Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.0750] device (enx001e06328264): Activation: starting connection 'Wired connection 1' (72b9f1d5-9d26-3ce6-98fa-3ca764ea4bc9) Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.0759] device (enx001e06328264): state change: disconnected -> prepare (reason 'none') [30 40 0] Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.0765] manager: NetworkManager state is now CONNECTING Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.0783] device (enx001e06328264): state change: prepare -> config (reason 'none') [40 50 0] Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.0796] device (enx001e06328264): state change: config -> ip-config (reason 'none') [50 70 0] Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.0965] dhcp4 (enx001e06328264): dhclient started with pid 30262 Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1615] dhcp4 (enx001e06328264): address 192.168.1.22 Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1615] dhcp4 (enx001e06328264): plen 24 (255.255.255.0) Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1616] dhcp4 (enx001e06328264): gateway 192.168.1.1 Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1616] dhcp4 (enx001e06328264): server identifier 192.168.1.1 Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1616] dhcp4 (enx001e06328264): lease time 86400 Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1617] dhcp4 (enx001e06328264): hostname 'omv' Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1618] dhcp4 (enx001e06328264): nameserver '192.168.1.1' Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1618] dhcp4 (enx001e06328264): state changed unknown -> bound Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1664] device (enx001e06328264): state change: ip-config -> ip-check (reason 'none') [70 80 0] Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1697] device (enx001e06328264): state change: ip-check -> secondaries (reason 'none') [80 90 0] Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1712] device (enx001e06328264): state change: secondaries -> activated (reason 'none') [90 100 0] Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1719] manager: NetworkManager state is now CONNECTED_LOCAL Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1756] manager: NetworkManager state is now CONNECTED_GLOBAL Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1761] policy: set 'Wired connection 1' (enx001e06328264) as default for IPv4 routing and DNS Jun 26 23:28:18 omv NetworkManager[884]: <info> [1530052098.1770] device (enx001e06328264): Activation: successful, device activated.Ifconfig -a now shows an IP address:
Code
Alles anzeigenenx001e06328264: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.22 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::18f2:23a8:13f4:7e0 prefixlen 64 scopeid 0x20<link> ether 00:1e:06:32:82:64 txqueuelen 1000 (Ethernet) RX packets 1899654 bytes 1513058146 (1.4 GiB) RX errors 0 dropped 162 overruns 0 frame 0 TX packets 1238450 bytes 2613150616 (2.4 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Local Loopback) RX packets 73446 bytes 8299726 (7.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 73446 bytes 8299726 (7.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0To be clear, I didn't disconnect the cable to fix this, I simply puttyed in via USB UART and brought the connection down and then up. By doing this, the OMV webpage comes back on line and the shared folders on the windows network reappears.
So, in my mind, something is causing the interface to fall over, but I've no idea what....
-
I recently got an odroid-HC2 and installed OMV on it on a new Samsung SD card. I am using the power supply it came with from odroid.co.uk.
The system runs fine for 3ish days then it looses network connection. This can easily be fixed by removing and replacing the Ethernet cable but this is obviously not useful for a NAS device.
Other errors I have read on this forum related to similar devices seem to be power supply or sd card based but relate to the whole system crashing. My issue seems specific to the network itself.
The OMV logs give no indication of errors though one line seems to relate to a post I found via google about an issue with the USB driver.
Anyone aware of a similar issue and what the fix might be or should I return the odroid?
-
Did you work out how you fixed this? I got the same error on an odroid-HC2.
-
I had exactly the same issue this evening. Downloaded 1.0.20 (seemingly most recent version from the omv site), wrote the iso to a USB drive using unetbootin, installed omv on a SSD and then could only boot with the USB attached. pw2002au's solution fixed it, but it would throw a new user i guess.
Probably down to a particular BIOS, USB drive, HD drive combination, but still. It's a bummer.
sudo dpkg-reconfigure grub-pcenter through the default values until you get to the listed devices and select the actual drive you want for grub to be booted from and select that. You can then boot without the thumb stick.
-
Hi
I have multiple NICs in my OMV box (5 in total, one built in Gigabit NIC and four Gigabit NICs from a PCI-E card).
When more than one NIC is connected to my network, I notice that the NFS server seems to get confused, videos I watch via an NFS share hosted on OMV stutter constantly. With only one NIC connected, this isn't an issue and the videos play fine.
How should multiple NICs be configured and used in OMV?