[Group.of.nepali.translators] [Bug 1162475] Re: [hostnamed] Changing hostname doesn't update /etc/hosts
** Changed in: systemd (Ubuntu) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1162475 Title: [hostnamed] Changing hostname doesn't update /etc/hosts Status in gnome-control-center package in Ubuntu: Invalid Status in systemd package in Ubuntu: Won't Fix Status in unity-control-center package in Ubuntu: Won't Fix Status in gnome-control-center source package in Xenial: Confirmed Status in systemd source package in Xenial: Triaged Status in unity-control-center source package in Xenial: Confirmed Status in gnome-control-center package in Debian: Fix Released Bug description: GUI --- 1a. Run sudo gnome-control-center, or... 1b. Save the gnome-control-center.pkla from https://bazaar.launchpad.net/~ubuntu-desktop/gnome-control-center/ubuntu/revision/556 to /var/lib/polkit-1/localauthority/10-vendor.d/ and then run gnome-control-center as an admin user 2. Enter the Details panel 3. The "Device name" (hostname) text field should be editable; change the text to something else. 4. The hostname is updated instantly which can be verified by looking in /etc/hostname. However /etc/hosts/ is not updated. Command line hostnamectl set-hostname The hostnamed documentation at http://www.freedesktop.org/wiki/Software/systemd/hostnamed says "To properly handle name lookups with changing local hostnames without having to edit /etc/hosts for them we recommend using hostnamed in combination with nss-myhostname: http://0pointer.de/lennart/projects/nss-myhostname/ " Without /etc/hosts being handled correctly, the hostnamed integration is only half-working. ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: gnome-control-center 1:3.6.3-0ubuntu18 ProcVersionSignature: Ubuntu 3.8.0-15.25-generic 3.8.4 Uname: Linux 3.8.0-15-generic x86_64 ApportVersion: 2.9.2-0ubuntu5 Architecture: amd64 Date: Sun Mar 31 08:52:57 2013 MarkForUpload: True SourcePackage: gnome-control-center UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_gnome-control-center: activity-log-manager-control-center 0.9.4-0ubuntu6.1 deja-dup26.0-0ubuntu1 gnome-control-center-signon 0.1.5-0ubuntu1 gnome-control-center-unity 1.2daily13.02.15-0ubuntu1 indicator-datetime 12.10.3daily13.03.26-0ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1162475/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1830479] Re: testcases expect first kernel log line, but not always in logs
** Changed in: systemd (Ubuntu Cosmic) Status: New => Won't Fix ** Changed in: systemd (Ubuntu Bionic) Status: New => Won't Fix ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1830479 Title: testcases expect first kernel log line, but not always in logs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Won't Fix Status in systemd source package in Bionic: Won't Fix Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Won't Fix Status in systemd source package in Eoan: Won't Fix Status in systemd package in Debian: Fix Released Bug description: [impact] boot-and-services and cmdline-upstart-boot expect the first(ish) kernel log line to be in the system logs, but that is not guaranteed to be in the logs. [test case] run autopkgtest on arm64 with the current kernel, whose kernel log size is too small for journald or rsyslogd to capture the first kernel log messages. [regression potential] low; testcase fix only. [other info] the specific cause of this currently is too-small kernel log buffer size on arm64, which is being fixed in bug 1824864, but increasing amounts of boot time logging may cause a failure again, or custom kernel configs with small log buffers. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830479/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1770082] Re: systemd-networkd not renaming devices on boot
** Changed in: systemd (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1770082 Title: systemd-networkd not renaming devices on boot Status in netplan: Fix Released Status in cloud-init package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Fix Released Status in nplan package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Invalid Status in nplan source package in Xenial: Fix Released Status in netplan.io source package in Bionic: Fix Released Status in netplan.io source package in Cosmic: Fix Released Bug description: [Impact] Systems relying on renaming network interfaces at boot and when 'netplan apply' is run. [Test case] - Write a new netplan YAML (adjusting for current system as necessary): network: version: 2 ethernets: ens3: dhcp4: true match: macaddress: 52:54:00:de:bd:f6 set-name: myif0 - Bring down interface : 'ip link set dev ens3 down' - Run 'netplan apply' - Verify that the device is correctly renamed to 'myif0'. - Reboot. - Make sure the device is correctly renamed to 'myif0'. [Regression potential] Changes in rename logic to add udev rules may otherwise impact applying different settings to the network interfaces. Changes in settings on network interfaces, missing parameters (especially on bonds, bridges) should be investigated as potential regressions. Other failures to apply network settings might also happen if there's a race between applying renames via the udev rules, and using the new names to apply configuration changes to the interfaces. === systemd issue === Renaming devices doesn't seem to work. If I disable all other network configuration and create /etc/systemd/network/10-network.link with: [Match] MACAddress=52:54:00:c1:c9:bb [Link] Name=myiface3 I expect this to cause the device with that MAC address to be renamed to myiface3. However, when I reboot, I instead see: $ ip l 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens3: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff The device is not renamed. This link file is pretty much identical to Example 2 in https://www.freedesktop.org/software/systemd/man/systemd.link.html. The renaming does work if I boot with net.ifnames=0, and oddly, it also works if I unbind the device and rebind it as netplan apply does. No setting of NamePolicy seems to help. === Original Bug == 'set-name:' doesn't change the name of a network interface on boot, it only works when you do netplan apply. Say I take this 50-cloud-init.yaml file: # This file is generated from information provided by # the datasource. Changes to it will not persist across an instance. # To disable cloud-init's network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # network: {config: disabled} network: version: 2 ethernets: ens3: dhcp4: true match: macaddress: 52:54:00:de:bd:f6 set-name: ens3 Say I change set-name to 'myiface3' and reboot. I expect that the device will be called myiface3 and brought up fine with dhcp. However, instead I see: $ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens3: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff The name has not been changed, and the device has not been brought up. If I run netplan apply however, I see the following: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: myiface3: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3 valid_lft 3575sec preferred_lft 3575sec inet6 fe80::5054:ff:fede:bdf6/64 scope link valid_lft forever preferred_lft forever So names are successfully changed with netplan apply. This seems to be some