[Touch-packages] [Bug 1800836] Re: systemd-networkd doesn't process IPv6 RA properly
This bug is still present on Ubuntu 18.04.5 LTS with systemd 237-3ubuntu10.50. Please reopen. -- 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/1800836 Title: systemd-networkd doesn't process IPv6 RA properly Status in systemd package in Ubuntu: Invalid Bug description: The gateways/firewalls in our DC are highly available and when there is a failover their IPv6 VIP (fe80::1) moves from the master to the backup one. We found that only our Bionic VMs behind those gateways had issues after a failover. Those Bionic VMs were all running systemd-networkd (from netplan) and before the failover they had: $ ip -6 route ... default via fe80::1 dev eth0 proto ra metric 1024 pref medium But after a failover: $ ip -6 route ... default proto ra metric 1024 nexthop via fe80::1 dev eth0 weight 1 nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1 And after another failover: $ ip -6 route ... default proto ra metric 1024 nexthop via fe80::1 dev eth0 weight 1 nexthop via fe80::210:18ff:febe:6750 dev eth0 weight 1 nexthop via fe80::210:18ff:fe77:b558 dev eth0 weight 1 This is problematic as those then use fe80::210:18ff:fe77:b558%$IFACE as their default gateway even when this gateway is unavailable: $ ip -6 route get :: :: from :: via fe80::210:18ff:fe77:b558 dev eth0 proto ra src fe80::a800:ff:fe51:8c37 metric 1024 pref medium We concluded it was a systemd-networkd bug after checking that the following combinations were NOT affected: 1) Xenial+4.4 kernel 2) Xenial+4.15 kernel 3) Bionic+ifupdown Additional information: $ apt-cache policy systemd systemd: Installed: 237-3ubuntu10.3 Candidate: 237-3ubuntu10.3 Version table: *** 237-3ubuntu10.3 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages $ lsb_release -rd Description: Ubuntu 18.04.1 LTS Release: 18.04 ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.3 ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18 Uname: Linux 4.15.0-38-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.4 Architecture: amd64 Date: Wed Oct 31 08:47:28 2018 Lspci: Error: [Errno 2] No such file or directory: 'lspci': 'lspci' Lsusb: Error: [Errno 2] No such file or directory: 'lsusb': 'lsusb' MachineType: QEMU Standard PC (i440FX + PIIX, 1996) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic root=UUID=43b7ee2e-2ab1-4505-8e0b-d9fe0563a034 ro console=ttyS0 net.ifnames=0 vsyscall=none kaslr nmi_watchdog=0 possible_cpus=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: Ubuntu-1.8.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-xenial dmi.modalias: dmi:bvnSeaBIOS:bvrUbuntu-1.8.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-xenial:cvnQEMU:ct1:cvrpc-i440fx-xenial: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-xenial dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1800836/+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 1906986] Re: defective ir-keytable udev rule → custom keytable does not get loaded
Probably. My (fully updated) 20.04.1 LTS box is still at version
1.18.0-2build1, though.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to v4l-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1906986
Title:
defective ir-keytable udev rule → custom keytable does not get loaded
Status in v4l-utils package in Ubuntu:
Incomplete
Bug description:
ir-keytable v1.18.0-2build1 ships /lib/udev/rules.d/60-ir-
keytable.rules containing the following rule:
ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a
/etc/rc_maps.cfg -s $name"
After upgrading to Focal, this does not get triggered at boot, nor if
I (re)insert my receiver when the system is running. Therefore, the
custom keytable does not get loaded.
This is the udev events that occur when I insert the receiver:
$ sudo udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[1195.829011] add /devices/pci:00/:00:14.0/usb1/1-3 (usb)
KERNEL[1195.834989] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0 (usb)
KERNEL[1195.874055] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/lirc0 (lirc)
KERNEL[1195.875019] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11 (input)
KERNEL[1195.875183] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11/event3 (input)
KERNEL[1196.134164] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/wakeup/wakeup21 (wakeup)
KERNEL[1196.134448] bind
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0 (usb)
KERNEL[1196.134704] bind /devices/pci:00/:00:14.0/usb1/1-3 (usb)
UDEV [1196.158923] add /devices/pci:00/:00:14.0/usb1/1-3 (usb)
UDEV [1196.174559] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0 (usb)
UDEV [1196.194750] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/lirc0 (lirc)
UDEV [1196.196268] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11 (input)
UDEV [1196.197180] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/wakeup/wakeup21 (wakeup)
UDEV [1196.224577] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11/event3 (input)
UDEV [1196.231346] bind
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0 (usb)
UDEV [1196.244978] bind /devices/pci:00/:00:14.0/usb1/1-3 (usb)
Note how there's no «(rc)» displayed on any of the lines, which means
that the «SUBSYSTEM=="rc"» condition from the udev rule filters all of
the above events.
I found a rule that works at https://www.mail-archive.com/linux-
me...@vger.kernel.org/msg117165.html:
ACTION=="add", SUBSYSTEM=="input", SUBSYSTEMS=="rc", KERNEL=="event*",
ENV{.rc_sysdev}="$id", RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg
-s $env{.rc_sysdev}"
Creating a custom /etc/udev/rules.d/60-ir-keytable.rules file
containing this rule solves the problem; now my custom keymap is
loaded at boot, as it did before (when I was running Bionic).
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: ir-keytable 1.18.0-2build1 [modified: usr/bin/ir-keytable]
ProcVersionSignature: Ubuntu 5.4.0-56.62-generic 5.4.73
Uname: Linux 5.4.0-56-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.13
Architecture: amd64
CasperMD5CheckResult: skip
Date: Sun Dec 6 18:05:06 2020
SourcePackage: v4l-utils
UpgradeStatus: Upgraded to focal on 2020-12-06 (0 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/v4l-utils/+bug/1906986/+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 1906986] [NEW] defective ir-keytable udev rule → custom keytable does not get loaded
Public bug reported:
ir-keytable v1.18.0-2build1 ships /lib/udev/rules.d/60-ir-keytable.rules
containing the following rule:
ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a
/etc/rc_maps.cfg -s $name"
After upgrading to Focal, this does not get triggered at boot, nor if I
(re)insert my receiver when the system is running. Therefore, the custom
keytable does not get loaded.
This is the udev events that occur when I insert the receiver:
$ sudo udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[1195.829011] add /devices/pci:00/:00:14.0/usb1/1-3 (usb)
KERNEL[1195.834989] add /devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0
(usb)
KERNEL[1195.874055] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/lirc0 (lirc)
KERNEL[1195.875019] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11 (input)
KERNEL[1195.875183] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11/event3 (input)
KERNEL[1196.134164] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/wakeup/wakeup21 (wakeup)
KERNEL[1196.134448] bind /devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0
(usb)
KERNEL[1196.134704] bind /devices/pci:00/:00:14.0/usb1/1-3 (usb)
UDEV [1196.158923] add /devices/pci:00/:00:14.0/usb1/1-3 (usb)
UDEV [1196.174559] add /devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0
(usb)
UDEV [1196.194750] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/lirc0 (lirc)
UDEV [1196.196268] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11 (input)
UDEV [1196.197180] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/wakeup/wakeup21 (wakeup)
UDEV [1196.224577] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11/event3 (input)
UDEV [1196.231346] bind /devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0
(usb)
UDEV [1196.244978] bind /devices/pci:00/:00:14.0/usb1/1-3 (usb)
Note how there's no «(rc)» displayed on any of the lines, which means
that the «SUBSYSTEM=="rc"» condition from the udev rule filters all of
the above events.
I found a rule that works at https://www.mail-archive.com/linux-
me...@vger.kernel.org/msg117165.html:
ACTION=="add", SUBSYSTEM=="input", SUBSYSTEMS=="rc", KERNEL=="event*",
ENV{.rc_sysdev}="$id", RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s
$env{.rc_sysdev}"
Creating a custom /etc/udev/rules.d/60-ir-keytable.rules file containing
this rule solves the problem; now my custom keymap is loaded at boot, as
it did before (when I was running Bionic).
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: ir-keytable 1.18.0-2build1 [modified: usr/bin/ir-keytable]
ProcVersionSignature: Ubuntu 5.4.0-56.62-generic 5.4.73
Uname: Linux 5.4.0-56-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.13
Architecture: amd64
CasperMD5CheckResult: skip
Date: Sun Dec 6 18:05:06 2020
SourcePackage: v4l-utils
UpgradeStatus: Upgraded to focal on 2020-12-06 (0 days ago)
** Affects: v4l-utils (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to v4l-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1906986
Title:
defective ir-keytable udev rule → custom keytable does not get loaded
Status in v4l-utils package in Ubuntu:
New
Bug description:
ir-keytable v1.18.0-2build1 ships /lib/udev/rules.d/60-ir-
keytable.rules containing the following rule:
ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a
/etc/rc_maps.cfg -s $name"
After upgrading to Focal, this does not get triggered at boot, nor if
I (re)insert my receiver when the system is running. Therefore, the
custom keytable does not get loaded.
This is the udev events that occur when I insert the receiver:
$ sudo udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[1195.829011] add /devices/pci:00/:00:14.0/usb1/1-3 (usb)
KERNEL[1195.834989] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0 (usb)
KERNEL[1195.874055] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/lirc0 (lirc)
KERNEL[1195.875019] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11 (input)
KERNEL[1195.875183] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11/event3 (input)
KERNEL[1196.134164] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/wakeup/wakeup21 (wakeup)
KERNEL[1196.134448] bind
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0 (usb)
KERNEL[1196.134704] bind /devices/pci:00/:00:14.0/usb1/1-3 (usb)
UDEV [1196.158923] add /devices/pci:00/:00:14
[Touch-packages] [Bug 1841364] Re: AppArmor breaks the default Unbound installation in a live session
I can confirm that the following commands fixes the problem so Ubound can start again: echo 'alias / -> /upper/,' >> /etc/apparmor.d/tunables/alias apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.unbound I noticed that when it starts, another AppArmor-related error message is logged: [ 257.707923] audit: type=1107 audit(1567174888.349:247): pid=976 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/systemd1" interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers" mask="send" name="org.freedesktop.systemd1" pid=6735 label="/usr/sbin/unbound" peer_pid=1 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?' However, it does not appear to cause any problems as far as I could tell. Tore -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1841364 Title: AppArmor breaks the default Unbound installation in a live session Status in apparmor package in Ubuntu: New Status in unbound package in Ubuntu: Triaged Bug description: Immediately after installing Unbound, it starts up normally. However, if you try to restart it afterwards (without changing anything), it fails with the following error message: Aug 25 10:41:26 ubuntu unbound[6650]: /etc/unbound/unbound.conf:10: error: cannot open include file '/etc/unbound/unbound.conf.d/*.conf': No such file or directory Aug 25 10:41:26 ubuntu unbound[6650]: read /etc/unbound/unbound.conf failed: 1 errors in configuration file Aug 25 10:41:26 ubuntu unbound[6650]: [1566729686] unbound[6650:0] fatal error: Could not read config file: /etc/unbound/unbound.conf. Maybe try unbound -dd, it stays on the commandline to see more errors, or unbound-checkconf There *are* files matching the above glob pattern, however: root@ubuntu:~# echo /etc/unbound/unbound.conf.d/*.conf /etc/unbound/unbound.conf.d/qname-minimisation.conf /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf unbound-checkconf, on the other hand, determines the configuration to be fine: root@ubuntu:~# unbound-checkconf unbound-checkconf: no errors in /etc/unbound/unbound.conf In the kernel log I can see that AppArmor is the probable culprit: Aug 25 10:41:26 ubuntu kernel: audit: type=1400 audit(1566729686.377:239): apparmor="DENIED" operation="open" profile="/usr/sbin/unbound" name="/upper/etc/unbound/unbound.conf.d/" pid=6650 comm="unbound" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Steps to reproduce: 1. Download ubuntu-19.04-desktop-amd64.iso from https://ubuntu.com/download/desktop 2. Boot the downloaded ISO file in a virtual machine 3. Start gnome-terminal 4. sudo -i 5. apt-add-repository universe 6. apt -y install unbound 7. systemctl status unbound # verify that it is runnning 8. systemctl restart unbound 9. systemctl status unbound # verify that it failed to start 10. journalctl -kn1 # display AppArmor error message To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1841364/+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 1068756] Re: IPv6 Privacy Extensions enabled on Ubuntu Server by default
Hi Christian. Some comments/corrections: 1) On servers privacy extensions are *not* always enabled. As I pointed out in comment #24, if NM is not in use, privacy extensions are only enabled for userspace-created interfaces such as "vlan123". It is *not* enabled by default for physical interfaces such as "eth0". This is inconistent, but at least it's a good default for most people (i.e., those that are using "eth0"). 2) The old bugs #176125 and #841353 concern themselves with the potential leak of information of the user's MAC address. While this was a valid concern in the past, it no longer is. This is because (as I also pointed out in comment #24) NM will by default use RFC7217 interface identifiers. These do not contain the MAC address. Additionally, they will change when moving between networks, preventing tracking. 3) Finally, which has been pointed out by others earlier in the thread, even RFC4941 itself recommends that privacy extensions are disabled by default. Tore -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1068756 Title: IPv6 Privacy Extensions enabled on Ubuntu Server by default Status in cloud-init package in Ubuntu: Triaged Status in procps package in Ubuntu: Confirmed Bug description: Ubuntu 12.04 LTS and Ubuntu 12.10 server images both ship with the IPv6 Privacy Extensions enabled (as defined in RFC 4941[0]). Not only are they enabled, but these addresses are preferred over addresses obtained using SLAAC. While is may be considered a reasonable default on an image being used on a personal computer, it's not something that is sane to have enabled by default in a server environment. Having this extension enabled can wreak havoc if you are expecting a specific IPv6 address when you know the MAC addresses of your systems beforehand. The file that is responsible for causing this to be defaulted to enabled is: "/etc/sysctl.d/10-ipv6-privacy.conf". This file appears to be part of the procps package (as per the output of 'dpkg -S') and contains the following: # IPv6 Privacy Extensions (RFC 4941) # --- # IPv6 typically uses a device's MAC address when choosing an IPv6 address # to use in autoconfiguration. Privacy extensions allow using a randomly # generated IPv6 address, which increases privacy. # # Acceptable values: #0 - don’t use privacy extensions. #1 - generate privacy addresses #2 - prefer privacy addresses and use them over the normal addresses. net.ipv6.conf.all.use_tempaddr = 2 net.ipv6.conf.default.use_tempaddr = 2 In short, IPv6 privacy extensions should not be enabled by default when deploying an Ubuntu server image. In a server environment you should be able to reliably determine your IPv6 address based on the MAC address of the system. Thank you for taking the time to look in to this as well as consider changing the default behavior of Ubuntu server. -Tim Heckman [0] http://tools.ietf.org/html/rfc4941 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1068756/+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 1547193] Re: Impossible to answer "disk drive not ready" question on serial console
Still happens on a fully updated Trusty LTS. ** Changed in: mountall (Ubuntu) Status: Expired => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mountall in Ubuntu. https://bugs.launchpad.net/bugs/1547193 Title: Impossible to answer "disk drive not ready" question on serial console Status in mountall package in Ubuntu: Confirmed Bug description: When booting a server that is suffering from a (probably unrelated) bug in multipath-tools, I get the following questions posed on the serial console during bootup: The disk drive for /opt/vnx is not ready yet or not present. Continue to wait, or Press S to skip mounting or M for manual recovery Problem is, pressing "S" or "M" (even if followed by a newline) does absolutely nothing on the serial console. It does work on the KVM console, but that might not be available. You might very well need to send someone to a physical data centre somewhere in the middle of nowhere. (I ended up with powercycling the server, temporarily network booting it into a ramdisk, mounting the rootfs and commenting out the problematic entry from /etc/fstab, and rebooting again - which went fine, allowing me to later mount the missing filesystem manually via ssh.) I found no way to make the boot finish or break out to a debug shell, and it happens before sshd starts, so you're basically stuck with no apparent way to recover. For this reason I feel the bug is quite severe. For what it's worth I'm running 14.04.4 LTS, mountall package version is 2.53. The kernel command line is «BOOT_IMAGE=/@/boot/vmlinuz-3.13.0-77-generic root=UUID=2a141a43-97b0-4084-8816-ed1c41ac43e0 ro rootflags=subvol=@ console=tty1 console=ttyS0,115200n8». Tore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1547193/+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 1573982] Re: LVM boot problem - volumes not activated after upgrade to Xenial
I ran across the same bug. It was caused by the root filesystem being specified on the kernel command line with the root=UUID= syntax. This is not handled by the case "$dev" in stanza in activate() in /usr/share/initramfs-tools/scripts/local-top/lvm2. See attached screenshot. If I change the kernel command line to say root=/dev/vg0/root instead it works. ** Attachment added: "Screenshot of initramfs lvm2 script failing on UUID root syntax" https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1573982/+attachment/4870302/+files/Screenshot.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1573982 Title: LVM boot problem - volumes not activated after upgrade to Xenial Status in lvm2 package in Ubuntu: Confirmed Bug description: Soon after upgrade to Xenial (from 15.10) the boot process got broken. I'm using LVM for /root swap and other partitions. === The current behaviour is: When I boot short after the Grub login screen I'm getting log messages like: --- Scanning for Btrfs filesystems resume: Could not state the resume device file: '/dev/mapper/VolGroup' Please type in the full path... --- Then I press ENTER, for a few minutes some errors about floppy device access are raised (for some reason it tries to scan fd0 when floppy drive is empty). And then: --- Gave up waiting for root device. Common problems: ... ... ALERT! UUID=xxx-xxx does not exist. Dropping to a shell. --- From the BusyBox shell I managed to recover the boot by issuing "lvm vgchange -ay", then exit and then boot continues fine (all LVM file systems are successfully mounted). === One workaround so far is creating /etc/initramfs-tools/scripts/local-top/lvm2-manual script doing "lvm vgchange -ay". But I'm looking for cleaner solution. Boot used to work fine with 15.10. Actually the first boot after upgrading to Xenial actually worked OK too, I'm not sure what might changed meanwhile (I've been fixing some packages installation since mysql server upgrade has failed). === # lsb_release -rd Description: Ubuntu 16.04 LTS Release: 16.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1573982/+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 1547193] Re: Impossible to answer "disk drive not ready" question on serial console
Yes. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mountall in Ubuntu. https://bugs.launchpad.net/bugs/1547193 Title: Impossible to answer "disk drive not ready" question on serial console Status in mountall package in Ubuntu: Incomplete Bug description: When booting a server that is suffering from a (probably unrelated) bug in multipath-tools, I get the following questions posed on the serial console during bootup: The disk drive for /opt/vnx is not ready yet or not present. Continue to wait, or Press S to skip mounting or M for manual recovery Problem is, pressing "S" or "M" (even if followed by a newline) does absolutely nothing on the serial console. It does work on the KVM console, but that might not be available. You might very well need to send someone to a physical data centre somewhere in the middle of nowhere. (I ended up with powercycling the server, temporarily network booting it into a ramdisk, mounting the rootfs and commenting out the problematic entry from /etc/fstab, and rebooting again - which went fine, allowing me to later mount the missing filesystem manually via ssh.) I found no way to make the boot finish or break out to a debug shell, and it happens before sshd starts, so you're basically stuck with no apparent way to recover. For this reason I feel the bug is quite severe. For what it's worth I'm running 14.04.4 LTS, mountall package version is 2.53. The kernel command line is «BOOT_IMAGE=/@/boot/vmlinuz-3.13.0-77-generic root=UUID=2a141a43-97b0-4084-8816-ed1c41ac43e0 ro rootflags=subvol=@ console=tty1 console=ttyS0,115200n8». Tore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1547193/+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 1068756] Re: IPv6 Privacy Extensions enabled on Ubuntu Server by default
In case anyone's interested in knowing why setting net/ipv6/conf/all/use_tempaddr=2 no longer changes the value of pre- existing interfaces (thus ensuring privacy extensions are disabled by default for physical interfaces configured through /etc/network/interfaces), it's because http://kernel.ubuntu.com/git/ubuntu/ubuntu- trusty.git/commit/?id=c999e7dff4570e4c28a0953e7189c0c31343ce62 was dropped from the Ubuntu kernel packages starting with Utopic. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1068756 Title: IPv6 Privacy Extensions enabled on Ubuntu Server by default Status in cloud-init package in Ubuntu: Triaged Status in procps package in Ubuntu: Confirmed Bug description: Ubuntu 12.04 LTS and Ubuntu 12.10 server images both ship with the IPv6 Privacy Extensions enabled (as defined in RFC 4941[0]). Not only are they enabled, but these addresses are preferred over addresses obtained using SLAAC. While is may be considered a reasonable default on an image being used on a personal computer, it's not something that is sane to have enabled by default in a server environment. Having this extension enabled can wreak havoc if you are expecting a specific IPv6 address when you know the MAC addresses of your systems beforehand. The file that is responsible for causing this to be defaulted to enabled is: "/etc/sysctl.d/10-ipv6-privacy.conf". This file appears to be part of the procps package (as per the output of 'dpkg -S') and contains the following: # IPv6 Privacy Extensions (RFC 4941) # --- # IPv6 typically uses a device's MAC address when choosing an IPv6 address # to use in autoconfiguration. Privacy extensions allow using a randomly # generated IPv6 address, which increases privacy. # # Acceptable values: #0 - don’t use privacy extensions. #1 - generate privacy addresses #2 - prefer privacy addresses and use them over the normal addresses. net.ipv6.conf.all.use_tempaddr = 2 net.ipv6.conf.default.use_tempaddr = 2 In short, IPv6 privacy extensions should not be enabled by default when deploying an Ubuntu server image. In a server environment you should be able to reliably determine your IPv6 address based on the MAC address of the system. Thank you for taking the time to look in to this as well as consider changing the default behavior of Ubuntu server. -Tim Heckman [0] http://tools.ietf.org/html/rfc4941 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1068756/+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 1497166] Re: procps' 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings
This issue seems to have been resolved in Xenial as a side-effect of changing to systemd, as systemd-sysctl.service runs before NetworkManager.service and networking.service. When those services configure a device-specific use_tempaddr sysctl, it will be left alone. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1497166 Title: procps' 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings Status in ifupdown package in Ubuntu: New Status in network-manager package in Ubuntu: New Status in procps package in Ubuntu: New Bug description: I have configured the following in /etc/network/interfaces: auto eth0 iface eth0 inet6 auto privext 0 According to interfaces(5), this should disable IPv6 Privacy Extensions. However, after booting the machine, /proc/sys/net/ipv6/conf/eth0/use_tempaddr contains the value "2" - which means that Privacy Extensions are enabled. However running "ifdown eth0; ifup eth0" does fix the problem, so it is clear that ifup(8) does correctly set the use_tempaddr sysctl when bringing up the interface. What's going on is that sometime later in the bootup process, the procps package overrides the user-configured value and sets it unconditionally to "2" for every interface on the system. This happens because the file /etc/sysctl.d/10-ipv6-privacy.conf contains "net.ipv6.conf.all.use_tempaddr = 2". It should not, or this bug should be reassigned to the ifupdown package requesting for the removal of the defunct "privext" setting. On a related node, enabling IPv6 Privacy Extensions by default is counter to RFC 4941's recommendations. Quoting from section 3.6 Deployment Considerations: The use of temporary addresses may cause unexpected difficulties with some applications. As described below, some servers refuse to accept communications from clients for which they cannot map the IP address into a DNS name. In addition, some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions, but expects them to all use the same addresses. Consequently, the use of temporary addresses SHOULD be disabled by default in order to minimize potential disruptions. Individual applications, which have specific knowledge about the normal duration of connections, MAY override this as appropriate. As such, the most appropriate course of action is probably to stop shipping the 10-ipv6-privacy.conf file by default. The described behaviour is observed on Trusty LTS. Tore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1497166/+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 1068756] Re: IPv6 Privacy Extensions enabled on Ubuntu Server by default
Correction to my previous comment: "disable_ipv6" should of course have read "use_tempaddr" throughout, except for the part about NM bouncing the disable_ipv6 sysctl. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1068756 Title: IPv6 Privacy Extensions enabled on Ubuntu Server by default Status in cloud-init package in Ubuntu: Triaged Status in procps package in Ubuntu: Confirmed Bug description: Ubuntu 12.04 LTS and Ubuntu 12.10 server images both ship with the IPv6 Privacy Extensions enabled (as defined in RFC 4941[0]). Not only are they enabled, but these addresses are preferred over addresses obtained using SLAAC. While is may be considered a reasonable default on an image being used on a personal computer, it's not something that is sane to have enabled by default in a server environment. Having this extension enabled can wreak havoc if you are expecting a specific IPv6 address when you know the MAC addresses of your systems beforehand. The file that is responsible for causing this to be defaulted to enabled is: "/etc/sysctl.d/10-ipv6-privacy.conf". This file appears to be part of the procps package (as per the output of 'dpkg -S') and contains the following: # IPv6 Privacy Extensions (RFC 4941) # --- # IPv6 typically uses a device's MAC address when choosing an IPv6 address # to use in autoconfiguration. Privacy extensions allow using a randomly # generated IPv6 address, which increases privacy. # # Acceptable values: #0 - don’t use privacy extensions. #1 - generate privacy addresses #2 - prefer privacy addresses and use them over the normal addresses. net.ipv6.conf.all.use_tempaddr = 2 net.ipv6.conf.default.use_tempaddr = 2 In short, IPv6 privacy extensions should not be enabled by default when deploying an Ubuntu server image. In a server environment you should be able to reliably determine your IPv6 address based on the MAC address of the system. Thank you for taking the time to look in to this as well as consider changing the default behavior of Ubuntu server. -Tim Heckman [0] http://tools.ietf.org/html/rfc4941 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1068756/+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 1068756] Re: IPv6 Privacy Extensions enabled on Ubuntu Server by default
The situation appears to have improved somewhat in Xenial. The net/ipv6/conf/all/disable_ipv6 sysctl appears to have become a no-op in recent kernels, so when 10-ipv6-privacy.conf gets applied during the bootup sequence (by systemd-sysctl.service) it does *not* change the effective per-device setting for already existing devices (which defaults to 0). However, devices that show up later in the boot process, the 10-ipv6-privacy.conf-set value of net/ipv6/conf/default/disable_ipv6 is inherited, so privacy extensions remain enabled by default for userspace-created devices. Finally, NetworkManager will by default bounce the disable_ipv6 sysctl on devices it's bringing up. That seems to cause the device's use_tempaddr sysctl to be re-inherited from net/ipv6/conf/default/disable_ipv6, ensuring the setting from 10-ipv6-privacy.conf is applied. In summary, the following seems to be true in Xenial: - Physical kernel-plumbed interfaces (e.g., "eth0") managed through interfaces(5): Privacy extensions disabled by default. - Physical kernel-plumbed interfaces (e.g., "eth0") managed through NetworkManager(8): Privacy extensions enabled by default. - User-space created interfaces (e.g., "bond0" or "vlan123"), regardless of management method: Privacy extensions enabled by default. Another thing worth noting is that the version of NetworkManager shipped by Xenial uses RFC7217 Interface IDs by default. These are randomly generated and do not leak MAC addresses, yet they are stable on any given link/network. They will change when the link prefix changes, thus preventing tracking between networks. So where NetworkManager is used, there is IMHO very little rationale remaining for enabling RFC 4941 privacy extensions by default. https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy- in-the-ipv6-internet/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1068756 Title: IPv6 Privacy Extensions enabled on Ubuntu Server by default Status in cloud-init package in Ubuntu: Triaged Status in procps package in Ubuntu: Confirmed Bug description: Ubuntu 12.04 LTS and Ubuntu 12.10 server images both ship with the IPv6 Privacy Extensions enabled (as defined in RFC 4941[0]). Not only are they enabled, but these addresses are preferred over addresses obtained using SLAAC. While is may be considered a reasonable default on an image being used on a personal computer, it's not something that is sane to have enabled by default in a server environment. Having this extension enabled can wreak havoc if you are expecting a specific IPv6 address when you know the MAC addresses of your systems beforehand. The file that is responsible for causing this to be defaulted to enabled is: "/etc/sysctl.d/10-ipv6-privacy.conf". This file appears to be part of the procps package (as per the output of 'dpkg -S') and contains the following: # IPv6 Privacy Extensions (RFC 4941) # --- # IPv6 typically uses a device's MAC address when choosing an IPv6 address # to use in autoconfiguration. Privacy extensions allow using a randomly # generated IPv6 address, which increases privacy. # # Acceptable values: #0 - don’t use privacy extensions. #1 - generate privacy addresses #2 - prefer privacy addresses and use them over the normal addresses. net.ipv6.conf.all.use_tempaddr = 2 net.ipv6.conf.default.use_tempaddr = 2 In short, IPv6 privacy extensions should not be enabled by default when deploying an Ubuntu server image. In a server environment you should be able to reliably determine your IPv6 address based on the MAC address of the system. Thank you for taking the time to look in to this as well as consider changing the default behavior of Ubuntu server. -Tim Heckman [0] http://tools.ietf.org/html/rfc4941 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1068756/+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 1547193] Re: Impossible to answer "disk drive not ready" question on serial console
Small correction to what I wrote above, what actually appears on the serial console is the following (note "keys:"): The disk drive for /opt/vnx is not ready yet or not present. keys:Continue to wait, or Press S to skip mounting or M for manual recovery -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mountall in Ubuntu. https://bugs.launchpad.net/bugs/1547193 Title: Impossible to answer "disk drive not ready" question on serial console Status in mountall package in Ubuntu: New Bug description: When booting a server that is suffering from a (probably unrelated) bug in multipath-tools, I get the following questions posed on the serial console during bootup: The disk drive for /opt/vnx is not ready yet or not present. Continue to wait, or Press S to skip mounting or M for manual recovery Problem is, pressing "S" or "M" (even if followed by a newline) does absolutely nothing on the serial console. It does work on the KVM console, but that might not be available. You might very well need to send someone to a physical data centre somewhere in the middle of nowhere. (I ended up with powercycling the server, temporarily network booting it into a ramdisk, mounting the rootfs and commenting out the problematic entry from /etc/fstab, and rebooting again - which went fine, allowing me to later mount the missing filesystem manually via ssh.) I found no way to make the boot finish or break out to a debug shell, and it happens before sshd starts, so you're basically stuck with no apparent way to recover. For this reason I feel the bug is quite severe. For what it's worth I'm running 14.04.4 LTS, mountall package version is 2.53. The kernel command line is «BOOT_IMAGE=/@/boot/vmlinuz-3.13.0-77-generic root=UUID=2a141a43-97b0-4084-8816-ed1c41ac43e0 ro rootflags=subvol=@ console=tty1 console=ttyS0,115200n8». Tore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1547193/+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 1547193] [NEW] Impossible to answer "disk drive not ready" question on serial console
Public bug reported: When booting a server that is suffering from a (probably unrelated) bug in multipath-tools, I get the following questions posed on the serial console during bootup: The disk drive for /opt/vnx is not ready yet or not present. Continue to wait, or Press S to skip mounting or M for manual recovery Problem is, pressing "S" or "M" (even if followed by a newline) does absolutely nothing on the serial console. It does work on the KVM console, but that might not be available. You might very well need to send someone to a physical data centre somewhere in the middle of nowhere. (I ended up with powercycling the server, temporarily network booting it into a ramdisk, mounting the rootfs and commenting out the problematic entry from /etc/fstab, and rebooting again - which went fine, allowing me to later mount the missing filesystem manually via ssh.) I found no way to make the boot finish or break out to a debug shell, and it happens before sshd starts, so you're basically stuck with no apparent way to recover. For this reason I feel the bug is quite severe. For what it's worth I'm running 14.04.4 LTS, mountall package version is 2.53. The kernel command line is «BOOT_IMAGE=/@/boot/vmlinuz-3.13.0-77-generic root=UUID=2a141a43-97b0-4084-8816-ed1c41ac43e0 ro rootflags=subvol=@ console=tty1 console=ttyS0,115200n8». Tore ** Affects: mountall (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mountall in Ubuntu. https://bugs.launchpad.net/bugs/1547193 Title: Impossible to answer "disk drive not ready" question on serial console Status in mountall package in Ubuntu: New Bug description: When booting a server that is suffering from a (probably unrelated) bug in multipath-tools, I get the following questions posed on the serial console during bootup: The disk drive for /opt/vnx is not ready yet or not present. Continue to wait, or Press S to skip mounting or M for manual recovery Problem is, pressing "S" or "M" (even if followed by a newline) does absolutely nothing on the serial console. It does work on the KVM console, but that might not be available. You might very well need to send someone to a physical data centre somewhere in the middle of nowhere. (I ended up with powercycling the server, temporarily network booting it into a ramdisk, mounting the rootfs and commenting out the problematic entry from /etc/fstab, and rebooting again - which went fine, allowing me to later mount the missing filesystem manually via ssh.) I found no way to make the boot finish or break out to a debug shell, and it happens before sshd starts, so you're basically stuck with no apparent way to recover. For this reason I feel the bug is quite severe. For what it's worth I'm running 14.04.4 LTS, mountall package version is 2.53. The kernel command line is «BOOT_IMAGE=/@/boot/vmlinuz-3.13.0-77-generic root=UUID=2a141a43-97b0-4084-8816-ed1c41ac43e0 ro rootflags=subvol=@ console=tty1 console=ttyS0,115200n8». Tore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1547193/+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 1497166] Re: 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings
I just realised that this bug also impacts NetworkManager, at least on Vivid: I set the property "ipv6.ip6-privacy" on the default wired Ethernet interface to 0 (in order to prevent a remote CIFS mount from freezing every few hours), however after a reboot, privacy extensions remained active. My assumption is that NetworkManager configured the interface correctly (without privacy extensions) early on during the boot process, only to have the procps' 10-ipv6-privacy.conf overwrite it moments later. Disabling 10-ipv6-privacy.conf solved this issue too. ** Summary changed: - 10-ipv6-privacy.conf stomps on user-configured "privext" option + 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings ** Also affects: ifupdown (Ubuntu) Importance: Undecided Status: New ** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Summary changed: - 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings + procps' 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1497166 Title: procps' 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings Status in ifupdown package in Ubuntu: New Status in network-manager package in Ubuntu: New Status in procps package in Ubuntu: New Bug description: I have configured the following in /etc/network/interfaces: auto eth0 iface eth0 inet6 auto privext 0 According to interfaces(5), this should disable IPv6 Privacy Extensions. However, after booting the machine, /proc/sys/net/ipv6/conf/eth0/use_tempaddr contains the value "2" - which means that Privacy Extensions are enabled. However running "ifdown eth0; ifup eth0" does fix the problem, so it is clear that ifup(8) does correctly set the use_tempaddr sysctl when bringing up the interface. What's going on is that sometime later in the bootup process, the procps package overrides the user-configured value and sets it unconditionally to "2" for every interface on the system. This happens because the file /etc/sysctl.d/10-ipv6-privacy.conf contains "net.ipv6.conf.all.use_tempaddr = 2". It should not, or this bug should be reassigned to the ifupdown package requesting for the removal of the defunct "privext" setting. On a related node, enabling IPv6 Privacy Extensions by default is counter to RFC 4941's recommendations. Quoting from section 3.6 Deployment Considerations: The use of temporary addresses may cause unexpected difficulties with some applications. As described below, some servers refuse to accept communications from clients for which they cannot map the IP address into a DNS name. In addition, some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions, but expects them to all use the same addresses. Consequently, the use of temporary addresses SHOULD be disabled by default in order to minimize potential disruptions. Individual applications, which have specific knowledge about the normal duration of connections, MAY override this as appropriate. As such, the most appropriate course of action is probably to stop shipping the 10-ipv6-privacy.conf file by default. The described behaviour is observed on Trusty LTS. Tore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1497166/+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 1497166] [NEW] 10-ipv6-privacy.conf stomps on user-configured "privext" option
Public bug reported: I have configured the following in /etc/network/interfaces: auto eth0 iface eth0 inet6 auto privext 0 According to interfaces(5), this should disable IPv6 Privacy Extensions. However, after booting the machine, /proc/sys/net/ipv6/conf/eth0/use_tempaddr contains the value "2" - which means that Privacy Extensions are enabled. However running "ifdown eth0; ifup eth0" does fix the problem, so it is clear that ifup(8) does correctly set the use_tempaddr sysctl when bringing up the interface. What's going on is that sometime later in the bootup process, the procps package overrides the user-configured value and sets it unconditionally to "2" for every interface on the system. This happens because the file /etc/sysctl.d/10-ipv6-privacy.conf contains "net.ipv6.conf.all.use_tempaddr = 2". It should not, or this bug should be reassigned to the ifupdown package requesting for the removal of the defunct "privext" setting. On a related node, enabling IPv6 Privacy Extensions by default is counter to RFC 4941's recommendations. Quoting from section 3.6 Deployment Considerations: The use of temporary addresses may cause unexpected difficulties with some applications. As described below, some servers refuse to accept communications from clients for which they cannot map the IP address into a DNS name. In addition, some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions, but expects them to all use the same addresses. Consequently, the use of temporary addresses SHOULD be disabled by default in order to minimize potential disruptions. Individual applications, which have specific knowledge about the normal duration of connections, MAY override this as appropriate. As such, the most appropriate course of action is probably to stop shipping the 10-ipv6-privacy.conf file by default. The described behaviour is observed on Trusty LTS. Tore ** Affects: procps (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1497166 Title: 10-ipv6-privacy.conf stomps on user-configured "privext" option Status in procps package in Ubuntu: New Bug description: I have configured the following in /etc/network/interfaces: auto eth0 iface eth0 inet6 auto privext 0 According to interfaces(5), this should disable IPv6 Privacy Extensions. However, after booting the machine, /proc/sys/net/ipv6/conf/eth0/use_tempaddr contains the value "2" - which means that Privacy Extensions are enabled. However running "ifdown eth0; ifup eth0" does fix the problem, so it is clear that ifup(8) does correctly set the use_tempaddr sysctl when bringing up the interface. What's going on is that sometime later in the bootup process, the procps package overrides the user-configured value and sets it unconditionally to "2" for every interface on the system. This happens because the file /etc/sysctl.d/10-ipv6-privacy.conf contains "net.ipv6.conf.all.use_tempaddr = 2". It should not, or this bug should be reassigned to the ifupdown package requesting for the removal of the defunct "privext" setting. On a related node, enabling IPv6 Privacy Extensions by default is counter to RFC 4941's recommendations. Quoting from section 3.6 Deployment Considerations: The use of temporary addresses may cause unexpected difficulties with some applications. As described below, some servers refuse to accept communications from clients for which they cannot map the IP address into a DNS name. In addition, some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions, but expects them to all use the same addresses. Consequently, the use of temporary addresses SHOULD be disabled by default in order to minimize potential disruptions. Individual applications, which have specific knowledge about the normal duration of connections, MAY override this as appropriate. As such, the most appropriate course of action is probably to stop shipping the 10-ipv6-privacy.conf file by default. The described behaviour is observed on Trusty LTS. Tore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1497166/+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 406397] Re: init: job stuck with expect fork/daemon when parent reaps child
** Also affects: irqbalance (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/406397 Title: init: job stuck with expect fork/daemon when parent reaps child Status in Upstart: Triaged Status in irqbalance package in Ubuntu: New Status in upstart package in Ubuntu: Invalid Status in upstart package in Debian: Confirmed Status in PLD Linux Distribution: New Bug description: Hi Wrong use of the expect fork stanza can create job with status job stop/killled, process nnn without any process nnn running on the system. As an example the following avahi.conf should have used "expect daemon", but will instead create a stuck job. stop on stopping dbus-system respawn expect fork exec avahi-daemon -D /Emil Renner Berthing To manage notifications about this bug go to: https://bugs.launchpad.net/upstart/+bug/406397/+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
