[Desktop-packages] [Bug 2011385] Re: [950XED, Realtek ALC298, Speaker, Internal] No sound at all
What's the resolution here? I've tried every incantation of fixes and patches. I'm currently running 6.9-rc but even that doesn't resolve the problem. Latest installs of sof-firmwre, updating alsa tools...nothing -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/2011385 Title: [950XED, Realtek ALC298, Speaker, Internal] No sound at all Status in alsa-driver package in Ubuntu: Confirmed Status in linux-hwe-5.19 package in Ubuntu: Confirmed Bug description: only bluetooth can work,im sungsang book2 pro ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.19.0-35.36~22.04.1-generic 5.19.17 Uname: Linux 5.19.0-35-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.3 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: wang 1658 F pulseaudio CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Mar 13 15:41:47 2023 InstallationDate: Installed on 2023-03-08 (4 days ago) InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:sofhdadsp failed Symptom_Card: sof-hda-dsp - sof-hda-dsp Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: wang 1658 F pulseaudio Symptom_Jack: Speaker, Internal Symptom_Type: No sound at all Title: [950XED, Realtek ALC298, Speaker, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/17/2022 dmi.bios.release: 5.25 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: P08RGF.054.220817.ZQ dmi.board.asset.tag: No Asset Tag dmi.board.name: NT950XEW-A51AS dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.board.version: SGLFREEDOS-C00-R000-S+1.0. dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrP08RGF.054.220817.ZQ:bd08/17/2022:br5.25:svnSAMSUNGELECTRONICSCO.,LTD.:pn950XED:pvrP08RGF:rvnSAMSUNGELECTRONICSCO.,LTD.:rnNT950XEW-A51AS:rvrSGLFREEDOS-C00-R000-S+1.0.:cvnSAMSUNGELECTRONICSCO.,LTD.:ct10:cvrN/A:skuSCAI-ICPS-A5A5-ADLP-PRGF: dmi.product.family: Galaxy Book2 Pro dmi.product.name: 950XED dmi.product.sku: SCAI-ICPS-A5A5-ADLP-PRGF dmi.product.version: P08RGF dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/2011385/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1988499] [NEW] Snap prevents repartitioning Azure resource disk
Public bug reported: In an Azure VM, the resource disk (a.k.a. “local” or “temp” disk) has a single partition created by the Azure infrastructure. Linux cloud-init creates an ext4 file system in that partition and arranges for it to be mounted on /mnt. In Ubuntu 20.04 and Ubuntu 22.04 images in the Azure Marketplace, snap then creates a bind mount of /mnt for its internal purposes. Some customers want to use the Azure resource disk for purposes other than a file system mounted on /mnt. If they unmount the disk, and use a partition editor to remove or change the partition structure, the closing ioctl to re-read the partition table fails because the Linux kernel still has a reference to the disk. The command “blockdev --rereadpt” also fails. After debugging this problem, it turns out that the umount of /mnt only partially succeeds, and that’s why the ioctl thinks the disk is still in use. From what’s visible in the file system, the umount has succeeded. And “lsblk” shows that /dev/sdb1 (assuming the resource disk is /dev/sdb) as not mounted anywhere. But this message: [ 51.885870] EXT4-fs (sdb1): unmounting filesystem. is *not* output in dmesg because internally the Linux kernel still has a reference to the mount that it is waiting (forever) to go away. The problem is that snap has a reference to the mount, which was created by “snap-confine” doing the bind mount. This behavior of snap is specifically for the /mnt mount point (and maybe “/” for the root file system?): * If I bugger things up a bit so that cloud-init doesn’t force the resource disk mount point to be /mnt, and change it to be /mnt2, then Ubuntu boots normally, and mounts the resource disk on /mnt2. At that point, I can umount /mnt2, and the umount is done 100%, including the “unmounting filesystem” message in dmesg. The ioctl problem in fdisk or parted goes away commensurately. * If I remove “snap” entirely from my Ubuntu 20.04 installation, the problem also goes away. * The problem does not occur on RHEL 8.5 or CentOS 8.5, which don’t have snap in the first place. What’s the right way to solve this problem? Unfortunately, I’m not knowledgeable about snap or what snap-confine is trying to do. * Why is snap tracking /mnt? Is there a way to tell snap not to track /mnt? * Or is there some design flaw in snap that causes the mount on /mnt to not work normally? Longer run, we’re looking at enhancing cloud-init with an option to not mount the resource disk at all, which should avoid the problem. But still, there should be a way for the mount of the resource disk on /mnt to work normally. ** Affects: ubuntu Importance: Undecided Status: New ** Package changed: gnome-bluetooth (Ubuntu) => ubuntu -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-bluetooth in Ubuntu. https://bugs.launchpad.net/bugs/1988499 Title: Snap prevents repartitioning Azure resource disk Status in Ubuntu: New Bug description: In an Azure VM, the resource disk (a.k.a. “local” or “temp” disk) has a single partition created by the Azure infrastructure. Linux cloud- init creates an ext4 file system in that partition and arranges for it to be mounted on /mnt. In Ubuntu 20.04 and Ubuntu 22.04 images in the Azure Marketplace, snap then creates a bind mount of /mnt for its internal purposes. Some customers want to use the Azure resource disk for purposes other than a file system mounted on /mnt. If they unmount the disk, and use a partition editor to remove or change the partition structure, the closing ioctl to re-read the partition table fails because the Linux kernel still has a reference to the disk. The command “blockdev --rereadpt” also fails. After debugging this problem, it turns out that the umount of /mnt only partially succeeds, and that’s why the ioctl thinks the disk is still in use. From what’s visible in the file system, the umount has succeeded. And “lsblk” shows that /dev/sdb1 (assuming the resource disk is /dev/sdb) as not mounted anywhere. But this message: [ 51.885870] EXT4-fs (sdb1): unmounting filesystem. is *not* output in dmesg because internally the Linux kernel still has a reference to the mount that it is waiting (forever) to go away. The problem is that snap has a reference to the mount, which was created by “snap-confine” doing the bind mount. This behavior of snap is specifically for the /mnt mount point (and maybe “/” for the root file system?): * If I bugger things up a bit so that cloud-init doesn’t force the resource disk mount point to be /mnt, and change it to be /mnt2, then Ubuntu boots normally, and mounts the resource disk on /mnt2. At that point, I can umount /mnt2, and the umount is done 100%, including the “unmounting filesystem” message in dmesg. The ioctl problem in fdisk or parted goes away commensurately. * If I remove “snap” entirely from my
[Desktop-packages] [Bug 1586528] Re: Avahi-daemon withdraws address record
I am also seeing this same problem on a Raspberry Pi4 4GB. I purchased the Pi last November and installed from the then-available 2019-09-26-raspbian-buster.zip but routinely keep it updated (apt update / apt upgrade). The Pi was rock solid and did not exhibit any problems until 2020-02-24 when I applied some updates followed by a "sudo reboot" but the boot process did not complete. The Pi runs headless so I don't know whether it never actually completed the shutdown, or failed to reboot. I power- cycled the device and it came back OK. Another set of updates were applied on 2020-03-11 and the subsequent reboot completed without incident so I assumed the earlier problem was a one-off. Then, on 2020-03-14 the Pi froze. Wouldn't respond to pings, ssh or vnc. It is Ethernet-connected but the WiFi interface is active and it did not occur to me to try connecting via WiFi. I just did another power-cycle and then started nosing around through the logs. Which brought me to: Mar 14 12:48:16 iot-hub avahi-daemon[361]: Withdrawing address record for 192.168.132.60 on eth0. Mar 14 12:48:16 iot-hub avahi-daemon[361]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.132.60. Mar 14 12:48:16 iot-hub avahi-daemon[361]: Interface eth0.IPv4 no longer relevant for mDNS. and, from there, to this post. The main reasons I'm adding a comment to this post are (a) as a "me too" as of March 2020, and (b) in case the pattern of the RPi being perfectly OK until 2020-02-24 causes someone to say "ahah!" The updates in question were (from the history log): Upgrade: libpython3.7-minimal:armhf (3.7.3-2, 3.7.3-2+deb10u1), libraspberrypi- bin:armhf (1.20200114-1, 1.20200212-1), libopenjp2-7:armhf (2.3.0-2, 2.3.0-2+deb10u1), rc-gui:armhf (1.34, 1.36), libcom-err2:armhf (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libcups2:armhf (2.2.10-6+deb10u1, 2.2.10-6+deb10u2), libraspberrypi-dev:armhf (1.20200114-1, 1.20200212-1), libraspberrypi-doc:armhf (1.20200114-1, 1.20200212-1), python3.7-venv:armhf (3.7.3-2, 3.7.3-2+deb10u1), raspberrypi-ui- mods:armhf (1.20200127, 1.20200218), qt5-gtk-platformtheme:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), libfm4:armhf (1.3.1-1+rpt12, 1.3.1-1+rpt13), libsystemd0:armhf (241-7~deb10u2+rpi1, 241-7~deb10u3+rpi1), raspi-config:armhf (20200205, 20200207), libfm- modules:armhf (1.3.1-1+rpt12, 1.3.1-1+rpt13), libfm-extra4:armhf (1.3.1-1+rpt12, 1.3.1-1+rpt13), mariadb-common:armhf (1:10.3.17-0+deb10u1, 1:10.3.22-0+deb10u1), binutils:armhf (2.31.1-16+rpi1, 2.31.1-16+rpi2), e2fsprogs:armhf (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), sudo:armhf (1.8.27-1+deb10u1, 1.8.27-1+deb10u2), libqt5dbus5:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), libqt5sql5-sqlite:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), python3-pil:armhf (5.4.1-2, 5.4.1-2+deb10u1), libpython3.7:armhf (3.7.3-2, 3.7.3-2+deb10u1), python3.7:armhf (3.7.3-2, 3.7.3-2+deb10u1), openssh-sftp-server:armhf (1:7.9p1-10+deb10u1, 1:7.9p1-10+deb10u2), libqt5widgets5:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), libfm-gtk4:armhf (1.3.1-1+rpt12, 1.3.1-1+rpt13), udev:armhf (241-7~deb10u2+rpi1, 241-7~deb10u3+rpi1), python3.7-dev:armhf (3.7.3-2, 3.7.3-2+deb10u1), binutils-arm-linux-gnueabihf:armhf (2.31.1-16+rpi1, 2.31.1-16+rpi2), libpython3.7-stdlib:armhf (3.7.3-2, 3.7.3-2+deb10u1), libudev1:armhf (241-7~deb10u2+rpi1, 241-7~deb10u3+rpi1), python3.7-minimal:armhf (3.7.3-2, 3.7.3-2+deb10u1), libqt5xml5:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), libqt5printsupport5:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), raspberrypi- kernel:armhf (1.20200114-1, 1.20200212-1), libss2:armhf (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libqt5concurrent5:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), libext2fs2:armhf (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), raspberrypi-bootloader:armhf (1.20200114-1, 1.20200212-1), libexif12:armhf (0.6.21-5.1, 0.6.21-5.1+deb10u1), libqt5gui5:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), libimobiledevice6:armhf (1.2.1~git20181030.92c5462-1, 1.2.1~git20181030.92c5462-2), gldriver- test:armhf (0.4, 0.5), ssh:armhf (1:7.9p1-10+deb10u1, 1:7.9p1-10+deb10u2), systemd-sysv:armhf (241-7~deb10u2+rpi1, 241-7~deb10u3+rpi1), guile-2.2-libs:armhf (2.2.4+1-2, 2.2.4+1-2+deb10u1), realvnc-vnc-server:armhf (6.6.0.41949, 6.7.1.42348), libpython3.7-dev:armhf (3.7.3-2, 3.7.3-2+deb10u1), libpam-systemd:armhf (241-7~deb10u2+rpi1, 241-7~deb10u3+rpi1), libmatroska6v5:armhf (1.4.9-1, 1.4.9-1+deb10u1), systemd:armhf (241-7~deb10u2+rpi1, 241-7~deb10u3+rpi1), libwebkit2gtk-4.0-37:armhf (2.26.3-1~deb10u1+rpi1, 2.26.4-1~deb10u1+rpi1), libqt5core5a:armhf (5.11.3+dfsg1-1+rpi1, 5.11.3+dfsg1-1+rpi1+deb10u3), piwiz:armhf (0.8, 0.9), libraspberrypi0:armhf (1.20200114-1, 1.20200212-1), openssh-server:armhf (1:7.9p1-10+deb10u1, 1:7.9p1-10+deb10u2), openssh-client:armhf (1:7.9p1-10+deb10u1, 1:7.9p1-10+deb10u2), libmysofa0:armhf (0.6~dfsg0-3, 0.6~dfsg0-3+deb10u1), rpi-chromium-mods:armhf
[Desktop-packages] [Bug 1795121] Re: 18.10: Indicator icons not shown in the panel
Roberto Leinardi's comment on 9-29 might have been accurate for him, but overall it is not right. Appindicators still do not work on 18.10, including a fresh install of 18.10 after its release date, one in which Unity was never installed, nor unity-tweak-tool. I've seen that message repeated all over and it does nothing to solve the problem for me nor for most other people. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-appindicator in Ubuntu. https://bugs.launchpad.net/bugs/1795121 Title: 18.10: Indicator icons not shown in the panel Status in gnome-shell-extension-appindicator package in Ubuntu: Confirmed Bug description: The indicator icons are not showing on a fresh installation of Ubuntu 18.10 beta. On 18.04 I can see the tray icons of Chrome, Hangouts, Dropbox and InSync but on 18.10 they are missing. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: gnome-shell-extension-appindicator 22-1 ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5 Uname: Linux 4.18.0-7-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.10-0ubuntu11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Sat Sep 29 10:00:34 2018 Dependencies: InstallationDate: Installed on 2018-09-28 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Beta amd64 (20180927) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=it_IT.UTF-8 SHELL=/bin/bash SourcePackage: gnome-shell-extension-appindicator UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-appindicator/+bug/1795121/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1660496] [NEW] Libva upstream project has moved to Github from Freedesktop.org
Public bug reported: Package: libva Version: 1.7.3-2 I'm a maintainer of upstream Libva. I have moved our project from freedesktop.org to github.com. Wiki location has moved to: https://01.org/linuxmedia/vaapi Libva project has moved to https://github.com/01org/libva Use https://github.com/01org/libva/issues/new to file bugs on the libva github site Packages will need to be updated to pull source from the new github repos mentioned above. I have submitted this bug upstream to debian packagers of libva Bug#853270 853...@bugs.debian.org Thanks, Sean ** Affects: libva (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libva in Ubuntu. https://bugs.launchpad.net/bugs/1660496 Title: Libva upstream project has moved to Github from Freedesktop.org Status in libva package in Ubuntu: New Bug description: Package: libva Version: 1.7.3-2 I'm a maintainer of upstream Libva. I have moved our project from freedesktop.org to github.com. Wiki location has moved to: https://01.org/linuxmedia/vaapi Libva project has moved to https://github.com/01org/libva Use https://github.com/01org/libva/issues/new to file bugs on the libva github site Packages will need to be updated to pull source from the new github repos mentioned above. I have submitted this bug upstream to debian packagers of libva Bug#853270 853...@bugs.debian.org Thanks, Sean To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libva/+bug/1660496/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1581913] Re: touchpad not working or recognized (ASUS UX305)
** Description changed: + (8/7/16) My touchpad was once working and now it has stopped again. I'm + still using Ubuntu 16.04 LTS + **Update: I have since installed version 16.04 of Ubuntu and this is what my terminal brings up. I have no idea what this means considering I am currently using Ubuntu 16.04 LTS as I type this. The OS is working fine as far as I can tell. However, my touchpad is now working. Going forward for the Linux community, it is my recommendation that anyone with an ASUS Zenbook UX305 upgrade to 16.04 LTS in order to avoid the bug found in 14.04 so their touchpads actually work with the Ubuntu OS. kelley-rose@Zenbook:~$ apt-cache policy pkgname N: Unable to locate package pkgname kelley-rose@Zenbook:~$ /proc/bus/input/devices bash: /proc/bus/input/devices: Permission denied kelley-rose@Zenbook:~$ lsb_release -rd Description: Ubuntu 16.04 LTS Release: 16.04 - kelley-rose@Zenbook:~$ + kelley-rose@Zenbook:~$ - kelley-rose@Zenbook:~$ apt-cache policy pkgname N: Unable to locate package pkgname kelley-rose@Zenbook:~$ kelley-rose@Zenbook:~$ lsb_release -rd Description: Ubuntu 14.04.4 LTS Release: 14.04 My apple mouse works for both Windows 10 and Ubuntu, but the trackpad only works in Windows. kelley-rose@Zenbook:~$ cat /proc/bus/input/devices I: Bus=0019 Vendor= Product=0005 Version= N: Name="Lid Switch" P: Phys=PNP0C0D/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0 U: Uniq= H: Handlers=event0 B: PROP=0 B: EV=21 B: SW=1 I: Bus=0019 Vendor= Product=0003 Version= N: Name="Sleep Button" P: Phys=PNP0C0E/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 U: Uniq= H: Handlers=kbd event1 B: PROP=0 B: EV=3 B: KEY=4000 0 0 I: Bus=0019 Vendor= Product=0001 Version= N: Name="Power Button" P: Phys=LNXPWRBN/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 U: Uniq= H: Handlers=kbd event2 B: PROP=0 B: EV=3 B: KEY=10 0 I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/devices/platform/i8042/serio0/input/input3 U: Uniq= H: Handlers=sysrq kbd event3 B: PROP=0 B: EV=120013 B: KEY=40200 3803078f800d001 fedfffef fffe B: MSC=10 B: LED=7 I: Bus=0003 Vendor=064e Product=9700 Version=0101 N: Name="USB2.0 UVC HD Webcam" P: Phys=usb-:00:14.0-5/button S: Sysfs=/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input4 U: Uniq= H: Handlers=kbd event4 B: PROP=0 B: EV=3 B: KEY=10 0 0 0 I: Bus=0019 Vendor= Product=0006 Version= N: Name="Video Bus" P: Phys=LNXVIDEO/video/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input5 U: Uniq= H: Handlers=kbd event5 B: PROP=0 B: EV=3 B: KEY=3e000b 0 0 0 I: Bus=0019 Vendor= Product= Version= N: Name="Asus WMI hotkeys" P: Phys=asus-nb-wmi/input0 S: Sysfs=/devices/platform/asus-nb-wmi/input/input6 U: Uniq= H: Handlers=rfkill kbd event6 B: PROP=0 B: EV=100013 B: KEY=8 0 8000 0 0 a1606f0090 8200027800501000 e 0 B: MSC=10 I: Bus= Vendor= Product= Version= N: Name="HDA Intel PCH Headphone" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1f.3/sound/card0/input7 U: Uniq= H: Handlers=event7 B: PROP=0 B: EV=21 B: SW=4 I: Bus= Vendor= Product= Version= N: Name="HDA Intel PCH HDMI/DP,pcm=3" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1f.3/sound/card0/input8 U: Uniq= H: Handlers=event8 B: PROP=0 B: EV=21 B: SW=140 I: Bus=0003 Vendor=05ac Product=0304 Version=0110 N: Name="Primax Electronics Apple Optical USB Mouse" P: Phys=usb-:00:14.0-1/input0 S: Sysfs=/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.0/0003:05AC:0304.0004/input/input12 U: Uniq= H: Handlers=mouse0 event9 B: PROP=0 B: EV=100017 B: KEY=f 0 0 0 0 B: REL=143 B: MSC=10 kelley-rose@Zenbook:~$ ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: xorg 1:7.7+1ubuntu8.1 ProcVersionSignature: Ubuntu 3.19.0-59.65~14.04.1-generic 3.19.8-ckt19 Uname: Linux 3.19.0-59-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.14.1-0ubuntu3.19 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true Date: Sat May 14 22:17:15 2016 DistUpgraded: Fresh install DistroCodename: trusty DistroVariant: ubuntu ExtraD
[Desktop-packages] [Bug 1581913] Re: touchpad not working or recognized (ASUS UX305)
** Description changed: **Update: I have since installed version 16.04 of Ubuntu and this is what my terminal brings up. I have no idea what this means considering I - am currently using Ubuntu 16.04 as I type this. The OS is working fine - as far as I can tell. + am currently using Ubuntu 16.04 LTS as I type this. The OS is working + fine as far as I can tell. However, my touchpad is now working. Going + forward for the Linux community, it is my recommendation that anyone + with an ASUS Zenbook UX305 upgrade to 16.04 LTS in order to avoid the + bug found in 14.04 so their touchpads actually work with the Ubuntu OS. kelley-rose@Zenbook:~$ apt-cache policy pkgname N: Unable to locate package pkgname kelley-rose@Zenbook:~$ /proc/bus/input/devices bash: /proc/bus/input/devices: Permission denied + kelley-rose@Zenbook:~$ lsb_release -rd + Description: Ubuntu 16.04 LTS + Release: 16.04 kelley-rose@Zenbook:~$ + - kelley-rose@Zenbook:~$ apt-cache policy pkgname N: Unable to locate package pkgname kelley-rose@Zenbook:~$ kelley-rose@Zenbook:~$ lsb_release -rd Description: Ubuntu 14.04.4 LTS Release: 14.04 My apple mouse works for both Windows 10 and Ubuntu, but the trackpad only works in Windows. kelley-rose@Zenbook:~$ cat /proc/bus/input/devices I: Bus=0019 Vendor= Product=0005 Version= N: Name="Lid Switch" P: Phys=PNP0C0D/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0 U: Uniq= H: Handlers=event0 B: PROP=0 B: EV=21 B: SW=1 I: Bus=0019 Vendor= Product=0003 Version= N: Name="Sleep Button" P: Phys=PNP0C0E/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 U: Uniq= H: Handlers=kbd event1 B: PROP=0 B: EV=3 B: KEY=4000 0 0 I: Bus=0019 Vendor= Product=0001 Version= N: Name="Power Button" P: Phys=LNXPWRBN/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 U: Uniq= H: Handlers=kbd event2 B: PROP=0 B: EV=3 B: KEY=10 0 I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/devices/platform/i8042/serio0/input/input3 U: Uniq= H: Handlers=sysrq kbd event3 B: PROP=0 B: EV=120013 B: KEY=40200 3803078f800d001 fedfffef fffe B: MSC=10 B: LED=7 I: Bus=0003 Vendor=064e Product=9700 Version=0101 N: Name="USB2.0 UVC HD Webcam" P: Phys=usb-:00:14.0-5/button S: Sysfs=/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input4 U: Uniq= H: Handlers=kbd event4 B: PROP=0 B: EV=3 B: KEY=10 0 0 0 I: Bus=0019 Vendor= Product=0006 Version= N: Name="Video Bus" P: Phys=LNXVIDEO/video/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input5 U: Uniq= H: Handlers=kbd event5 B: PROP=0 B: EV=3 B: KEY=3e000b 0 0 0 I: Bus=0019 Vendor= Product= Version= N: Name="Asus WMI hotkeys" P: Phys=asus-nb-wmi/input0 S: Sysfs=/devices/platform/asus-nb-wmi/input/input6 U: Uniq= H: Handlers=rfkill kbd event6 B: PROP=0 B: EV=100013 B: KEY=8 0 8000 0 0 a1606f0090 8200027800501000 e 0 B: MSC=10 I: Bus= Vendor= Product= Version= N: Name="HDA Intel PCH Headphone" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1f.3/sound/card0/input7 U: Uniq= H: Handlers=event7 B: PROP=0 B: EV=21 B: SW=4 I: Bus= Vendor= Product= Version= N: Name="HDA Intel PCH HDMI/DP,pcm=3" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1f.3/sound/card0/input8 U: Uniq= H: Handlers=event8 B: PROP=0 B: EV=21 B: SW=140 I: Bus=0003 Vendor=05ac Product=0304 Version=0110 N: Name="Primax Electronics Apple Optical USB Mouse" P: Phys=usb-:00:14.0-1/input0 S: Sysfs=/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.0/0003:05AC:0304.0004/input/input12 U: Uniq= H: Handlers=mouse0 event9 B: PROP=0 B: EV=100017 B: KEY=f 0 0 0 0 B: REL=143 B: MSC=10 kelley-rose@Zenbook:~$ ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: xorg 1:7.7+1ubuntu8.1 ProcVersionSignature: Ubuntu 3.19.0-59.65~14.04.1-generic 3.19.8-ckt19 Uname: Linux 3.19.0-59-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.14.1-0ubuntu3.19 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true Date: Sat May 14 22:17:15 2016 DistUpgraded: Fresh install DistroCodename: trusty DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical
[Desktop-packages] [Bug 1581913] Re: touchpad not working or recognized (ASUS UX305)
** Description changed: kelley-rose@Zenbook:~$ apt-cache policy pkgname N: Unable to locate package pkgname kelley-rose@Zenbook:~$ kelley-rose@Zenbook:~$ lsb_release -rd Description: Ubuntu 14.04.4 LTS Release: 14.04 My apple mouse works for both Windows 10 and Ubuntu, but the trackpad only works in Windows. kelley-rose@Zenbook:~$ cat /proc/bus/input/devices I: Bus=0019 Vendor= Product=0005 Version= N: Name="Lid Switch" P: Phys=PNP0C0D/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0 U: Uniq= - H: Handlers=event0 + H: Handlers=event0 B: PROP=0 B: EV=21 B: SW=1 I: Bus=0019 Vendor= Product=0003 Version= N: Name="Sleep Button" P: Phys=PNP0C0E/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 U: Uniq= - H: Handlers=kbd event1 + H: Handlers=kbd event1 B: PROP=0 B: EV=3 B: KEY=4000 0 0 I: Bus=0019 Vendor= Product=0001 Version= N: Name="Power Button" P: Phys=LNXPWRBN/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 U: Uniq= - H: Handlers=kbd event2 + H: Handlers=kbd event2 B: PROP=0 B: EV=3 B: KEY=10 0 I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/devices/platform/i8042/serio0/input/input3 U: Uniq= - H: Handlers=sysrq kbd event3 + H: Handlers=sysrq kbd event3 B: PROP=0 B: EV=120013 B: KEY=40200 3803078f800d001 fedfffef fffe B: MSC=10 B: LED=7 I: Bus=0003 Vendor=064e Product=9700 Version=0101 N: Name="USB2.0 UVC HD Webcam" P: Phys=usb-:00:14.0-5/button S: Sysfs=/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input4 U: Uniq= - H: Handlers=kbd event4 + H: Handlers=kbd event4 B: PROP=0 B: EV=3 B: KEY=10 0 0 0 I: Bus=0019 Vendor= Product=0006 Version= N: Name="Video Bus" P: Phys=LNXVIDEO/video/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input5 U: Uniq= - H: Handlers=kbd event5 + H: Handlers=kbd event5 B: PROP=0 B: EV=3 B: KEY=3e000b 0 0 0 I: Bus=0019 Vendor= Product= Version= N: Name="Asus WMI hotkeys" P: Phys=asus-nb-wmi/input0 S: Sysfs=/devices/platform/asus-nb-wmi/input/input6 U: Uniq= - H: Handlers=rfkill kbd event6 + H: Handlers=rfkill kbd event6 B: PROP=0 B: EV=100013 B: KEY=8 0 8000 0 0 a1606f0090 8200027800501000 e 0 B: MSC=10 I: Bus= Vendor= Product= Version= N: Name="HDA Intel PCH Headphone" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1f.3/sound/card0/input7 U: Uniq= - H: Handlers=event7 + H: Handlers=event7 B: PROP=0 B: EV=21 B: SW=4 I: Bus= Vendor= Product= Version= N: Name="HDA Intel PCH HDMI/DP,pcm=3" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1f.3/sound/card0/input8 U: Uniq= - H: Handlers=event8 + H: Handlers=event8 B: PROP=0 B: EV=21 B: SW=140 I: Bus=0003 Vendor=05ac Product=0304 Version=0110 N: Name="Primax Electronics Apple Optical USB Mouse" P: Phys=usb-:00:14.0-1/input0 S: Sysfs=/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.0/0003:05AC:0304.0004/input/input12 U: Uniq= - H: Handlers=mouse0 event9 + H: Handlers=mouse0 event9 B: PROP=0 B: EV=100017 B: KEY=f 0 0 0 0 B: REL=143 B: MSC=10 kelley-rose@Zenbook:~$ ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: xorg 1:7.7+1ubuntu8.1 ProcVersionSignature: Ubuntu 3.19.0-59.65~14.04.1-generic 3.19.8-ckt19 Uname: Linux 3.19.0-59-generic x86_64 .tmp.unity.support.test.0: - + ApportVersion: 2.14.1-0ubuntu3.19 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true Date: Sat May 14 22:17:15 2016 DistUpgraded: Fresh install DistroCodename: trusty DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: - Intel Corporation Sky Lake Integrated Graphics [8086:191e] (rev 07) (prog-if 00 [VGA controller]) -Subsystem: ASUSTeK Computer Inc. Device [1043:1cfd] + Intel Corporation Sky Lake Integrated Graphics [8086:191e] (rev 07) (prog-if 00 [VGA controller]) + Subsystem: ASUSTeK Computer Inc. Device [1043:1cfd] InstallationDate: Installed on 2016-05-14 (1 days ago) InstallationMedia: It Lsusb: - Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub - Bus 001 Device 003: ID 8087:0a2a Intel Corp. - Bus 001 Device 002: ID 064e:9700 Suyin Corp. Asus Integrated Webcam - Bus 001 Device 007: ID 05ac:0304 Apple, Inc. Mighty Mouse [Mitsumi, M1152] - Bus 001 Device 001: ID 1d6b:0002 Li
[Desktop-packages] [Bug 1581913] [NEW] touchpad not working or recognized (ASUS UX305)
*** This bug is a security vulnerability *** Private security bug reported: kelley-rose@Zenbook:~$ apt-cache policy pkgname N: Unable to locate package pkgname kelley-rose@Zenbook:~$ kelley-rose@Zenbook:~$ lsb_release -rd Description:Ubuntu 14.04.4 LTS Release:14.04 My apple mouse works for both Windows 10 and Ubuntu, but the trackpad only works in Windows. kelley-rose@Zenbook:~$ cat /proc/bus/input/devices I: Bus=0019 Vendor= Product=0005 Version= N: Name="Lid Switch" P: Phys=PNP0C0D/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0 U: Uniq= H: Handlers=event0 B: PROP=0 B: EV=21 B: SW=1 I: Bus=0019 Vendor= Product=0003 Version= N: Name="Sleep Button" P: Phys=PNP0C0E/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 U: Uniq= H: Handlers=kbd event1 B: PROP=0 B: EV=3 B: KEY=4000 0 0 I: Bus=0019 Vendor= Product=0001 Version= N: Name="Power Button" P: Phys=LNXPWRBN/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 U: Uniq= H: Handlers=kbd event2 B: PROP=0 B: EV=3 B: KEY=10 0 I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 S: Sysfs=/devices/platform/i8042/serio0/input/input3 U: Uniq= H: Handlers=sysrq kbd event3 B: PROP=0 B: EV=120013 B: KEY=40200 3803078f800d001 fedfffef fffe B: MSC=10 B: LED=7 I: Bus=0003 Vendor=064e Product=9700 Version=0101 N: Name="USB2.0 UVC HD Webcam" P: Phys=usb-:00:14.0-5/button S: Sysfs=/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/input/input4 U: Uniq= H: Handlers=kbd event4 B: PROP=0 B: EV=3 B: KEY=10 0 0 0 I: Bus=0019 Vendor= Product=0006 Version= N: Name="Video Bus" P: Phys=LNXVIDEO/video/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input5 U: Uniq= H: Handlers=kbd event5 B: PROP=0 B: EV=3 B: KEY=3e000b 0 0 0 I: Bus=0019 Vendor= Product= Version= N: Name="Asus WMI hotkeys" P: Phys=asus-nb-wmi/input0 S: Sysfs=/devices/platform/asus-nb-wmi/input/input6 U: Uniq= H: Handlers=rfkill kbd event6 B: PROP=0 B: EV=100013 B: KEY=8 0 8000 0 0 a1606f0090 8200027800501000 e 0 B: MSC=10 I: Bus= Vendor= Product= Version= N: Name="HDA Intel PCH Headphone" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1f.3/sound/card0/input7 U: Uniq= H: Handlers=event7 B: PROP=0 B: EV=21 B: SW=4 I: Bus= Vendor= Product= Version= N: Name="HDA Intel PCH HDMI/DP,pcm=3" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1f.3/sound/card0/input8 U: Uniq= H: Handlers=event8 B: PROP=0 B: EV=21 B: SW=140 I: Bus=0003 Vendor=05ac Product=0304 Version=0110 N: Name="Primax Electronics Apple Optical USB Mouse" P: Phys=usb-:00:14.0-1/input0 S: Sysfs=/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.0/0003:05AC:0304.0004/input/input12 U: Uniq= H: Handlers=mouse0 event9 B: PROP=0 B: EV=100017 B: KEY=f 0 0 0 0 B: REL=143 B: MSC=10 kelley-rose@Zenbook:~$ ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: xorg 1:7.7+1ubuntu8.1 ProcVersionSignature: Ubuntu 3.19.0-59.65~14.04.1-generic 3.19.8-ckt19 Uname: Linux 3.19.0-59-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.14.1-0ubuntu3.19 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true Date: Sat May 14 22:17:15 2016 DistUpgraded: Fresh install DistroCodename: trusty DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation Sky Lake Integrated Graphics [8086:191e] (rev 07) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:1cfd] InstallationDate: Installed on 2016-05-14 (1 days ago) InstallationMedia: It Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bus 001 Device 002: ID 064e:9700 Suyin Corp. Asus Integrated Webcam Bus 001 Device 007: ID 05ac:0304 Apple, Inc. Mighty Mouse [Mitsumi, M1152] Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: ASUSTeK COMPUTER INC. UX305CA ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-59-generic root=UUID=531c23f0-3c1c-42cb-92bf-7e2fa2cbc7cc ro quiet splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/11/2015 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: UX305CA.201 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: UX305CA dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: ATN12345678901234567
[Desktop-packages] [Bug 1211479] Re: package slpd 1.2.1-9 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
** Also affects: openslp-dfsg (Unity Linux) Importance: Undecided Status: New ** Also affects: ubuntu-gnome Importance: Undecided Status: New ** No longer affects: openslp-dfsg (Unity Linux) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to openslp-dfsg in Ubuntu. https://bugs.launchpad.net/bugs/1211479 Title: package slpd 1.2.1-9 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 Status in Ubuntu GNOME: New Status in openslp-dfsg package in Ubuntu: New Bug description: Description: Ubuntu 13.04 Release: 13.04 ProblemType: Package DistroRelease: Ubuntu 13.04 Package: slpd 1.2.1-9 ProcVersionSignature: Ubuntu 3.8.0-27.40-generic 3.8.13.4 Uname: Linux 3.8.0-27-generic i686 ApportVersion: 2.9.2-0ubuntu8.3 Architecture: i386 Date: Mon Aug 12 14:11:35 2013 DuplicateSignature: package:slpd:1.2.1-9:subprocess installed post-installation script returned error exit status 1 ErrorMessage: subprocess installed post-installation script returned error exit status 1 InstallationDate: Installed on 2013-08-05 (6 days ago) InstallationMedia: Ubuntu 13.04 Raring Ringtail - Release i386 (20130424) MarkForUpload: True SourcePackage: openslp-dfsg Title: package slpd 1.2.1-9 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-gnome/+bug/1211479/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1394063] Re: [vivid regression] brightness keys aren't recognized
This also affects my MacBook Pro 11,1 with Retina Display running 15.04 (vivid). Brightness keys do not work. But command line /sys/class/backlight/intel_backlight/ does work for manual adjustment. Sean -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to unity-settings-daemon in Ubuntu. https://bugs.launchpad.net/bugs/1394063 Title: [vivid regression] brightness keys aren't recognized Status in “unity-settings-daemon” package in Ubuntu: Confirmed Bug description: Hardware keys on an inspirion 3137 for brightness don't work. Manually setting the backlight via /sys/class/backlight/intel_backlight/brightness works properly. This worked properly in utopic and has been broken since upgrade to vivid. Xev doesn't show a keypress event. Scan codes from evtest are shown below: Event: time 1416367751.898584, -- EV_SYN Event: time 1416367754.952917, type 4 (EV_MSC), code 4 (MSC_SCAN), value 85 Event: time 1416367754.952917, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 1 Event: time 1416367754.952917, -- EV_SYN Event: time 1416367754.952946, type 1 (EV_KEY), code 224 (KEY_BRIGHTNESSDOWN), value 0 Event: time 1416367754.952946, -- EV_SYN Event: time 1416367756.898936, type 4 (EV_MSC), code 4 (MSC_SCAN), value 86 Event: time 1416367756.898936, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 1 Event: time 1416367756.898936, -- EV_SYN Event: time 1416367756.898968, type 1 (EV_KEY), code 225 (KEY_BRIGHTNESSUP), value 0 ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: udev 215-5ubuntu2 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 ApportVersion: 2.14.7-0ubuntu10 Architecture: amd64 CurrentDesktop: Unity Date: Tue Nov 18 22:16:25 2014 InstallationDate: Installed on 2014-06-04 (167 days ago) InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Release amd64 (20140417) MachineType: Dell Inc. Inspiron 3137 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-24-generic.efi.signed root=UUID=0e352344-90e9-4cbe-acde-376a88cf5b47 ro quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: Upgraded to vivid on 2014-06-04 (167 days ago) dmi.bios.date: 12/25/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A05 dmi.board.name: 0PRDX0 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: 0.1 dmi.modalias: dmi:bvnDellInc.:bvrA05:bd12/25/2013:svnDellInc.:pnInspiron3137:pvr:rvnDellInc.:rn0PRDX0:rvrA00:cvnDellInc.:ct8:cvr0.1: dmi.product.name: Inspiron 3137 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1394063/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1392447] [NEW] apport starts even when not installed
Public bug reported: When removed (but not purged), apport leaves /etc/init/apport.conf and /etc/init.d/apport, which is enough for commands like service apport start to work. service apport start runs without complaining and overrides /proc/sys/kernel/core_pattern to send core dumps to apport, even though apport doesn't exist. Apport's service scripts should refuse to run if Apport isn't installed and, in particular, shouldn't break /proc/sys/kernel/core_pattern. Observed in Ubuntu 14.04.1, apport 2.14.1-0ubuntu3.5. ** Affects: apport (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1392447 Title: apport starts even when not installed Status in “apport” package in Ubuntu: New Bug description: When removed (but not purged), apport leaves /etc/init/apport.conf and /etc/init.d/apport, which is enough for commands like service apport start to work. service apport start runs without complaining and overrides /proc/sys/kernel/core_pattern to send core dumps to apport, even though apport doesn't exist. Apport's service scripts should refuse to run if Apport isn't installed and, in particular, shouldn't break /proc/sys/kernel/core_pattern. Observed in Ubuntu 14.04.1, apport 2.14.1-0ubuntu3.5. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1392447/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1327477] Re: dnsmasq not using all DHCPv6 provided nameservers
I think the following, much simpler, patch should solve the problem.
Simon.
diff --git a/src/dbus.c b/src/dbus.c
index 93c597c..4696442 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -156,13 +156,16 @@ static void dbus_read_servers(DBusMessage *message)
dbus_message_iter_get_basic(iter, p[i]);
dbus_message_iter_next (iter);
if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_BYTE)
- break;
+ {
+ i++;
+ break;
+ }
}
#ifndef HAVE_IPV6
my_syslog(LOG_WARNING, _(attempt to set an IPv6 server address via
DBus - no IPv6 support));
#else
- if (i == sizeof(struct in6_addr)-1)
+ if (i == sizeof(struct in6_addr))
{
memcpy(addr.in6.sin6_addr, p, sizeof(struct in6_addr));
#ifdef HAVE_SOCKADDR_SA_LEN
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1327477
Title:
dnsmasq not using all DHCPv6 provided nameservers
Status in “dnsmasq” package in Ubuntu:
Confirmed
Status in “network-manager” package in Ubuntu:
Invalid
Bug description:
When receiving nameservers from a DHCPv6 server, NetworkManager
reports receiving both my primary and secondary servers, but only
advises dnsmasq about the secondary.
Jun 6 13:59:29 daedalus dhclient: XMT: Info-Request on eth0, interval 910ms.
Jun 6 13:59:29 daedalus dhclient: RCV: Reply message on eth0 from
fe80::221:85ff:fe10:7749.
Jun 6 13:59:29 daedalus NetworkManager[22306]: info (eth0): DHCPv6 state
changed nbi - renew6
Jun 6 13:59:29 daedalus NetworkManager[22306]: info nameserver
'2001:470:8:64f::4'
Jun 6 13:59:29 daedalus NetworkManager[22306]: info nameserver
'2001:470:8:64f:21b:fcff:fe43:bcff'
Jun 6 13:59:29 daedalus NetworkManager[22306]: info domain search
'home.nivex.net.'
Jun 6 13:59:29 daedalus NetworkManager[22306]: info Activation (eth0)
Stage 5 of 5 (IPv6 Commit) scheduled...
Jun 6 13:59:29 daedalus NetworkManager[22306]: info (eth0): DHCPv6 client
pid 22638 exited with status 0
Jun 6 13:59:29 daedalus NetworkManager[22306]: info Activation (eth0)
Stage 5 of 5 (IPv6 Commit) started...
Jun 6 13:59:29 daedalus avahi-daemon[991]: Registering new address record
for 2001:470:8:64f:dcf5:dd0f:11f5:b6ed on eth0.*.
Jun 6 13:59:30 daedalus NetworkManager[22306]: info (eth0): device state
change: ip-config - secondaries (reason 'none') [70 90 0]
Jun 6 13:59:30 daedalus NetworkManager[22306]: info Activation (eth0)
Stage 5 of 5 (IPv6 Commit) complete.
Jun 6 13:59:30 daedalus NetworkManager[22306]: info (eth0): device state
change: secondaries - activated (reason 'none') [90 100 0]
Jun 6 13:59:30 daedalus NetworkManager[22306]: info NetworkManager state
is now CONNECTED_GLOBAL
Jun 6 13:59:30 daedalus NetworkManager[22306]: info Policy set 'Ethernet
connection 1' (eth0) as default for IPv6 routing and DNS.
Jun 6 13:59:30 daedalus NetworkManager[22306]: info Writing DNS
information to /sbin/resolvconf
Jun 6 13:59:30 daedalus dnsmasq[22603]: setting upstream servers from DBus
Jun 6 13:59:30 daedalus dnsmasq[22603]: using nameserver
2001:470:8:64f:21b:fcff:fe43:bcff#53
Jun 6 13:59:30 daedalus NetworkManager[22306]: info Activation (eth0)
successful, device activated.
I noticed this during the Turn IPv4 Off Day
(http://www.internetsociety.org/deploy360/blog/2013/12/campaign-turn-
off-ipv4-on-6-june-2014-for-one-day/) shakedown because my secondary
was not configured to recurse over IPv6, resulting in an inability to
resolve anything.
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: network-manager 0.9.8.8-0ubuntu7
ProcVersionSignature: Ubuntu 3.13.0-27.50-generic 3.13.11
Uname: Linux 3.13.0-27-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: XFCE
Date: Fri Jun 6 23:18:49 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2011-12-09 (910 days ago)
InstallationMedia: Xubuntu 11.10 Oneiric Ocelot - Release amd64 (20111012)
IpRoute:
default via 172.31.3.1 dev eth0 proto static
172.31.3.0/24 dev eth0 proto kernel scope link src 172.31.3.11 metric 1
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=true
WimaxEnabled=true
RfKill:
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
SourcePackage: network-manager
UpgradeStatus: Upgraded to trusty on 2014-04-20 (47 days ago)
nmcli-dev:
DEVICE TYPE STATE DBUS-PATH
wlan0 802-11-wireless unavailable
/org/freedesktop/NetworkManager/Devices/1
eth0 802-3-ethernetconnected
/org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
RUNNING VERSIONSTATE NET-ENABLED
Re: [Desktop-packages] [Bug 1218322] Re: Can't set keyboard layout change to alt+shift, ctrl+shift, etc.
I am completely locked out of typing anything on my laptop Dell D620 4gb ram 1.66ghz dual core intel processor 500 gb hitachi 7200 rpm hd. I am at a point to where I think I need to pull my docs/music to another partition and reformat the GNOME partition. What is most frustrating about this is I just got my system set up perfect and of course this happens to be betta and then I get this. Any suggestions are very much appreciated. On Wednesday, November 20, 2013, Krisztian Poos 1218...@bugs.launchpad.net wrote: Unfortunately neither the old ppa, ppa:attente/1218322 nor the new , the modifier-only-input-switch fixes the issue on my laptop. I tried to use also gsettings, I can finally map the keybindigs to ctrl-shift with the gsettings set org.gnome.desktop.wm.keybindings switch-input-source ['PrimaryShift_L'], however I still can use the Alt+Shift_L combo to change the keyboard. It changes the keyboard notifier in the panel, however I still type english keys instead of hungarian. I run ubuntu 13.10 on a Thinkpad T500, I use gnome shell. I also tried to upgrade my gnome to 3.10, however the problem remained after the upgrade as well, so I reverted these changes and went back to the 3.8. Do you have any idea what else should I try to get back for the long- ago-used Alt+Shift shortcut? I am happily providing any needed information for investigation as well. Thanks and regards, Krisztian -- You received this bug notification because you are subscribed to Ubuntu GNOME. Matching subscriptions: kelley.castlebe...@gmail.com https://bugs.launchpad.net/bugs/1218322 Title: Can't set keyboard layout change to alt+shift, ctrl+shift, etc. Status in Gnome Settings Daemon: Invalid Status in Ubuntu GNOME: Confirmed Status in “gnome-control-center” package in Ubuntu: Fix Released Status in “gnome-settings-daemon” package in Ubuntu: Triaged Status in “gnome-settings-daemon” source package in Saucy: Triaged Status in “gnome-control-center” package in ALT Linux: Unknown Status in “gnome-control-center” package in Gentoo Linux: Unknown Status in “gnome-control-center” package in Mandriva: Confirmed Bug description: *** The old PPA, ppa:attente/1218322 is superceded by the following one. You can remove the old repository using ppa-purge. *** A PPA which should provide some relief for this issue is available at https://launchpad.net/~attente/+archive/modifier-only-input-switch. To install: sudo add-apt-repository ppa:attente/modifier-only-input-switch sudo apt-get update sudo apt-get upgrade (log out, log in) If the packages improve the situation for you, you can pin them using: sudo apt-mark hold compiz sudo apt-mark hold gnome-settings-daemon sudo apt-mark hold unity If the packages don't work for you, you can purge them using: sudo ppa-purge ppa:attente/modifier-only-input-switch === compiz === Impact: modifier-only key bindings need to be independent of key-press order, there's no support for double tapping two modifier keys of the same type Test case: - add at least two input sources through gnome-control-center's text entry settings - use gsettings to set the input switching shortcut to ctrl+left shift: gsettings set org.gnome.desktop.wm.keybindings switch-input-source ['PrimaryShift_L'] - holding left shift, press and release ctrl - the current input source should change Regression potential: possible, but highly unlikely, that some key bindings may be triggered due to the removal of some code that would normally prevent a possible tap from occurring. === unity === Impact: gnome-settings-daemon eats modifier-only shortcuts preventing them from propagating down to applications Test case: - open gnome-control-center's text input settings - set the next input source key binding to ctrl+left shift - open gnome-terminal - press ctrl+shift+t - gnome-terminal should open a new tab Regression potential: the additional input switch key bindings could collide with other functionality such as opening the dash or hud === gnome-control-center === Impact: the UI to change the layout switching keys doesn't work Test case: -- Kelley Scott Castleberry | Founder | Senior Business Consultant Serving So. California via Oceanside, CA 92057 and Los Angeles CA 90010 Serving Nationwide via Teleconference communications LA 323-639-0706 SD 619-665-1710 Email: kelley.castlebe...@gmail.com -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-control-center in Ubuntu. https://bugs.launchpad.net/bugs/1218322 Title: Can't set keyboard layout change to alt+shift, ctrl+shift, etc. Status in Gnome Settings Daemon: Invalid Status in Ubuntu GNOME: Confirmed Status in “gnome-control-center” package in Ubuntu: Fix Released Status in “gnome-settings-daemon” package
[Desktop-packages] [Bug 1225557] Re: gives bogus values
In my opinion this module should be pulled in favor of
https://github.com/jiixyj/libebur128
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreplaygain in Ubuntu.
https://bugs.launchpad.net/bugs/1225557
Title:
gives bogus values
Status in “libreplaygain” package in Ubuntu:
New
Bug description:
Here's an example file: http://superjoe.s3.amazonaws.com/temp/test-
rg.mp3
When I run the mp3gain cli tool on it, I get this:
Recommended Track dB change: -0.73
Recommended Track mp3 gain change: 0
Max PCM sample at current gain: 7739.570901
Max mp3 global gain field: 150
Min mp3 global gain field: 128
Seems reasonable.
But when I use my own program to feed data into libreplaygain I get
bogus results. I looked into this further and created a simple test
case that fails.
Here's the test file, converted to 44100 Hz, mono, 64-bit float raw file:
http://superjoe.s3.amazonaws.com/temp/test-rg-44100-64bit-mono.raw
Here's some C code relying on libreplaygain to parse the file:
#include stdio.h
#include replaygain/gain_analysis.h
int main (int argc, char **argv)
{
FILE *file = fopen(argv[1], rb);
double buf[5];
size_t bytes_read = fread(buf, 1, 40, file);
gain_init_analysis(44100);
gain_analyze_samples(buf, NULL, bytes_read / 8, 1);
fclose(file);
printf(analyzed %lu samples\n, bytes_read / 8);
printf(track gain: %f\n, gain_get_title());
}
When I run this, I see:
analyzed 47232 samples
track gain: 0.00
Am I missing something? Is there anywhere that a working replaygain example
exists, perhaps a bit simpler than the source to mp3gain?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libreplaygain/+bug/1225557/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1225557] [NEW] gives bogus values
Public bug reported:
Here's an example file: http://superjoe.s3.amazonaws.com/temp/test-
rg.mp3
When I run the mp3gain cli tool on it, I get this:
Recommended Track dB change: -0.73
Recommended Track mp3 gain change: 0
Max PCM sample at current gain: 7739.570901
Max mp3 global gain field: 150
Min mp3 global gain field: 128
Seems reasonable.
But when I use my own program to feed data into libreplaygain I get
bogus results. I looked into this further and created a simple test case
that fails.
Here's the test file, converted to 44100 Hz, mono, 64-bit float raw file:
http://superjoe.s3.amazonaws.com/temp/test-rg-44100-64bit-mono.raw
Here's some C code relying on libreplaygain to parse the file:
#include stdio.h
#include replaygain/gain_analysis.h
int main (int argc, char **argv)
{
FILE *file = fopen(argv[1], rb);
double buf[5];
size_t bytes_read = fread(buf, 1, 40, file);
gain_init_analysis(44100);
gain_analyze_samples(buf, NULL, bytes_read / 8, 1);
fclose(file);
printf(analyzed %lu samples\n, bytes_read / 8);
printf(track gain: %f\n, gain_get_title());
}
When I run this, I see:
analyzed 47232 samples
track gain: 0.00
Am I missing something? Is there anywhere that a working replaygain example
exists, perhaps a bit simpler than the source to mp3gain?
** Affects: libreplaygain (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreplaygain in Ubuntu.
https://bugs.launchpad.net/bugs/1225557
Title:
gives bogus values
Status in “libreplaygain” package in Ubuntu:
New
Bug description:
Here's an example file: http://superjoe.s3.amazonaws.com/temp/test-
rg.mp3
When I run the mp3gain cli tool on it, I get this:
Recommended Track dB change: -0.73
Recommended Track mp3 gain change: 0
Max PCM sample at current gain: 7739.570901
Max mp3 global gain field: 150
Min mp3 global gain field: 128
Seems reasonable.
But when I use my own program to feed data into libreplaygain I get
bogus results. I looked into this further and created a simple test
case that fails.
Here's the test file, converted to 44100 Hz, mono, 64-bit float raw file:
http://superjoe.s3.amazonaws.com/temp/test-rg-44100-64bit-mono.raw
Here's some C code relying on libreplaygain to parse the file:
#include stdio.h
#include replaygain/gain_analysis.h
int main (int argc, char **argv)
{
FILE *file = fopen(argv[1], rb);
double buf[5];
size_t bytes_read = fread(buf, 1, 40, file);
gain_init_analysis(44100);
gain_analyze_samples(buf, NULL, bytes_read / 8, 1);
fclose(file);
printf(analyzed %lu samples\n, bytes_read / 8);
printf(track gain: %f\n, gain_get_title());
}
When I run this, I see:
analyzed 47232 samples
track gain: 0.00
Am I missing something? Is there anywhere that a working replaygain example
exists, perhaps a bit simpler than the source to mp3gain?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libreplaygain/+bug/1225557/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On 06/02/13 09:18, Thomas Hood wrote: [...cont'd after in order to fix...] bug #1072899, dnsmasq will have to be enhanced such that proposition #1 is true. But we can discuss the details of that in bug #1072899. parenthesis There is a close analogy between the problem here (bug #1003842) and a problem we have with avahi. Avahi resolves names in the domain .local. Networks should not use this TLD, but many do and at least in the past Microsoft actually recommended doing so. When users connect to such networks with avahi enabled the result is malfunction. Upstream purisitically says[*] If you come across a network where .local is a unicast DNS domain, please contact the local administrator and ask him to move his DNS zone to a different domain. If this is not possible, we recommend not to use Avahi in such a network at all. In practice avahi attempts to detect bad networks and disables itself if it thinks it is on a bad network, subject unfortunately both to false positives (bug #327362) and false negatives (bug #80900). We aren't yet doing even that well. We say that networks ought to have equivalent nameservers and we make no attempt to detect networks that have non-equivalent nameservers, of which there are very many. [*]http://avahi.org/wiki/AvahiAndUnicastDotLocal /parenthesis Detect non-equivalent servers is hard. I'm very much in favour of doing it, if a way can be found. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On 06/02/13 08:59, Thomas Hood wrote: Hi Simon. Before I forget to ask: can you please update dnsmasq(8) to include under --strict-order a description of what happens when nameserver addresses are passed in via D-Bus instead of via a file? You wrote, you can very easily provide the same behaviour - only pass the first nameserver to dnsmasq Because NM doesn't use dnsmasq to cache, if NM were to give dnsmasq only one address then I guess the only service that dnsmasq would still provide is that of name-to-server mapping. And it turns out that the way NM currently uses dnsmasq to do this is seriously flawed. So I conclude that it's better for NM not to use dnsmasq at all until these problems are solved. [That NM only supplies one nameserver address per domain name] is a different problem, and could be solved. From the man page it's not completely clear how to solve it. Can you confirm (1) that it's possible to give multiple server options as follows server=/google.com/1.2.3.4 server=/google.com/5.6.7.8 and that the result will be that 1.2.3.4 and 5.6.7.8 will be treated equally for the purpose of resolving names in domain google.com? (2) And likewise via D-Bus? (3) What effect does strict-order have on this? Ironically, I think the problem arises because for nameservers associated with particular domains, the equivalent of --strict-order is always in play. What you say here suggests that my proposition #1 above is false. If #1 is false then it seems that in order to fix proposition #1 is true, as is #2: you can configure the same thing via DBus. Consider server=1.1.1.1 server=2.2.2.2 server=/google.com/3.3.3.3 server=/google.com/4.4.4.4 Queries not sent to *.google.com will behave in the normal dnsmasq manner, sent non-deterministically to 1.1.1.1 and/or 2.2.2.2 in a way which tries to favour the fastest/most up server. Queries sent to *google.com will be sent 3.3.3.3 or 4.4.4.4 in the same way as if strict order was set, ie, to 3.3.3.3 first, and only to 4.4.4.4 if 3.3.3.3 returns a SERVFAIL or REFUSED error, or doesn't reply at all. This should be changed, but the code which implements it is knarly and old, and won't stand more tinkering, it needs rewriting. I've not found the time, as of yet. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
Belay my previous comment about 1072899, it looks like network manager is losing the second server before it ever gets to dnsmasq. Not a dnsmasq problem. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On 04/02/13 22:05, Thomas Hood wrote: Simon in #49: It doesn't work [...] the order of servers given to the DBus interface isn't preserved internally Aha, so the answer to my question Will switching on strict-order have the same effect now that nameserver addresses are sent over D-Bus? (in comment #42) is No. So switching strict-order back on is no solution. And solutions depending on strict-order including mine in #28 also won't work. Unless dnsmasq is somehow changed such that it remembers the order in which nameserver addresses come in over D-Bus so that strict-order is useful in the D-Bus case, if we want to avoid breaking name service on machines connected to NNNs then we have to disable dnsmasq by default; or disable it initially and only enable it when we know that we aren't on a NNN. Note that setting --strict-order is pretty much equivalent to telling dnsmasq to use only the first nameserver, so you can very easily provide the same behaviour - only pass the first nameserver to dnsmasq. Maybe provide a button in NM that does this - press here if you're in a captive portal. (NNN = nonequivalent-nameserver network. As discussed in comment #5, such networks are not properly configured. But as observed several times, there are many NNNs out there. Which is why *many* people have been commenting out dns=dnsmasq.) There is another problem with NM-dnsmasq (bug #1072899). Some VPNs have multiple nameservers. NM uses dnsmasq to direct VPN domain name queries to the *first* one. But then, if the first one goes down, the second one is not tried. Once again, for the sake of speed enhancement in the favorable case, users suffer radical name service failure in the unfavorable case. This is not a good deal, IMHO. NM-dnsmasq should be disabled by default until these problems are solved. That's a different problem, and could be solved. Ironically, I think the problem arises because for nameservers associated with particular domains, the equivalent of --strict-order is always in play. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On 03/02/13 07:48, Thomas Hood wrote: there's still the unresolved question of whether re-enabling --strict-order will suffice as a workaround, since 12.10 relies on DBus to populate the nameservers. Is there any extra information on this? Please try it and report back. :-) (Put strict-order in a file in /etc/NetworkManager/dnsmasq.d/; stop network-manager; make sure all dnsmasq processes are dead; start network-manager.) It doesn't work: It will always use the same server first, but the order of servers given to the DBus interface isn't preserved internally, and actually changes each time the DBus interface is used. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: dnsmasq sometimes fails to resolve private names in networks with non-equivalent nameservers
On 04/02/13 15:36, Sergio Callegari wrote: On 04/02/2013 15:40, Simon Kelley wrote: On 03/02/13 07:48, Thomas Hood wrote: there's still the unresolved question of whether re-enabling --strict-order will suffice as a workaround, since 12.10 relies on DBus to populate the nameservers. Is there any extra information on this? Please try it and report back. :-) (Put strict-order in a file in /etc/NetworkManager/dnsmasq.d/; stop network-manager; make sure all dnsmasq processes are dead; start network-manager.) It doesn't work: It will always use the same server first, but the order of servers given to the DBus interface isn't preserved internally, and actually changes each time the DBus interface is used. Cheers, Simon. Isn't it possible to change dnsmasq behavior to query the servers in any order or in parallel and in the case the first server to reply says I don't know avoid relying on that information, rather wait and see if in a reasonable time some other server answers I do? You're far from the first person to ask that question. The answer is that there is no possible response in the DNS protocol which means I don't know. NXDOMAIN or NODATA answers _don't_ mean that; they mean I know that this domain doesn't exist. They also make up quite a large proportion of the DNS results returned to the average host, so that all of those queries would suddenly take much longer. With the current behavior, whenever I need to access a captive portal, I basically have to press the reload page button 50 times until for some reasons the order in which the nameservers reply becomes the good one. The fundamental problem lies with the captive portal, and no good solution which can be implemented by dnsmasq has so far been devised. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: In Progress Status in “dnsmasq” source package in Precise: Confirmed Status in “network-manager” source package in Precise: Triaged Status in “dnsmasq” package in Debian: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 991308] Re: DNS Querying fails if any DNS server is unreachable
Simon, do you think that dnsmasq could misbehave as described here? The only way I can see for this to occur is if a DNS server is return wrong (ie NXDOMAIN or NODATA) answers, no answer shouldn't be a problem. I suggest adding --log-queries to the dnsmasq configuration to try and get a handle on what's happening. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/991308 Title: DNS Querying fails if any DNS server is unreachable Status in “dnsmasq” package in Ubuntu: New Status in “network-manager” package in Ubuntu: Incomplete Bug description: Release: 12.04 Hardware: HP Compaq 6910p Laptop If the backup DNS server is unreachable, dnsmasq does not try to reach primary DNS server. In the following default configuration (clean install of 12.04) 1 out of 4 DNS queries fail. (DNSMasq seems to rotate queries between the listed servers) wlightning@archon:~$ cat /run/nm-dns-dnsmasq.conf server=75.75.75.75 server=75.75.76.76 wlightning@archon:~$ wlightning@archon:~$ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search hsd1.or.comcast.net wlightning@archon:~$ wlightning@archon:~$ nm-tool NetworkManager Tool State: connected (global) - Device: ttyUSB0 -- Type: Mobile Broadband (CDMA) Driver:sierra State: disconnected Default: no Capabilities: - Device: wlan0 Type: 802.11 WiFi Driver:iwl4965 State: unavailable Default: no HW Address:00:1D:E0:35:69:AF Capabilities: Wireless Properties WEP Encryption: yes WPA Encryption: yes WPA2 Encryption: yes Wireless Access Points - Device: eth0 [Wired connection 1] --- Type: Wired Driver:e1000e State: connected Default: yes HW Address:00:1B:38:E7:F5:02 Capabilities: Carrier Detect: yes Speed: 1000 Mb/s Wired Properties Carrier: on IPv4 Settings: Address: 10.0.0.11 Prefix: 24 (255.255.255.0) Gateway: 10.0.0.1 DNS: 75.75.75.75 DNS: 75.75.76.76 wlightning@archon:~$ mtr of 75.75.75.75 (anycast addr): My traceroute [v0.80] archon (0.0.0.0) Sun Apr 29 10:13:58 2012 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings HostLoss% Snt Last Avg Best Wrst StDev 1. 10.0.0.1 0.0%510.6 0.6 0.6 1.5 0.2 2. 73.94.124.1 0.0%519.0 9.2 7.1 14.7 1.5 3. 68.85.148.1 0.0%517.9 10.6 7.4 24.7 4.0 4. 68.87.216.13 0.0%519.2 19.8 8.5 150.8 29.0 5. 68.87.218.162 0.0%50 10.8 14.1 8.1 85.0 13.4 68.87.218.158 6. 68.87.216.41 0.0%509.5 13.2 9.5 67.4 8.6 7. 75.75.75.75 0.0%509.9 11.0 9.1 17.2 1.8 mtr of 75.75.76.76 (anycast addr): My traceroute [v0.80] archon (0.0.0.0) Sun Apr 29 10:12:42 2012 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings HostLoss% Snt Last Avg Best Wrst StDev 1. 10.0.0.1 0.0%510.6 0.8 0.5 3.6 0.5 2. 73.94.124.1 0.0%519.0 9.3 7.0 18.3 2.5 3. 68.85.148.9 0.0%517.3 9.6 7.2 22.3 2.9 4. 68.85.243.253 0.0%518.3 13.8 7.5 81.9 15.6 5. 68.86.95.97 0.0%51 14.5 17.2 11.9 33.0 4.4 68.86.91.197 68.86.90.213 68.86.95.93
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 20/06/12 10:56, Thomas Hood wrote: I can imagine that it will take a lot of care to avoid introducing races inside dnsmasq. It's OK: notification of new interfaces comes via netlink, so it gets synchronised via the select() call just like everything else. Have I mentioned yet that Simon is a hero? :-) New code is in git (and I released 2.63test1) change --bind-interfaces to --bind-dynamic as see how it goes. Do we have to worry about races outside of dnsmasq? Suppose someone was running dnsmasq in unbound mode and has now switched to the new improved dnsmasq in bind-interfaces-dynamically mode. Now an interface comes up but there is a delay before dnsmasq notices this and starts listening on it. Problem? Because it's using netlink rather than polling, the delay is pretty short (I know that's not a solution to races, but it does help.) Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 18/06/12 21:08, Thomas Hood wrote: @Simon: This is pretty much what I had in mind (comment #88) as a long- term solution. How difficult do you think that this would be? Don't know. I'm working on it now: seems to be behaving: dnsmasq: new IPv4: 192.168.3.1 dnsmasq: new IPv6: fe80::f0f6:48ff:fe15:70b0 (Moving nm-dnsmasq listening to another port than 53 is at best a veeery long-term solution since it requires first getting glibc enhanced, then getting all other resolver libraries enhanced, then waiting for third- party static binaries to be replaced by new versions built against enhanced libraries. That's a ten-year project.) If bind-interfaces-dynamically works well then I see no reason why it shouldn't be the default mode of operation. Indeed, I see no reason why it shouldn't be the *only* mode on OSs with support for it. I see reasons: I've been burned by releasing changes that won;t affect anything too many times, I like the idea of making the new behaviour opt-in. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 15/06/12 10:19, Thomas Hood wrote: $ cat /run/nm-dns-dnsmasq.conf server=/17.172.in-addr.arpa/172.17.1.2 server=192.168.1.254 server=... The first server= line reflects the fact that I am connected to a VPN. This can't be expressed in resolv.conf syntax. FYI only, It's possible to use the dnsmasq DBus interface to set servers/domains with full generality and without restarting dnsmasq. Simon. No doubt dnsmasq could be enhanced to poll its configuration files. But it remains a question whether it's advisable for NM to make use of the standalone dnsmasq for the purposes for which nm-dnsmasq was introduced. Effectively this revisits the discussion that led to the introduction of nm-dnsmasq in the first place. Part of that discussion (which I wasn't party to) can be read here: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 15/06/12 08:04, Thomas Hood wrote: Alkis: This relies on the assumption that NM's configuration text can be dropped in alongside whatever other configuration text is present and that dnsmasq will still work properly. This assumption is, er, questionable. There was an attempt, some time ago, to provide a way to allow something like libvirt to add its DHCP configuration to a system dnsmasq configuration without interfering with the existing config. It's basically a way to specify an interface and subnet for DHCP in a config line which overrides other access control, so for instance if the system dnsmasq config limits it to certain interfaces, then the interface specified by libvirt would be added to that set. To my knowledge this facility has never actually been used. And this is also one answer to my question in #72. The dnsmasq cascade may waste resources but it has maintenance advantages. One dnsmasq process is under the control of NM. The other is under the control of the admin. They communicate with each other via a well defined protocol, RFC 1035. This is a good argument, I think. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 15/06/12 15:01, Thomas Hood wrote: -- Solvable by moving nm-dnsmasq to another port: There's one more snippet after this dealing with the IPv6 case. That should be it. Any obvious problems I'm overlooking? Applications that don't use the libc resolver? I don't know if such exist be they might do. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
On 14/06/12 16:06, Thomas Hood wrote: @Alkis: IIUC dnsmasq in bind-interfaces mode will not start to listen on any addresses assigned to interfaces after dnsmasq has started. So, yes, she would have to restart standalone dnsmasq if she wants it to listen on those newly assigned addresses. That's correct. The chief advantage of listening on the wildcard address is that it all works as interfaces come and go. You lose that with --bind-interfaces. It would be possible these days to have dnsmasq detect extra interfaces and bind to their addresses automatically, but the code to do that isn't portable. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 13/06/12 11:07, Thomas Hood wrote: OK, so the ::1 idea fails as a quick hack. The alternatives seem to be as follows. 1. Either we accept that nm-dnsmasq is incompatible with every standalone nameserver and enforce this in a better way; 2. or we force every standalone nameserver into bind-interfaces mode and move nm-dnsmasq's listen address to something other than 127.0.0.1; 3. or we make nm-dnsmasq listen on another port number (using the --port option) and enhance glibc to support accessing nameservers at ports other than 53. Have I forgotten any? #3 is the most attractive option but requires the most work and won't happen soon. In the short term the choice is between #1 and #2. For completeness, there's a #4 which is to dump bind-interfaces except-interface=lo into /etc/dnsmasq.d, but that won't work for other nameservers (though something analogous would, I expect) If you can make #2 happen without breaking things, that would seem to be worth doing, I guess the main problem is that you need dnsmasq 2.61 or a backport of the relevant code to 2.59. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 13/06/12 11:07, Thomas Hood wrote: OK, so the ::1 idea fails as a quick hack. The alternatives seem to be as follows. 1. Either we accept that nm-dnsmasq is incompatible with every standalone nameserver and enforce this in a better way; 2. or we force every standalone nameserver into bind-interfaces mode and move nm-dnsmasq's listen address to something other than 127.0.0.1; 3. or we make nm-dnsmasq listen on another port number (using the --port option) and enhance glibc to support accessing nameservers at ports other than 53. Have I forgotten any? #3 is the most attractive option but requires the most work and won't happen soon. In the short term the choice is between #1 and #2. Further to #2 and getting dnsmasq support. I found a bug last night that means that dnsmasq --listen-address=ip addr where ip addr is not on an interface, will listen on port 69 of ip addr even if tftp is not enabled. The fix is in git but not a release, but should be backported if you do #2. It's trivial: one line. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 12/06/12 10:05, Alkis Georgopoulos wrote: Note that while bind-interfaces can be specified multiple times, defining except-interfaces more than once is a syntax error in my dnsmasq 2.59-4. Are you sure? That should be allowed. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 12/06/12 11:24, Thomas Hood wrote: Hmm, just tested this myself. You can't use except-interface=lo; it seems you have to use listen-address=10.1.2.3. Perhaps Simon knows a better way. If you want to listen on an address which doesn't appear on an interface (ie 127.0.1.1) then you have to use --listen-address. The rules for 127.0.0.1 are slightly arcane too: If you use -interface and --except-interface, then dnsmasq will assume that you want it to listen on the address of any loopback interfaces it finds as well. In practise that means 127.0.0.1 So dnsmasq --interface=eth0 will listen on the address(es) of eth0 and 127.0.0.1. If you use --listen-address, then dnsmasq assumes you want more control and only uses the addresses you actually give so dnsmasq --listen-address=127.0.1.1 will _not_ listen on 127.0.0.1 Given this, it makes sense to use 127.0.1.1 (or any address in 127.0.0.0/8 that doesn't appear on lo) for nm-dnsmasq. Because 127.0.1.1 doesn't appear on lo, another dnsmasq instance will not try and listen on it, and the only thing required to get the two dnsmasq instances to co-exist is --bind-interfaces. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 12/06/12 20:31, Thomas Hood wrote: (Executive summary of the following: I think we should fix this by making nm-dnsmasq listen at ::1.) Thanks for your much-needed help, Simon. It is good to know that the except-interface avenue is available. We want, however, to be able to enjoy the advantages of non-bind-interfaces mode (unbound mode??) in standalone dnsmasq insofar as we can. Certainly standalone dnsmasq should continue to run in unbound mode when n-m is not installed or when nm-dnsmasq is not in use; so ideally we would ensure that /etc/NetworkManager/NetworkManager.conf contains dns=dnsmasq if and only if /etc/dnsmasq.d/nm-dnsmasq contains bind- interfaces except-interface=lo. I don't see a very easy way to ensure this. In any case it would be better if we never had to force dnsmasq into bind-interfaces mode. So instead of switching the nm-dnsmasq listen address from 127.0.0.1 to 127.0.1.1 it seems better to switch that address to ::1: no more difficult, yet in the latter case standalone dnsmasq can continue to run in unbound mode as it has traditionally done (unless forced into bind- interfaces mode by something like libvirt-bin, of course). I don't think that's true. In unbound mode, the standalone dnsmasq will bind the IPv6 wildcard address, which will stop the nm-dnsmasq from binding ::1 There's no escape in IPv6 land. Indeed the situation is worse, because as far a I know, you can't use any address in the defined subnet for loopback, it has to be ::1, so except-interface=lo is required. I think the 127.0.1.1 (or whatever) answer is the best. Unfortunately there's no way round having to set --bind-interfaces on the standalone dnsmasq, but except-interface=lo is not required as long as the 127.0.0.0/8 address in use by nm-dnsmasq doesn't appear on the lo interface. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 11/06/12 19:57, Thomas Hood wrote: But, second, there is a problem connecting the resolver to the NM- controlled dnsmasq such that the latter stays out of the way of the general local nameserver which currently wants to listen on the IPv4 wildcard address. Using address ::1 for nm-dnsmasq is a quick hack which might work without further ado But even if it works it clearly isn't a permanent solution. More satisfactory would be to use an another port than 53 for the special purpose of connecting the resolver with nm-dnsmasq. Another option is to use another address in 127.0.0.0/8, any will work. You'll need dnsmasq 2.61 or later for this to be a viable option. You could have the nm-dnsmasq run with --bind-interfaces --listen-address=127.0.100.1 and put 127.0.100.1 in /etc/resolv.conf. Another instance of dnsmasq will run without interfering with that, providing only that --bind-interfaces is set. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 11/06/12 20:41, Thomas Hood wrote: Aha, I had tried this and it didn't work... in version 2.57. But I see that quantal already has 2.62. Another instance of dnsmasq will run without interfering with that, providing only that --bind-interfaces is set. Just to make sure I understand correctly: Do you mean here that --bind- interfaces has to be set on both instances of dnsmasq? Or will one instance (the NM-controlled one) with --bind-interfaces coexist nicely with another (the standalone dnsmasq) which doesn't use that option and listens on 0.0.0.0? It has to be set in both instances of dnsmasq. dnsmasq started as a system daemon reads config from /etc/dnsmasq.d/* so dropping a file there containing bind-interfaces and doing the relevant restart in postinst should make this automatic in most cases. NM already runs dnsmasq with --bind-interfaces and --listen-address (specifically, --listen-address=127.0.0.1) so we would only be changing the address. Mathieu mentioned earlier the possibility of using 127.0.1.1 which happens to be the address assigned (in /etc/hosts) to the system hostname on some (but not all) systems. Is there any advantage to using 127.0.1.1 as opposed to another 127.* address? I don't think so: they're all equivalent. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1003842] Re: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers
On 31/05/12 08:47, Thomas Hood wrote: In addition to devising an algorithm for dnsmasq to detect all and only NNNs, the implementation of which will no doubt take a while, we should consider implementing a quick fix too, along the lines suggested by Sergio in #19. NM could be changed to do the following. If the nameserver address list to be fed to dnsmasq contains one or more local addresses followed by one or more non-local addresses then run dnsmasq with the --strict-order option. I must confess that I am not sure what exactly should fall under local addresses here. In IPv4 I presume that these would be the familiar ranges 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, but what about IPv6? I think you're right for IPv4. For IPv6, I'm tempted to treat it as a tabula rasa and explicitly not support NNNs. the rationale being that NNN support is to work around historical bad practice and such bad practice is not supported in the brave new world of IPv6. If that won't fly, then the IPv6 equivalent would be link-local (fe80::/64), site-local (fec0::/10) and ULAs (block fc00::/7), I think. Nevertheless, I think we can safely proceed with this fix without being sure that we have exactly the right definition of local address since dnsmasq works no worse than libc in strict-order mode. ** Also affects: dnsmasq (Ubuntu) Importance: Undecided Status: New ** Also affects: resolvconf (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: dnsmasq sometimes fails to resolve private names in networks with non- equivalent nameservers Status in “dnsmasq” package in Ubuntu: New Status in “network-manager” package in Ubuntu: Confirmed Status in “resolvconf” package in Ubuntu: New Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1003842] Re: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers
Simon, your suggestion (call it #18) differs from the suggestion in #17 in two ways. First, #18 sends the first-received reply back to the client without waiting for the results of comparison with other results whereas #17 does wait. Second, #18 switches to strict-order mode when *any* difference is found, whereas #17 proposed only looking for a particular pattern, that being: a NODATA/NXDOMAIN is received from a nameserver that is not listed first and an earlier-listed nameserver does return an address within the standard libc timeout period. In #17's defence... in #17 the client only has to wait for a reply in the case of a NODATA/NXDOMAIN from a non-first nameserver; the client does get the desired address from the earlier-listed nameserver if there is one --- even the first time; and dnsmasq only drops into strict-order mode under the circumstances when it is necessary for it to do so such that clients get needed addresses. There is no point, for example, in dropping into strict-order mode if it's the first nameserver returning NXDOMAIN and a later-listed nameserver returning an address! What do you think about the possibility of implementing such ideas? I think that both are implementable. I worry that #17 will make (real) NXDOMAIN/NODATA replies much slower, since there at least two round-trips, and possibly a timeout, if a server never replies. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers Status in “network-manager” package in Ubuntu: Confirmed Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1003842] Re: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers
Simon Kelley might have written dnsmaskq with the assumption that all DNS servers upstream have the same view about the namespace. However, this is not how RFC sees it nor how it is set up in a majority of installations. Can you provide an authoritative reference for that? As far as I can see, the internal DNS server can provide one of five different answers to a query (there are other possible answers, including delagations, but these are the five possible ones to a stub resolver which sets the RD bit in th query) 1) A valid answer 2) A NODATA answer asserting that the domain exists, but the domain has no information for the type (A, , MX..) queried. 3) A NXDOMAIN anser asserting that the domain does not exist. 4) No answer. 5) An error return code. 1) and 4) and 5) are not a probem, the next step is obvious. the argument is what to do in 2) and 3), we can either accept the valid reply that comes from DNS server or we can try again witha another one. Dnsmasq does the former, and that, I assert, is the correct thing to do. I believe it's what the libc resolver does too. Given the above, the only way to use an internal DNS server which knows about local records is to make sure it's always queried first: we can't sensibly send the query to the external server and then to the internal server when the external one says don't know since THERE IS NO VALID DON'T KNOW ANSWER. My comment about random failures due to UDP packet loss applies here, but if you want dnsmasq to work this way, there's a flag, --strict-order, which will do it. Assume --strict-order. Since we've decide that the only time we're going to use a second nameserver is when the first one doesn't reply, this affects the timeliness of anwers, if you always send to the one nameserver first, the only circumstance you can use an answer from the second server if after the first one times out. The second server isn't very useful if using it makes all DNS queries take 2-3 seconds. One the other hand, if you arrange that all the servers are equivalent, you can keep a note of which ones are up, or even send the query to all the servers, use the first reply, and discard the rest. Dnsmasq uses both these techniques to improve resilience. If you have very flaky servers, you can even tell it to send every query to all the available servers. Executive summary: non-equivalent servers are bad, but --strict-order will make things work, for the same value of work as the libc resolver). Non-equivalent servers are bad, so don't encourage their use by making --strict-order the default. HTH Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers Status in “network-manager” package in Ubuntu: Confirmed Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1003842] Re: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers
To be frank, when changing the default system resolver, expected behavior should be the default. It's all well and good saying that non-equivalent resolvers are 'bad' - and in the case of dnsmasq, that might be true - but that's a value judgement that shouldn't have a place in this scenario, since users haven't made the choice to enable dnsmasq, and so shouldn't have to be aware of the caveats (ie - My DNS worked fine before upgrade). It's a delicate trade-off, made all the more ironic by the fact that without dnsmasq, a second DNS server is practically useless (because you have to wait for the time-out on the first for each and every query). The easiest solution is just to delete the second nameserver. All I can say is that dnsmasq provides both modes, and the default is what it is for the reasons I outlined. If Ubuntu as a distro wants to flip the default, they can. My personal opinion is that it would be a mistake, but that's just my opinion. Question: does networkmanager's GUI expose the option to divert particular domains to a special nameserver? That's an alternative correct way to achieve layering local names over the global DNS. Cheers, Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers Status in “network-manager” package in Ubuntu: Confirmed Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1003842] Re: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers
Thomas in #17 A heuristic for this is difficult, because you have to prove a negative. If we can assume the first nameserver has local addresses, we can never return a reply from any other nameserver until we have the reply from the first one, in case the first one has different data. Once we see different data from different nameservers, we can go to --strict-order mode, but the opposite is not true: the same answer for a particular query doesn't guarantee that the answers to future queries will always agree. There's no way to be sure that the nameservers are equivalent based on the history of returned queries. Unless we can assume that, we always need to wait for the first nameserver to reply (or a timeout) and have to stay in --strict-order mode forever. There is one possibility, which is to assume that nameservers are equivalent, but switch to --strict-order mode if conflicting replies are seen. When a query is forwarded to all available servers, and the first reply sent back to the original requestor, keep the record of the reply (at least, a bit indicating NODATA/NXDOMAIN or a valid reply. If another reply comes in later from another nameserver which conflicts, then switch to --strict-order mode. This will not get the first queries right, but it will be triggered eventually (and it might be triggered, swicthing mode forever, by random server glitches) For a single-host cache, --strict-order might be the simplest fix.. Simon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1003842 Title: Precise NM with dns=dnsmasq breaks systems with non-equivalent upstream nameservers Status in “network-manager” package in Ubuntu: Confirmed Bug description: A number of reports already filed against network-manager seem to reflect this problem, but to make things very clear I am opening a new report. Where appropriate I will mark other reports as duplicates of this one. Consider a pre-Precise system with the following /etc/resolv.conf: nameserver 192.168.0.1 nameserver 8.8.8.8 The first address is the address of a nameserver on the LAN that can resolve both private and public domain names. The second address is the address of a nameserver on the Internet that can resolve only public names. This setup works fine because the GNU resolver always tries the first- listed address first. Now the administrator upgrades to Precise and instead of writing the above to resolv.conf, NetworkManager writes server=192.168.0.1 server=8.8.8.8 to /var/run/nm-dns-dnsmasq.conf and nameserver 127.0.0.1 to resolv.conf. Resolution of private domain names is now broken because dnsmasq treats the two upstream nameservers as equals and uses the faster one, which could be 8.8.8.8. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
