Will the newer Debian releases that have ‘systemd on board’ (i.e. Jessie-or-newer) run as the Omnia (LXC) container (using the ‘out of the box’ Omnia OS / software)?
Well, it does indeed work. However, I’m having troubles with the default LXC configuration: the network works in a very strange way:
root@LXC_NAME:~# ifup eth0
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/36:e4:92:4b:42:c3
Sending on LPF/eth0/36:e4:92:4b:42:c3
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
5 bad udp checksums in 5 packets
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
On the host, I see the following in the logs:
2016-10-06T18:51:53+02:00 info dnsmasq-dhcp[1777]: DHCPDISCOVER(br-lan) 36:e4:92:4b:42:c3
2016-10-06T18:51:53+02:00 info dnsmasq-dhcp[1777]: DHCPOFFER(br-lan) 192.168.1.205 36:e4:92:4b:42:c3
2016-10-06T18:51:54+02:00 info dnsmasq-dhcp[1777]: DHCPDISCOVER(br-lan) 36:e4:92:4b:42:c3
2016-10-06T18:51:54+02:00 info dnsmasq-dhcp[1777]: DHCPOFFER(br-lan) 192.168.1.205 36:e4:92:4b:42:c3
2016-10-06T18:52:01+02:00 info dnsmasq-dhcp[1777]: DHCPDISCOVER(br-lan) 36:e4:92:4b:42:c3
2016-10-06T18:52:01+02:00 info dnsmasq-dhcp[1777]: DHCPOFFER(br-lan) 192.168.1.205 36:e4:92:4b:42:c3
2016-10-06T18:52:18+02:00 info dnsmasq-dhcp[1777]: DHCPDISCOVER(br-lan) 36:e4:92:4b:42:c3
2016-10-06T18:52:18+02:00 info dnsmasq-dhcp[1777]: DHCPOFFER(br-lan) 192.168.1.205 36:e4:92:4b:42:c3
2016-10-06T18:52:40+02:00 info dnsmasq-dhcp[1777]: DHCPDISCOVER(br-lan) 36:e4:92:4b:42:c3
2016-10-06T18:52:40+02:00 info dnsmasq-dhcp[1777]: DHCPOFFER(br-lan) 192.168.1.205 36:e4:92:4b:42:c3
…
This all seem pretty complex… or at least not “out of the box”.
Should I ‘take a week of of work’ to get it all up and running? You guys got me scared!
This will be a critical device in my network topology - I cant afford it to be down due to me tweaking too much (not that this is your problem I know; but hopefully someone is able to take me by the hand once I get to it; checking e-mail box first thing of the day - everyday).
Well, there is no ethtool as part of default image, but it can be installed via opkg update && opkg install ethtool from TurrisOS repositories. So far I was using just openSUSE in container which is not affected, but tried Debian and seems that calling ethtool -K veth* tx off made even dhclient in Debian get ip address. It should be probably possible to automate this workaround, will try. btw. When booted Debian container it got IPv6 without any issue via RA or whatever.
Couldn’t you just through that in the rc.local? Like Miska said.
I mean the LXC is still the OS, so i expect that it also should have some sort of start-on-boot function. Off course till it is fixed, till then when it is automated, then you should have no worries anymore.
Hello,
another solution could to remove isc-dhcp-client package and install dhcpcd5 package instead. Debian scripts will use it automatically. If cz.nic can do it in prepared image, we can get better “out of the box” experience.
This is working for me, thanks @janskyj
(U need “apt-get download dhcpcd5” on your turris terminal screen, then move downloaded *.deb package to your lxc container root folder, then log in lxc container and run apt-get remove isc-dhcp-client -y && dpkg -i dhcpcd5.deb in folder where you put deb file and reboot and it should work instantly. )
Just a small message to extend my hand to you guys @miska@andrewsh@janskyj and @technik007_cz (and possibly others that helped in the discussion but were not listed by me)! You lot saved me - and my friends (yes I pulled in 2 other guys to the Omnia-world) - so much time!!
Happy to inform you that I have multiple Debian (and Ubuntu) containers running by doing:
But the rest (references to the Debian bug and proposed workaround) really helped us understanding the issue!
I do have another issue when running Debian (no issue with Ubuntu) inside an LXC container on the Omnia:
I can: lxc-attach -n <containername>andlxc-console -n <countainername> -t 0 (note the tty 0 reference) but not on any of the other TTYs… I simply get no login and my commands are echoed to the screen…
In my quest for answers I stumbled upon the following: https://github.com/lxc/lxc/issues/520 which seems close but isn’t quite it… But that is where my Google-fu left me, unfortunately.
Anyone able to reproduce it / direct me to a solution and/or should I simply accept it (I can SSH in and/or use lxc-attach for now? There is no immediate issue… just me not understanding / finding it annoying there there seems to be a bug in the Debian template that the Omnia is referring to).
I mean… I read that too, but ignored it (until you suggested it), as it is located in:
Incompatibility with systemd / Scenarios / Reconfiguring updated VMs
I mean… I installed Jessie directly from the template offered by the Omnia (or is this in fact an upgraded Wheezy?)… How could I have known? I must be missing a link… would you be so kind to help me learn by explaining your thought-path there?
I had a similar issue. But I did not get any login prompt using lxc-console so figured something was up with getty. Then my searches suggested there were issues with (older versions of) systemd in LXC containers, so I ended up trying the suggestions in the Debian wiki.
I know; but hopefully someone is able to take me by the hand once I get to it; checking e-mail box first thing of the day - everyday).
