[Touch-packages] [Bug 1779721] Re: systemd-networkd does not configure DHCPv4
In both cases, no network, no static IP address, .. however, restarting systemd-networkd instantly brings the configuration up, and communication on the desired IP address starts. If anyone face laptop problem gets help from this http://lenovotechsupport.com -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1779721 Title: systemd-networkd does not configure DHCPv4 Status in netplan.io package in Ubuntu: Invalid Status in systemd package in Ubuntu: Confirmed Bug description: I have an up-to-date Ubuntu 18.04 (bionic) server installation (with systemd 237-3ubuntu10) which has following netplan configuration: ``` root@ubuntu:~# cat /etc/netplan/01-netcfg.yaml # This file describes the network interfaces available on your system # For more information, see netplan(5). network: version: 2 renderer: networkd ethernets: all: match: {} dhcp4: yes root@ubuntu:~# cat /run/systemd/network/10-netplan-all.network [Match] [Network] DHCP=ipv4 [DHCP] UseMTU=true RouteMetric=100 ``` Despite having DHCPv4 configured, no IPv4 address is configured on the ethernet device: ``` root@ubuntu:~# ip a show ens6 2: ens6: mtu 64000 qdisc fq_codel state UP group default qlen 1000 link/ether 02:01:71:8f:cc:72 brd ff:ff:ff:ff:ff:ff inet6 fe80::1:71ff:fe8f:cc72/64 scope link valid_lft forever preferred_lft forever ``` The kernel dmesg has no related messages and the journal log also looks normal: ``` root@ubuntu:~# journalctl -u systemd-networkd Jul 02 16:36:51 ubuntu systemd[1]: Starting Network Service... Jul 02 16:36:51 ubuntu systemd-networkd[1790]: ens6: Gained IPv6LL Jul 02 16:36:51 ubuntu systemd-networkd[1790]: Enumeration completed Jul 02 16:36:51 ubuntu systemd[1]: Started Network Service. Jul 02 16:36:51 ubuntu systemd-networkd[1790]: lo: Link is not managed by us Jul 02 16:36:51 ubuntu systemd-networkd[1790]: lo: Configured ``` Calling dhclient sets up the device correctly: ``` root@ubuntu:~# dhclient ens6 root@ubuntu:~# cat /var/lib/dhcp/dhclient.leases lease { interface "ens6"; fixed-address 87.106.172.36; option subnet-mask 255.255.255.255; option dhcp-lease-time 600; option routers 87.106.172.1; option dhcp-message-type 5; option domain-name-servers 46.16.74.70,46.16.72.37; option dhcp-server-identifier 87.106.172.1; option interface-mtu 64000; option host-name "ubuntu-18_04-fkb-2018-07-02"; renew 1 2018/07/02 16:46:51; rebind 1 2018/07/02 16:51:31; expire 1 2018/07/02 16:52:46; } root@ubuntu:~# ip a show ens6 2: ens6: mtu 64000 qdisc fq_codel state UP group default qlen 1000 link/ether 02:01:71:8f:cc:72 brd ff:ff:ff:ff:ff:ff inet 87.106.172.36/32 brd 87.106.172.36 scope global ens6 valid_lft forever preferred_lft forever inet6 fe80::1:71ff:fe8f:cc72/64 scope link valid_lft forever preferred_lft forever ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1779721/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1623383] Re: Some restarts fail due to missing base devices
The system LPAR this was seen first was an upgrade from Xenial but since then has been freshly installed with Yakkety. The same behaviour is seen on a zVM guest running Yakkety. If anyone face printer issue click here http://canonprintersupport247.com -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1623383 Title: Some restarts fail due to missing base devices Status in systemd package in Ubuntu: Confirmed Bug description: Arch: s390x Release: Yakkety / 16.10 This happens on some (but not all) system starts with Yakkety. In Xenial (which is using the same 4.4 kernel version the Yakkety systems were using when the problem was first observed) this did not happen. The system (LPAR) this was seen first was an upgrade from Xenial but since then has been freshly installed with Yakkety. The same behaviour is seen on a zVM guest running Yakkety. The attached syslog shows a failed boot, followed by one that did work. Note the "Found device .*(sclp|encc00).*" messages in the good boot. Those are missing in the bad attempt and as a result networking and console fail to be usable. Also note, those boots were 4.8 kernels but we saw this with 4.4 kernels, too. This might be a systemd problem / race, I just filed it into udev for now as that better matches the not finding basic devices symptom. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1623383/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1721223] Re: Networkd fail to set ip address between leases if ip address changes on UbuntuCore
you can Add a device, and assign two IPv4 addresses. First one, with a short lease time. Second one, with a different ip and a longer lease time. If anyone face printer issue click here http://HPsupport365.com ** Attachment added: "printer.png" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1721223/+attachment/5223123/+files/printer.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1721223 Title: Networkd fail to set ip address between leases if ip address changes on UbuntuCore Status in Snappy: Fix Committed Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Released Status in systemd source package in Zesty: Won't Fix Status in systemd source package in Artful: Fix Released Bug description: [Impact] * networkd fails to renew a lease, specifically it fails to change IPv4 address via DHCP renew/rebind. * networkd relies on a kernel feature to promote secondary IPv4 address to primary, upon primary address lease expiry. * this sysctl tunable was not enabled by default in systemd. [Test Case] Add a device, and assign two IPv4 addresses. First one, with a short lease time. Second one, with a different ip and a longer lease time. Second one should be treated as secondary ip address, and upon expiry of the first one, should be promoted and become primary ip address. The below scripted instructions simulate this: sudo ip link add name testleases type dummy sudo ip address add 192.0.2.10/27 dev testleases \ valid_lft 5 preferred_lft 5 sudo ip address add 192.0.2.11/27 dev testleases \ valid_lft 11 preferred_lft 11 ip address list dev testleases | \ grep -q 'inet 192.0.2.10/27 scope global dynamic testleases' \ && echo ok || echo not ok ip address list dev testleases | \ grep -q 'inet 192.0.2.11/27 scope global secondary dynamic testleases' \ && echo ok || echo not ok sleep 6 ip address list dev testleases | \ grep -q 'inet 192.0.2.11/27 scope global dynamic testleases' \ && echo ok || echo not ok sudo ip link del dev testleases [Regression Potential] * This changes the default kernel behaviour, previously upon expiry of the primary address, secondary addresses were removed as well. Which is imho silly. * comparing networkd renewal with isc-dhcp renewal the semantics are quite different. Upon acquiring new ip address, isc-dhcp would instantly flush existing ip address, and add a new one. Networkd add the new address as secondary, and waits for old one to expire first before promoting / switching to using the new ip address. IMHO kernel should have an API to promote secondary ip address to a primary one. * This update also applies other safe-looking options, which are currently also already applied via sysctls shipped in other packages # Source route verification net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1 # Do not accept source routing net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.all.accept_source_route = 0 # Enable hard and soft link protection fs.protected_hardlinks = 1 fs.protected_symlinks = 1 * This update also applies the following upstream/bufferbloat.net recommended setting # Fair Queue CoDel packet scheduler to fight bufferbloat net.core.default_qdisc = fq_codel * [~racb] There are complex network setups out there, such as HA with corosync/pacemaker, OpenStack Neutron, and that kind of thing. If this fix were SRU'd, will all of these things in the wild cope with this sysctl change? [Other Info] * Original bug report Hi there, we found a replicable issue that involves the Ubuntu Core networking and causes complete loss of connectivity. We run a custom board with ubuntu core: the architecure is amrhf. We replicated this issue with an official Ubuntu Core image on a Raspberry Pi: other platform was been tested. It shows that it is a snap core problem which interests networkd: we use the default network stack based on networkd + netplan. Below steps to replicate the issue. 1)Setup a dhcp server for lease of about some minutes (i.e 10 minutes). 2)Boot the board and wait for get an ip from dhcp server 3)Before the lease expires, set a reservation for a different ip address Depending on lease duration before the lease expires( for 10 minute we have 2 minutes before ), networkd configure the new address in addition to the previous one. When the lease expire both ip address ( the prevoius and the new one ) disappear from the interested network interface. Depending on lease duration before the second lease expires ( for 10 minure we have 2 minutes before ) networkd configure only the new ip address on the network interface and the ping toward an outside host work properly. During