[Touch-packages] [Bug 1211700] Re: [gallium] EGL clients using a gallium driver (radeon, nouveau, freedreno) that saturate the GPU cause the Mir server to slow, freeze and stutter, displaying very few
Closing this ticket where I can as there's no update for 5 years. Plus mir has been supplanted by wayland. ** Changed in: mesa (Ubuntu) Status: New => Won't Fix ** Changed in: mir (Ubuntu) Status: Triaged => Won't Fix ** Changed in: mir Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mir in Ubuntu. https://bugs.launchpad.net/bugs/1211700 Title: [gallium] EGL clients using a gallium driver (radeon, nouveau, freedreno) that saturate the GPU cause the Mir server to slow, freeze and stutter, displaying very few frames Status in Mir: Fix Released Status in mesa package in Ubuntu: Won't Fix Status in mir package in Ubuntu: Won't Fix Bug description: GPU-heavy clients on Mesa gallium drivers (e.g. radeon, nouveau and freedreno) cause the Mir server to slow, sometimes to a halt. This is seen as a frozen screen, unable to move surfaces, or unable to switch VTs (for a while). For example: mir_demo_client_egltriangle -n mir_demo_client_eglplasma -n The -n flag (swapinterval = 0) seems to cause the client to overload the mir server to the point where it cannot render physical frames very often. $ es2_info EGL_VERSION = 1.4 (Gallium) EGL_VENDOR = Mesa Project EGL_EXTENSIONS = EGL_WL_bind_wayland_display EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_image EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_surfaceless_context EGL_NOK_swap_region EGL_NV_post_sub_buffer EGL_CLIENT_APIS = OpenGL OpenGL_ES OpenGL_ES2 OpenVG GL_VERSION: OpenGL ES 3.0 Mesa 9.2.0-devel GL_RENDERER: Gallium 0.4 on AMD CEDAR ... $ es2_info EGL_VERSION = 1.4 (Gallium) EGL_VENDOR = Mesa Project EGL_EXTENSIONS = EGL_WL_bind_wayland_display EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_image EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_surfaceless_context EGL_NOK_swap_region EGL_NV_post_sub_buffer EGL_CLIENT_APIS = OpenGL OpenGL_ES OpenGL_ES2 OpenVG GL_VERSION: OpenGL ES 3.0 Mesa 9.2.0-devel GL_RENDERER: Gallium 0.4 on NVA8 ... To manage notifications about this bug go to: https://bugs.launchpad.net/mir/+bug/1211700/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2006669] [NEW] Asynchronous wait on fence ... timed out (hint:intel_atomic_commit_ready [i915])
Public bug reported: GUI hard lock during zoom session and gnome-terminal kern.log shows a mix of errors __ kernel: [ 3627.948545] Asynchronous wait on fence :00:02.0:gnome-shell[4236]:40810 timed out (hint:intel_atomic_commit_ready [i915]) kernel: [ 3631.063832] i915 :00:02.0: [drm] GPU HANG: ecode 12:1:85db, in chrome [5521] kernel: [ 3631.064218] i915 :00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0 kernel: [ 3631.165642] i915 :00:02.0: [drm] chrome[5521] context reset due to GPU hang kernel: [ 3631.165719] i915 :00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1 kernel: [ 3631.165725] i915 :00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9 kernel: [ 3631.187377] i915 :00:02.0: [drm] HuC authenticated kernel: [ 3631.187670] i915 :00:02.0: [drm] GuC submission enabled kernel: [ 3631.187672] i915 :00:02.0: [drm] GuC SLPC enabled ___ I suspect this issue to be upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7755 upstream commit: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20169/commits?commit_id=b9403b1c477e7af04114ae6a4e16ca370e22253c#d6ffde011ad32c6371611e7d64affaeb21b6b217 Reproducer: Although I don't have my own reproducer, the upstream mesa reproducer does trigger a hang on my machine. Upstream Reproducer: Open https://kartikmandhang.netlify.app/ when it loads, you will see pikachu. Press "S", he will go back. My whole system freezes from this in Wayland, regardless of the browser. Kernel: 6.0.0-1008-oem Mesa: 22.2.5-0ubuntu0.1~22.04.1 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1 ProcVersionSignature: Ubuntu 6.0.0-1008.8-oem 6.0.9 Uname: Linux 6.0.0-1008-oem x86_64 ApportVersion: 2.20.11-0ubuntu82.3 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Feb 8 21:40:19 2023 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes, including running git bisection searches GraphicsCard: Intel Corporation Alder Lake-P Integrated Graphics Controller [8086:46a6] (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Dell Device [1028:0b1a] Subsystem: Dell Device [1028:0b1a] InstallationDate: Installed on 2022-07-13 (211 days ago) InstallationMedia: Ubuntu-Server 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220421) MachineType: Dell Inc. Precision 5570 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.0.0-1008-oem root=/dev/mapper/ubuntu--vg-ubuntu--lv ro pcie_aspm=force quiet splash mem_sleep_default=deep vt.handoff=7 SourcePackage: mesa UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/21/2022 dmi.bios.release: 1.9 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.9.1 dmi.board.name: 03M8N5 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.9.1:bd11/21/2022:br1.9:svnDellInc.:pnPrecision5570:pvr:rvnDellInc.:rn03M8N5:rvrA00:cvnDellInc.:ct10:cvr:sku0B1A: dmi.product.family: Precision dmi.product.name: Precision 5570 dmi.product.sku: 0B1A dmi.sys.vendor: Dell Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 22.2.5-0ubuntu0.1~22.04.1 version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.7 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 ** Affects: mesa (Ubuntu) Importance: Undecided Assignee: Dave Chiluk (chiluk) Status: New ** Tags: amd64 apport-bug jammy ubuntu uec-images wayland-session -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2006669 Title: Asynchronous wait on fence ... timed out (hint:intel_atomic_commit_ready [i915]) Status in mesa package in Ubuntu: New Bug description: GUI hard lock during zoom session and gnome-terminal kern.log shows a mix of errors __ kernel: [ 3627.948545] Asynchronous wait on fence :00:02.0:gnome-shell[4236]:40810 timed out (hint:intel_atomic_commit_ready [i915]) kernel: [ 3631.063832] i915 :00:02.0: [drm] GPU HANG: ecode 12:1:
[Touch-packages] [Bug 2006669] Re: Asynchronous wait on fence ... timed out (hint:intel_atomic_commit_ready [i915])
** Tags added: indeed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2006669 Title: Asynchronous wait on fence ... timed out (hint:intel_atomic_commit_ready [i915]) Status in mesa package in Ubuntu: New Bug description: GUI hard lock during zoom session and gnome-terminal kern.log shows a mix of errors __ kernel: [ 3627.948545] Asynchronous wait on fence :00:02.0:gnome-shell[4236]:40810 timed out (hint:intel_atomic_commit_ready [i915]) kernel: [ 3631.063832] i915 :00:02.0: [drm] GPU HANG: ecode 12:1:85db, in chrome [5521] kernel: [ 3631.064218] i915 :00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0 kernel: [ 3631.165642] i915 :00:02.0: [drm] chrome[5521] context reset due to GPU hang kernel: [ 3631.165719] i915 :00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1 kernel: [ 3631.165725] i915 :00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9 kernel: [ 3631.187377] i915 :00:02.0: [drm] HuC authenticated kernel: [ 3631.187670] i915 :00:02.0: [drm] GuC submission enabled kernel: [ 3631.187672] i915 :00:02.0: [drm] GuC SLPC enabled ___ I suspect this issue to be upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7755 upstream commit: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20169/commits?commit_id=b9403b1c477e7af04114ae6a4e16ca370e22253c#d6ffde011ad32c6371611e7d64affaeb21b6b217 Reproducer: Although I don't have my own reproducer, the upstream mesa reproducer does trigger a hang on my machine. Upstream Reproducer: Open https://kartikmandhang.netlify.app/ when it loads, you will see pikachu. Press "S", he will go back. My whole system freezes from this in Wayland, regardless of the browser. Kernel: 6.0.0-1008-oem Mesa: 22.2.5-0ubuntu0.1~22.04.1 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1 ProcVersionSignature: Ubuntu 6.0.0-1008.8-oem 6.0.9 Uname: Linux 6.0.0-1008-oem x86_64 ApportVersion: 2.20.11-0ubuntu82.3 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Feb 8 21:40:19 2023 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes, including running git bisection searches GraphicsCard: Intel Corporation Alder Lake-P Integrated Graphics Controller [8086:46a6] (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Dell Device [1028:0b1a] Subsystem: Dell Device [1028:0b1a] InstallationDate: Installed on 2022-07-13 (211 days ago) InstallationMedia: Ubuntu-Server 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220421) MachineType: Dell Inc. Precision 5570 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.0.0-1008-oem root=/dev/mapper/ubuntu--vg-ubuntu--lv ro pcie_aspm=force quiet splash mem_sleep_default=deep vt.handoff=7 SourcePackage: mesa UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/21/2022 dmi.bios.release: 1.9 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.9.1 dmi.board.name: 03M8N5 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.9.1:bd11/21/2022:br1.9:svnDellInc.:pnPrecision5570:pvr:rvnDellInc.:rn03M8N5:rvrA00:cvnDellInc.:ct10:cvr:sku0B1A: dmi.product.family: Precision dmi.product.name: Precision 5570 dmi.product.sku: 0B1A dmi.sys.vendor: Dell Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 22.2.5-0ubuntu0.1~22.04.1 version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.7 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/2006669/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2006669] Re: Asynchronous wait on fence ... timed out (hint:intel_atomic_commit_ready [i915])
The above referenced commits are committed into mesa 23.0.0. I see references to backports of this onto stable, but I'm not familiar enough with mesa as a project just yet. ** Also affects: mesa (Ubuntu Lunar) Importance: Undecided Assignee: Dave Chiluk (chiluk) Status: New ** Also affects: mesa (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: mesa (Ubuntu Kinetic) Importance: Undecided Status: New ** Changed in: mesa (Ubuntu Jammy) Assignee: (unassigned) => Dave Chiluk (chiluk) ** Changed in: mesa (Ubuntu Lunar) Assignee: Dave Chiluk (chiluk) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2006669 Title: Asynchronous wait on fence ... timed out (hint:intel_atomic_commit_ready [i915]) Status in mesa package in Ubuntu: New Status in mesa source package in Jammy: New Status in mesa source package in Kinetic: New Status in mesa source package in Lunar: New Bug description: GUI hard lock during zoom session and gnome-terminal kern.log shows a mix of errors __ kernel: [ 3627.948545] Asynchronous wait on fence :00:02.0:gnome-shell[4236]:40810 timed out (hint:intel_atomic_commit_ready [i915]) kernel: [ 3631.063832] i915 :00:02.0: [drm] GPU HANG: ecode 12:1:85db, in chrome [5521] kernel: [ 3631.064218] i915 :00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0 kernel: [ 3631.165642] i915 :00:02.0: [drm] chrome[5521] context reset due to GPU hang kernel: [ 3631.165719] i915 :00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1 kernel: [ 3631.165725] i915 :00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9 kernel: [ 3631.187377] i915 :00:02.0: [drm] HuC authenticated kernel: [ 3631.187670] i915 :00:02.0: [drm] GuC submission enabled kernel: [ 3631.187672] i915 :00:02.0: [drm] GuC SLPC enabled ___ I suspect this issue to be upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7755 upstream commit: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20169/commits?commit_id=b9403b1c477e7af04114ae6a4e16ca370e22253c#d6ffde011ad32c6371611e7d64affaeb21b6b217 Reproducer: Although I don't have my own reproducer, the upstream mesa reproducer does trigger a hang on my machine. Upstream Reproducer: Open https://kartikmandhang.netlify.app/ when it loads, you will see pikachu. Press "S", he will go back. My whole system freezes from this in Wayland, regardless of the browser. Kernel: 6.0.0-1008-oem Mesa: 22.2.5-0ubuntu0.1~22.04.1 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1 ProcVersionSignature: Ubuntu 6.0.0-1008.8-oem 6.0.9 Uname: Linux 6.0.0-1008-oem x86_64 ApportVersion: 2.20.11-0ubuntu82.3 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Feb 8 21:40:19 2023 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes, including running git bisection searches GraphicsCard: Intel Corporation Alder Lake-P Integrated Graphics Controller [8086:46a6] (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Dell Device [1028:0b1a] Subsystem: Dell Device [1028:0b1a] InstallationDate: Installed on 2022-07-13 (211 days ago) InstallationMedia: Ubuntu-Server 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220421) MachineType: Dell Inc. Precision 5570 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.0.0-1008-oem root=/dev/mapper/ubuntu--vg-ubuntu--lv ro pcie_aspm=force quiet splash mem_sleep_default=deep vt.handoff=7 SourcePackage: mesa UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/21/2022 dmi.bios.release: 1.9 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.9.1 dmi.board.name: 03M8N5 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.9.1:bd11/21/2022:br1.9:svnDellInc.:pnPrecision5570:pvr:rvnDellInc.:rn03M8N5:rvrA00:cvnDellInc.:ct10:cvr:sku0B1A: dmi.product.family: Precision dmi.product.name: Precision 5570 dmi.product.sku: 0B1A dmi.sys.vendor: Dell Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 22.2.5-0ubuntu0.1~22.04.1 version
[Touch-packages] [Bug 2006669] Re: Asynchronous wait on fence ... timed out (hint:intel_atomic_commit_ready [i915])
Looking at mesa git staging/23.0 it looks like 78a75e0d2 and 4c986c58b may also be required. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2006669 Title: Asynchronous wait on fence ... timed out (hint:intel_atomic_commit_ready [i915]) Status in mesa package in Ubuntu: New Status in mesa source package in Jammy: New Status in mesa source package in Kinetic: New Status in mesa source package in Lunar: New Bug description: GUI hard lock during zoom session and gnome-terminal kern.log shows a mix of errors __ kernel: [ 3627.948545] Asynchronous wait on fence :00:02.0:gnome-shell[4236]:40810 timed out (hint:intel_atomic_commit_ready [i915]) kernel: [ 3631.063832] i915 :00:02.0: [drm] GPU HANG: ecode 12:1:85db, in chrome [5521] kernel: [ 3631.064218] i915 :00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0 kernel: [ 3631.165642] i915 :00:02.0: [drm] chrome[5521] context reset due to GPU hang kernel: [ 3631.165719] i915 :00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1 kernel: [ 3631.165725] i915 :00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9 kernel: [ 3631.187377] i915 :00:02.0: [drm] HuC authenticated kernel: [ 3631.187670] i915 :00:02.0: [drm] GuC submission enabled kernel: [ 3631.187672] i915 :00:02.0: [drm] GuC SLPC enabled ___ I suspect this issue to be upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7755 upstream commit: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20169/commits?commit_id=b9403b1c477e7af04114ae6a4e16ca370e22253c#d6ffde011ad32c6371611e7d64affaeb21b6b217 Reproducer: Although I don't have my own reproducer, the upstream mesa reproducer does trigger a hang on my machine. Upstream Reproducer: Open https://kartikmandhang.netlify.app/ when it loads, you will see pikachu. Press "S", he will go back. My whole system freezes from this in Wayland, regardless of the browser. Kernel: 6.0.0-1008-oem Mesa: 22.2.5-0ubuntu0.1~22.04.1 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1 ProcVersionSignature: Ubuntu 6.0.0-1008.8-oem 6.0.9 Uname: Linux 6.0.0-1008-oem x86_64 ApportVersion: 2.20.11-0ubuntu82.3 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Wed Feb 8 21:40:19 2023 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes, including running git bisection searches GraphicsCard: Intel Corporation Alder Lake-P Integrated Graphics Controller [8086:46a6] (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Dell Device [1028:0b1a] Subsystem: Dell Device [1028:0b1a] InstallationDate: Installed on 2022-07-13 (211 days ago) InstallationMedia: Ubuntu-Server 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220421) MachineType: Dell Inc. Precision 5570 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.0.0-1008-oem root=/dev/mapper/ubuntu--vg-ubuntu--lv ro pcie_aspm=force quiet splash mem_sleep_default=deep vt.handoff=7 SourcePackage: mesa UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/21/2022 dmi.bios.release: 1.9 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.9.1 dmi.board.name: 03M8N5 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.9.1:bd11/21/2022:br1.9:svnDellInc.:pnPrecision5570:pvr:rvnDellInc.:rn03M8N5:rvrA00:cvnDellInc.:ct10:cvr:sku0B1A: dmi.product.family: Precision dmi.product.name: Precision 5570 dmi.product.sku: 0B1A dmi.sys.vendor: Dell Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 22.2.5-0ubuntu0.1~22.04.1 version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.7 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/2006669/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net
[Touch-packages] [Bug 2020604] Re: After mesa upgrades, Chrome won't show graphics
As I have multiple profiles, I chose to simply delete all Cache directories $ find ~/.config/google-chrome \( -name "*Cache" \) | xargs -d '\n' -L 1 rm -rf -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2020604 Title: After mesa upgrades, Chrome won't show graphics Status in chromium-browser package in Ubuntu: Fix Committed Status in mesa package in Ubuntu: Triaged Bug description: After today's Ubuntu 22.04 mesa upgrades many of our users reported problems viewing graphics when using Google Chrome (Stable). The mesa upgrades we installed were: [UPGRADE] libegl-mesa0:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2 [UPGRADE] libegl1-mesa:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2 [UPGRADE] libgl1-mesa-dri:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2 [UPGRADE] libgl1-mesa-glx:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2 [UPGRADE] libglapi-mesa:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2 [UPGRADE] libglx-mesa0:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2 [UPGRADE] mesa-vulkan-drivers:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2 We documented the problem in AskUbuntu before we realized it was probably related to mesa, so wanted to link to that report here: https://askubuntu.com/questions/1469116/since-23-may-2023-ubuntu-22-04-mesa- updates-chrome-wont-display-website-graphi There are several useful pointers and bypasses listed in that AskUbuntu link (one being to remove affected users' GPUCache directories, which does not destroy their profiles and seems to work in many but not all cases). Not sure if this is an issue with mesa or Chrome or specific machine graphics or an interaction between them. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2020604/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] [NEW] dev file system is mounted without nosuid
Public bug reported: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug ec2-images focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid Status in systemd package in Ubuntu: New Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid
** Also affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid
So far I've only tested focal AWS images, but this may likely exist elsewhere as well. ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: New Status in systemd source package in Focal: New Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid
I was hoping to work around this in /etc/init.d/udev, but it looks like that gets redirected to systemctl via . lib/lsb/init-functions ** Description changed: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. - $ mount | grep devtmpfs - nosuid found in the options list. + $ mount | grep devtmpfs + nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: - + Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: - TERM=xterm-256color - PATH=(custom, no user) - LANG=C.UTF-8 - SHELL=/bin/bash + TERM=xterm-256color + PATH=(custom, no user) + LANG=C.UTF-8 + SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: New Status in systemd source package in Focal: New Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_c
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid
Looks like Kees already found this years ago. https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ Looks like it was accepted as commit 28f0c335dd4a1 in 5.17. So I think we should apply this patch and the corresponding set CONFIG_DEVTMPFS_SAFE=y at least for the aws kernel and preferably all the 5.15 kernels. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: New Status in systemd source package in Jammy: New Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid
** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: New Status in systemd source package in Jammy: New Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid
** Changed in: linux (Ubuntu Jammy) Status: New => Confirmed ** Changed in: systemd (Ubuntu Jammy) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: Confirmed Status in systemd source package in Jammy: Confirmed Bug description: This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid
** Description changed: + [ SRU TEMPLATE ] + [ Impact ] + + * nosuid, and noexec bits are not set on /dev + * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. + * It is not best security practice. + + [ Test Plan ] + +1.Boot a Canonical Supplied EC2 instance +2.Check the mount options for /dev. +3.You will notice the lack of nosuid and noexec on /dev. + + [ Where problems could occur ] + + * As of 2022/10/06, I need to test this, but don't know how to build + -aws flavored ubuntu kernels. Instructions welcome. + + * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: + https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ + + * Low risk if a driver depends on /dev allowing suid or exec this might + prevent boot. That being said, all kernels that have been booting with + an initramfs have been getting nosuid, and noexec set so hopefully we + can consider that risk fairly well tested. + + [ Other Info ] + + * Patch is accepted into 5.17, and will drop out quickly + * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully + + + <<< ORIGINAL TEXT + This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen ** Description changed: [ SRU TEMPLATE ] - [ Impact ] + [ Impact ] - * nosuid, and noexec bits are not set on /dev - * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. - * It is not best security practice. + * nosuid, and noexec bits are not set on /dev + * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. + * It is not best security practice. [ Test Plan ] -1.Boot a Canonical Supplied EC2 instance -2.Check the mount options for /dev. -3.You will notice the lack of nosuid and noexec on /dev. + 1.Boot a Canonical Supplied EC2 instance + 2.Check the mount options for /dev. + 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] - * As of 2022/10/06, I need to test this, but don't know how to build - -aws flavored ubuntu kernels. Instructions welcome. + * As of 2022/10/06, I need to test this, but don't know how to build +
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid
** Information type changed from Private Security to Public Security ** Summary changed: - dev file system is mounted without nosuid + dev file system is mounted without nosuid or noexec -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: Confirmed Status in systemd source package in Jammy: Confirmed Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec
Here is a workaround for this issue in case anyone finds this in the future. Copy remount_dev.service to /etc/systemd/system sudo chown root:root /etc/systemd/system/remount_dev.service sudo systemctl daemon-reload sudo systemctl enable remount_dev.service Still I think the kernel patch should be applied, but at least there's a workaround for now. ** Attachment added: "Systemd unit file as workaround" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+attachment/5622080/+files/remount_dev.service -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: Confirmed Status in systemd source package in Jammy: Confirmed Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubun
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec
@juliank, is this an aws system? If not there's a good chance that you are using an initramfs to mount the filesystems. That's definited in either /etc/init.d/udev or directly out of the init that lives in the initramfs. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: Confirmed Status in systemd source package in Jammy: Confirmed Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec
In case anyone is curious conversation is on-going on the kernel-team mailing list https://lists.ubuntu.com/archives/kernel-team/2022-October/133764.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Focal: Confirmed Status in systemd source package in Focal: Confirmed Status in linux source package in Jammy: Confirmed Status in systemd source package in Jammy: Confirmed Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec
Alright so that means we either need to push a change to remove noexec from the kernel init code, or we go ahead with noexec, and give people on option to remount with exec should they want sgx functionality. I do think the nosuid flag does still provide some benefit even if we decide not to include the noexec flag by default until 5.17+. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: In Progress Status in systemd source package in Focal: Invalid Status in linux source package in Jammy: In Progress Status in systemd source package in Jammy: Invalid Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.
[Touch-packages] [Bug 1991975] Re: dev file system is mounted without nosuid or noexec
So where are we on this folks? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1991975 Title: dev file system is mounted without nosuid or noexec Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in linux source package in Focal: In Progress Status in systemd source package in Focal: Invalid Status in linux source package in Jammy: In Progress Status in systemd source package in Jammy: Invalid Bug description: [ SRU TEMPLATE ] [ Impact ] * nosuid, and noexec bits are not set on /dev * This has the potential for nefarious actors to use this as an avenue for attack. see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 for more discussion around this. * It is not best security practice. [ Test Plan ] 1.Boot a Canonical Supplied EC2 instance 2.Check the mount options for /dev. 3.You will notice the lack of nosuid and noexec on /dev. [ Where problems could occur ] * As of 2022/10/06, I need to test this, but don't know how to build -aws flavored ubuntu kernels. Instructions welcome. I'm holding off on adding SRU tags until I can actually get this tested. * If this is applied to non initramfs-less kernels it could potentially cause a regression for very old hardware that does nefarious things with memory. For a larger discussion about that see: https://lore.kernel.org/lkml/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64/T/ * Low risk if a driver depends on /dev allowing suid or exec this might prevent boot. That being said, all kernels that have been booting with an initramfs have been getting nosuid, and noexec set so hopefully we can consider that risk fairly well tested. [ Other Info ] * Patch is accepted into 5.17, and will drop out quickly * Any server booting with an initramfs already has nosuid, and noexec set, so hopefully <<< ORIGINAL TEXT This is similar to https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1450960 but new. I discovered that my ec2 instances based off of Canonical supplied AMI ami-0a23d90349664c6ee *(us-east-2), have dev mounted mounted without the nosuid option. https://us-east-2.console.aws.amazon.com/ec2/home?region=us- east-2#Images:visibility=public-images;imageId=ami-0a23d90349664c6ee My usb installed 20.04.4 home machine does not have this problem, but it has been installed for quite some time. My 22.04 laptop machine also does not have this issue. Reproduce. Start an ec2 instance based off of ami-0a23d90349664c6ee. $ mount | grep devtmpfs nosuid is not found in the options list. I've checked the initrd, and /etc/init.d/udev script and all places I know of where dev gets mounted set nosuid, so it's non-obvious what boot code-path is being taken that results in nosuid missing. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.18 ProcVersionSignature: Ubuntu 5.15.0-1020.24~20.04.1-aws 5.15.53 Uname: Linux 5.15.0-1020-aws x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 60-cdrom_id.rules 70-snap.snapd.rules Date: Thu Oct 6 17:39:42 2022 Ec2AMI: ami-0a23d90349664c6ee Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-2c Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1020-aws root=PARTUUID=5bb90437-9efc-421d-aa94-c512c3b666a3 ro console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295 panic=-1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.release: 4.2 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:br4.2:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr:sku: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991975/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
I have tested bionic and cosmic myself, but I'd like to hear from a user
or two. I have experienced the low-volume issue, but that appears to be
correctable by launching alsamixer. All in all it's a better experience
than before imho.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1758736
Title:
[USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only
mono playback
Status in pulseaudio package in Ubuntu:
Fix Released
Status in pulseaudio source package in Bionic:
Fix Committed
Status in pulseaudio source package in Cosmic:
Fix Committed
Status in pulseaudio source package in Disco:
Fix Released
Bug description:
[Impact]
* User is only able to get mono audio from steelseries headsets
because they provide both a stereo and mono output. PA selects the
mono output by default.
* This should be backported to stable releases because this fix is
isolated to code that only applies to the affected headsets.
Additionally other gaming headsets may be more easily enabled by adding
ATTRS{idVendor}=="", ATTRS{idProduct}=="",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
to /lib/udev/rules.d/90-pulseaudio.rules now. Such as the Lucidsound
LS31 which I own.
* The upload fixes the bug by conditionally setting a pulseaudio
profile for the headset based on specific usb vendor and product ids
in the udev rules.
[Test Case]
1. Acquire headset.
2. Open sound settings, and click test speakers.
3. Only option available will be mono sound
[Regression Potential]
* Risk of regressions should be mitigated to those who own the
headset. In which case it is likely that their headset is already not
working.
[Other Info]
* All patches originate from upstream pulseaudio, and are documented as
such including the shas.
* I will be pursuing enabling other similar headsets in the coming weeks.
* I plan to work with upstream pulseaudio to enable my own headset and to
also make the headset templates backported here more generic.
Original Description -
There is not stereo playback only mono playback
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: pulseaudio 1:10.0-2ubuntu3.1
ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13
Uname: Linux 4.13.0-37-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio
/dev/snd/controlC1: kaj1755 F pulseaudio
/dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio
/dev/snd/controlC0: kaj1755 F pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Sun Mar 25 21:30:50 2018
InstallationDate: Installed on 2018-03-08 (17 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
SourcePackage: pulseaudio
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful
Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7
Symptom_PulsePlaybackTest: PulseAudio playback test failed
Symptom_Type: No sound at all
Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/09/2016
dmi.bios.vendor: LENOVO
dmi.bios.version: R06ET35W (1.09 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20FMS2AV00
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias:
dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T460
dmi.product.name: 20FMS2AV00
dmi.product.version: ThinkPad T460
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
** Tags removed: verification-needed-cosmic
** Tags added: verification-done-cosmic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1758736
Title:
[USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only
mono playback
Status in pulseaudio package in Ubuntu:
Fix Released
Status in pulseaudio source package in Bionic:
Fix Committed
Status in pulseaudio source package in Cosmic:
Fix Committed
Status in pulseaudio source package in Disco:
Fix Released
Bug description:
[Impact]
* User is only able to get mono audio from steelseries headsets
because they provide both a stereo and mono output. PA selects the
mono output by default.
* This should be backported to stable releases because this fix is
isolated to code that only applies to the affected headsets.
Additionally other gaming headsets may be more easily enabled by adding
ATTRS{idVendor}=="", ATTRS{idProduct}=="",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
to /lib/udev/rules.d/90-pulseaudio.rules now. Such as the Lucidsound
LS31 which I own.
* The upload fixes the bug by conditionally setting a pulseaudio
profile for the headset based on specific usb vendor and product ids
in the udev rules.
[Test Case]
1. Acquire headset.
2. Open sound settings, and click test speakers.
3. Only option available will be mono sound
[Regression Potential]
* Risk of regressions should be mitigated to those who own the
headset. In which case it is likely that their headset is already not
working.
[Other Info]
* All patches originate from upstream pulseaudio, and are documented as
such including the shas.
* I will be pursuing enabling other similar headsets in the coming weeks.
* I plan to work with upstream pulseaudio to enable my own headset and to
also make the headset templates backported here more generic.
Original Description -
There is not stereo playback only mono playback
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: pulseaudio 1:10.0-2ubuntu3.1
ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13
Uname: Linux 4.13.0-37-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio
/dev/snd/controlC1: kaj1755 F pulseaudio
/dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio
/dev/snd/controlC0: kaj1755 F pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Sun Mar 25 21:30:50 2018
InstallationDate: Installed on 2018-03-08 (17 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
SourcePackage: pulseaudio
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful
Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7
Symptom_PulsePlaybackTest: PulseAudio playback test failed
Symptom_Type: No sound at all
Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/09/2016
dmi.bios.vendor: LENOVO
dmi.bios.version: R06ET35W (1.09 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20FMS2AV00
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias:
dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T460
dmi.product.name: 20FMS2AV00
dmi.product.version: ThinkPad T460
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1754294] Re: After last updated libcurl3 on libcurl4, some apps are removed.
** Tags added: indeed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1754294 Title: After last updated libcurl3 on libcurl4, some apps are removed. Status in curl package in Ubuntu: Confirmed Bug description: Hi! After last updated libcurl3 on libcurl4, system (Kubuntu 18.04 bionic) deleted such applications as: virtualbox-5.2 opera-stable slack-desktop mongodb I really need these applications, I installed them with broken dependencies, but they are deleted after each update. Is it possible to make the dependence of the libcurl3 in libcurl4, and not remove it altogether from system? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1754294/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841654] Re: Consider replacing mawk with gawk in main
We (Indeed) were recently hit by mawk posix non-compliance as well. For
all the reasons stated above, I would also like to see mawk replaced
with gawk in main. I'd also like to see the mawk dependencies in the
ubuntu-meta packages replaced with gawk. For that reason I'm opening a
separate target for this bug in ubuntu-meta.
** Also affects: ubuntu-meta (Ubuntu)
Importance: Undecided
Status: New
** Tags added: indeed
** Changed in: ubuntu-meta (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mawk in Ubuntu.
https://bugs.launchpad.net/bugs/1841654
Title:
Consider replacing mawk with gawk in main
Status in mawk package in Ubuntu:
Confirmed
Status in ubuntu-meta package in Ubuntu:
Confirmed
Bug description:
For POSIX compatibility reasons Ubuntu ships with mawk ("Mike's awk" =
mawk) in main. There is an awk-symlink to mawk, thus mawk is the
official awk implementation in Ubuntu.
== Reasons against keeping mawk ==
*The mawk package is synced from debian and it is heavily
undermaintained: Debian (and thus Ubuntu) still ships version
1.3.3-17, the same version at least since oldoldstable:
https://packages.debian.org/search?searchon=names&keywords=mawk
*maintainer Thomas E. Dickey (https://invisible-island.net/mawk/)
called officially out that Debian "neglected" mawk in 2014 ("As noted,
mawk has been neglected by some packagers (see for example this
http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=mawk)". And
Debian (and Ubuntu) still ship the same version five years later
*Most other distributions ship mawk at least in its last official
incarnation 1.3.4 in their repositories. Dickey lists AIX, Fedora,
FinkPorts (Mac OS X), FreeBSD port, Gentoo, HPUX, MacPorts (Mac OS X),
NetBSD pkgsrc/lang, OpenCSW (Solaris). That version is from 2014 but
updated snapshots are released in regular intervals. The current
snapshot is from February 2019: https://github.com/ThomasDickey/mawk-
snapshots/blob/ab13a164013940e90c0b1ad36a039feae06a0b65/CHANGES
*A planned rewrite mawk2 was planned by original author Mike Brennan
in 2016 but obviously came to nothing:
https://github.com/ploxiln/mawk-2/commits/master
*Thus mawk sits in Ubuntu main in a version published upstream in 2009
and celebrates its 10th anniversary of negligence. In a state that
Debian was called out for 5 years ago.
*This year it is 10 years unmaintained and largely untouched. At the
end of the next LTS-support-cycle we can celebrate 15 years of not
supporting it.
*awk is included in Linux for POSIX standard compliance. Mawk is known
to be fast and small but it is the implementation that is farthest
from being POSIX compliant, missing things like named character
classes like [[:space:]] within its EREs.
== Reasons for gawk as a replacement ==
*It is the official GNU awk implementation and known to work well with
the rest of the GNU userland.
*It is actively maintained with the last version 5.01 shipping in
June, 2019 (even if Ubuntu will obviously still ship 4.2 for Eoan).
*It is mostly compliant with the POSIX standard.
*Most other distributions ship it as the standard POSIX
implementation, with a awk symlink. So it had security reviews already
by Red Hat and others.
== Possible problems with switching to gawk in time for Ubuntu 20.4 ==
- It might need to be MIRed by the Ubuntu security team and a review
might take some time. So I filed this bug early with Eoan not yet out
of the door.
- It is much larger than mawk, the Ubuntu package is 1600 kB in size,
while mawk is only about 190KB. Thus some might want to split out some
basic functionality to save size. Like what is vim-tiny to vim. To
start gawk in --traditional or --posix mode and disable the extensions
at compile time might be a good start to reduce the size. See:
https://www.gnu.org/software/gawk/manual/html_node/Additional-
Configuration-Options.html#Additional-Configuration-Options
=
ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: mawk 1.3.3-17ubuntu3
ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21
Uname: Linux 5.0.0-27-generic x86_64
ApportVersion: 2.20.10-0ubuntu27.1
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Aug 27 20:12:11 2019
Dependencies:
gcc-9-base 9.1.0-2ubuntu2~19.04
libc6 2.29-0ubuntu2
libgcc1 1:9.1.0-2ubuntu2~19.04
libidn2-0 2.0.5-1
libunistring2 0.9.10-1ubuntu2
InstallationDate: Installed on 2018-02-23 (550 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
ProcEnviron:
LANGUAGE=de_AT:de
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=de_AT.UTF-8
SHELL=/bin/bash
SourcePackage: mawk
UpgradeStatus: No upgrade log present (probably fresh
[Touch-packages] [Bug 1839580] [NEW] LucidSound LS31 only outputs mono sound
Public bug reported: LucidSound LS31 only outputs mono sound. The usb vendor:prod = 2f12:0109. The fix is incoming. ** Affects: pulseaudio (Ubuntu) Importance: Undecided Assignee: Dave Chiluk (chiluk) Status: In Progress ** Changed in: pulseaudio (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1839580 Title: LucidSound LS31 only outputs mono sound Status in pulseaudio package in Ubuntu: In Progress Bug description: LucidSound LS31 only outputs mono sound. The usb vendor:prod = 2f12:0109. The fix is incoming. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1839580/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1839580] Re: LucidSound LS31 only outputs mono sound
Upstream merge request. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/143 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1839580 Title: LucidSound LS31 only outputs mono sound Status in pulseaudio package in Ubuntu: In Progress Bug description: LucidSound LS31 only outputs mono sound. The usb vendor:prod = 2f12:0109. The fix is incoming. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1839580/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1839589] [NEW] pulseaudio FTBFS on eoan 12.2-2ubuntu4
Public bug reported: pulseaudio fails to build from source on Eoan I was attempting to put together a patchset for LP#1839580, but it appears as if the packages are currently failing to build from source. Not sure how they built the first time around. Here's my ppa's buildlog, for a source package with my patch commented out of the series file. https://launchpadlibrarian.net/436626918/buildlog_ubuntu-eoan-amd64.pulseaudio_1%3A12.2-2ubuntu4+lp1839580b2_BUILDING.txt.gz ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1839589 Title: pulseaudio FTBFS on eoan 12.2-2ubuntu4 Status in pulseaudio package in Ubuntu: New Bug description: pulseaudio fails to build from source on Eoan I was attempting to put together a patchset for LP#1839580, but it appears as if the packages are currently failing to build from source. Not sure how they built the first time around. Here's my ppa's buildlog, for a source package with my patch commented out of the series file. https://launchpadlibrarian.net/436626918/buildlog_ubuntu-eoan-amd64.pulseaudio_1%3A12.2-2ubuntu4+lp1839580b2_BUILDING.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1839589/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1839589] Re: pulseaudio FTBFS on eoan 12.2-2ubuntu4 [FAIL: cpu-volume-test]
** Changed in: pulseaudio (Ubuntu) Assignee: (unassigned) => Dave Chiluk (chiluk) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1839589 Title: pulseaudio FTBFS on eoan 12.2-2ubuntu4 [FAIL: cpu-volume-test] Status in pulseaudio package in Ubuntu: Confirmed Bug description: pulseaudio fails to build from source on Eoan I was attempting to put together a patchset for LP#1839580, but it appears as if the packages are currently failing to build from source. Not sure how they built the first time around. Here's my ppa's buildlog, for a source package with my patch commented out of the series file. https://launchpadlibrarian.net/436626918/buildlog_ubuntu-eoan-amd64.pulseaudio_1%3A12.2-2ubuntu4+lp1839580b2_BUILDING.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1839589/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1839589] Re: pulseaudio FTBFS on eoan 12.2-2ubuntu4 [FAIL: cpu-volume-test]
Hey thanks for the fix, I've been on vacation, and didn't have a chance to look at this further. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1839589 Title: pulseaudio FTBFS on eoan 12.2-2ubuntu4 [FAIL: cpu-volume-test] Status in pulseaudio package in Ubuntu: Fix Released Bug description: pulseaudio fails to build from source on Eoan I was attempting to put together a patchset for LP#1839580, but it appears as if the packages are currently failing to build from source. Not sure how they built the first time around. Here's my ppa's buildlog, for a source package with my patch commented out of the series file. https://launchpadlibrarian.net/436626918/buildlog_ubuntu-eoan-amd64.pulseaudio_1%3A12.2-2ubuntu4+lp1839580b2_BUILDING.txt.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1839589/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
** Changed in: pulseaudio (Ubuntu) Assignee: (unassigned) => Dave Chiluk (chiluk) ** Changed in: pulseaudio (Ubuntu) Importance: Undecided => Low ** Also affects: pulseaudio (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: pulseaudio (Ubuntu Disco) Importance: Low Assignee: Dave Chiluk (chiluk) Status: Confirmed ** Also affects: pulseaudio (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: pulseaudio (Ubuntu Cosmic) Importance: Undecided => Low ** Changed in: pulseaudio (Ubuntu Bionic) Importance: Undecided => Low ** Changed in: pulseaudio (Ubuntu Cosmic) Assignee: (unassigned) => Dave Chiluk (chiluk) ** Changed in: pulseaudio (Ubuntu Bionic) Assignee: (unassigned) => Dave Chiluk (chiluk) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1758736 Title: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback Status in pulseaudio package in Ubuntu: Confirmed Status in pulseaudio source package in Bionic: New Status in pulseaudio source package in Cosmic: New Status in pulseaudio source package in Disco: Confirmed Bug description: There is not stereo playback only mono playback ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: pulseaudio 1:10.0-2ubuntu3.1 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio /dev/snd/controlC1: kaj1755 F pulseaudio /dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio /dev/snd/controlC0: kaj1755 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Sun Mar 25 21:30:50 2018 InstallationDate: Installed on 2018-03-08 (17 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1) SourcePackage: pulseaudio Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7 Symptom_PulsePlaybackTest: PulseAudio playback test failed Symptom_Type: No sound at all Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R06ET35W (1.09 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FMS2AV00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T460 dmi.product.name: 20FMS2AV00 dmi.product.version: ThinkPad T460 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
Can someone on this bug please test the packages from https://launchpad.net/~chiluk/+archive/ubuntu/lp1758736 on Bionic? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1758736 Title: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback Status in pulseaudio package in Ubuntu: Confirmed Status in pulseaudio source package in Bionic: New Status in pulseaudio source package in Cosmic: New Status in pulseaudio source package in Disco: Confirmed Bug description: There is not stereo playback only mono playback ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: pulseaudio 1:10.0-2ubuntu3.1 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio /dev/snd/controlC1: kaj1755 F pulseaudio /dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio /dev/snd/controlC0: kaj1755 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Sun Mar 25 21:30:50 2018 InstallationDate: Installed on 2018-03-08 (17 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1) SourcePackage: pulseaudio Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7 Symptom_PulsePlaybackTest: PulseAudio playback test failed Symptom_Type: No sound at all Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R06ET35W (1.09 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FMS2AV00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T460 dmi.product.name: 20FMS2AV00 dmi.product.version: ThinkPad T460 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
Basically what I did was backport all the required Arctis stuff that seemed to be required in order to get my lucid sound headphones working. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1758736 Title: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback Status in pulseaudio package in Ubuntu: Confirmed Status in pulseaudio source package in Bionic: New Status in pulseaudio source package in Cosmic: New Status in pulseaudio source package in Disco: Confirmed Bug description: There is not stereo playback only mono playback ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: pulseaudio 1:10.0-2ubuntu3.1 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio /dev/snd/controlC1: kaj1755 F pulseaudio /dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio /dev/snd/controlC0: kaj1755 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Sun Mar 25 21:30:50 2018 InstallationDate: Installed on 2018-03-08 (17 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1) SourcePackage: pulseaudio Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7 Symptom_PulsePlaybackTest: PulseAudio playback test failed Symptom_Type: No sound at all Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R06ET35W (1.09 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FMS2AV00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T460 dmi.product.name: 20FMS2AV00 dmi.product.version: ThinkPad T460 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
Looking at pulseaudio upstream, it looks like 12.2 has 15386a710c1500f70085a6312fb4d84be4d254c9 and c7fe78c9f73ded2c3428666722ec9c1af4b82812 but not 83675b3745c64bd738400eae44eb4daa195ed88a fe6a9a8f59932f29cc77eac2a7e2c6bd07c8c7d0 3454c19f3c277d5d0099f17e7ebf5d2005afa4b0 Bionic will needs all of the above sha's. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1758736 Title: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback Status in pulseaudio package in Ubuntu: Confirmed Status in pulseaudio source package in Bionic: In Progress Status in pulseaudio source package in Cosmic: Confirmed Status in pulseaudio source package in Disco: Confirmed Bug description: There is not stereo playback only mono playback ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: pulseaudio 1:10.0-2ubuntu3.1 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio /dev/snd/controlC1: kaj1755 F pulseaudio /dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio /dev/snd/controlC0: kaj1755 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Sun Mar 25 21:30:50 2018 InstallationDate: Installed on 2018-03-08 (17 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1) SourcePackage: pulseaudio Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7 Symptom_PulsePlaybackTest: PulseAudio playback test failed Symptom_Type: No sound at all Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R06ET35W (1.09 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FMS2AV00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T460 dmi.product.name: 20FMS2AV00 dmi.product.version: ThinkPad T460 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
@Kaj Printz Madsen I know you opened this a long time ago, but is there any chance you could test the ppa for me? Thanks. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1758736 Title: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback Status in pulseaudio package in Ubuntu: Confirmed Status in pulseaudio source package in Bionic: In Progress Status in pulseaudio source package in Cosmic: Confirmed Status in pulseaudio source package in Disco: Confirmed Bug description: There is not stereo playback only mono playback ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: pulseaudio 1:10.0-2ubuntu3.1 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio /dev/snd/controlC1: kaj1755 F pulseaudio /dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio /dev/snd/controlC0: kaj1755 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Sun Mar 25 21:30:50 2018 InstallationDate: Installed on 2018-03-08 (17 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1) SourcePackage: pulseaudio Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7 Symptom_PulsePlaybackTest: PulseAudio playback test failed Symptom_Type: No sound at all Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R06ET35W (1.09 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FMS2AV00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T460 dmi.product.name: 20FMS2AV00 dmi.product.version: ThinkPad T460 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
I'm pretty sure you need to adjust the "chat mix" knob on your headset as the audio will now be playing through a separate audio device on the headset. Basically previously it was using the mono "chat"/mono output on the headphones. Now with the ppa it's primarily using the "game"/stereo output. AFAIU the knob adjusts the mix between the two outputs on the headphones themselves. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1758736 Title: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback Status in pulseaudio package in Ubuntu: Confirmed Status in pulseaudio source package in Bionic: In Progress Status in pulseaudio source package in Cosmic: Confirmed Status in pulseaudio source package in Disco: Confirmed Bug description: There is not stereo playback only mono playback ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: pulseaudio 1:10.0-2ubuntu3.1 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio /dev/snd/controlC1: kaj1755 F pulseaudio /dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio /dev/snd/controlC0: kaj1755 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Sun Mar 25 21:30:50 2018 InstallationDate: Installed on 2018-03-08 (17 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1) SourcePackage: pulseaudio Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7 Symptom_PulsePlaybackTest: PulseAudio playback test failed Symptom_Type: No sound at all Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R06ET35W (1.09 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FMS2AV00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T460 dmi.product.name: 20FMS2AV00 dmi.product.version: ThinkPad T460 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
** Changed in: pulseaudio (Ubuntu Cosmic) Status: Confirmed => In Progress ** Changed in: pulseaudio (Ubuntu Disco) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1758736 Title: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback Status in pulseaudio package in Ubuntu: In Progress Status in pulseaudio source package in Bionic: In Progress Status in pulseaudio source package in Cosmic: In Progress Status in pulseaudio source package in Disco: In Progress Bug description: There is not stereo playback only mono playback ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: pulseaudio 1:10.0-2ubuntu3.1 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio /dev/snd/controlC1: kaj1755 F pulseaudio /dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio /dev/snd/controlC0: kaj1755 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Sun Mar 25 21:30:50 2018 InstallationDate: Installed on 2018-03-08 (17 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1) SourcePackage: pulseaudio Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7 Symptom_PulsePlaybackTest: PulseAudio playback test failed Symptom_Type: No sound at all Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R06ET35W (1.09 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FMS2AV00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T460 dmi.product.name: 20FMS2AV00 dmi.product.version: ThinkPad T460 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
I uploaded test packages for cosmic and disco to my ppa today. If someone with the headset could test either of those as well that would be awesome. I should be getting a headset here soon to test with. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1758736 Title: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback Status in pulseaudio package in Ubuntu: In Progress Status in pulseaudio source package in Bionic: In Progress Status in pulseaudio source package in Cosmic: In Progress Status in pulseaudio source package in Disco: In Progress Bug description: There is not stereo playback only mono playback ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: pulseaudio 1:10.0-2ubuntu3.1 ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13 Uname: Linux 4.13.0-37-generic x86_64 ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio /dev/snd/controlC1: kaj1755 F pulseaudio /dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio /dev/snd/controlC0: kaj1755 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Sun Mar 25 21:30:50 2018 InstallationDate: Installed on 2018-03-08 (17 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1) SourcePackage: pulseaudio Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7 Symptom_PulsePlaybackTest: PulseAudio playback test failed Symptom_Type: No sound at all Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/09/2016 dmi.bios.vendor: LENOVO dmi.bios.version: R06ET35W (1.09 ) dmi.board.asset.tag: Not Available dmi.board.name: 20FMS2AV00 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T460 dmi.product.name: 20FMS2AV00 dmi.product.version: ThinkPad T460 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
** Description changed:
+ [Impact]
+
+ * User is only able to get mono audio from steelseries headsets because
+ they provide both a stereo and mono output. PA selects the mono output
+ by default.
+
+ * This should be backported to stable releases because this fix is
+isolated to code that only applies to the affected headsets.
+Additionally other gaming headsets may be more easily enabled by adding
+ ATTRS{idVendor}=="", ATTRS{idProduct}=="",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
+to /lib/udev/rules.d/90-pulseaudio.rules now. Such as the Lucidsound
+LS31 which I own.
+
+ * The upload fixes the bug by conditionally setting a pulseaudio
+ profile for the headset based on specific usb vendor and product ids in
+ the udev rules.
+
+ [Test Case]
+
+ 1. Acquire headset.
+ 2. Open sound settings, and click test speakers.
+ 3. Only option available will be mono sound
+
+ [Regression Potential]
+
+ * Risk of regressions should be mitigated to those who own the headset.
+ In which case it is likely that their headset is already not working.
+
+ [Other Info]
+
+ * All patches originate from upstream pulseaudio, and are documented as
+such including the shas.
+
+ * I will be pursuing enabling other similar headsets in the coming weeks.
+ * I plan to work with upstream pulseaudio to enable my own headset and to
+also make the headset templates backported here more generic.
+
+
+ Original Description -
+
There is not stereo playback only mono playback
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: pulseaudio 1:10.0-2ubuntu3.1
ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13
Uname: Linux 4.13.0-37-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
AudioDevicesInUse:
- USERPID ACCESS COMMAND
- /dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio
- /dev/snd/controlC1: kaj1755 F pulseaudio
- /dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio
- /dev/snd/controlC0: kaj1755 F pulseaudio
+ USERPID ACCESS COMMAND
+ /dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio
+ /dev/snd/controlC1: kaj1755 F pulseaudio
+ /dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio
+ /dev/snd/controlC0: kaj1755 F pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Sun Mar 25 21:30:50 2018
InstallationDate: Installed on 2018-03-08 (17 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
SourcePackage: pulseaudio
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful
Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7
Symptom_PulsePlaybackTest: PulseAudio playback test failed
Symptom_Type: No sound at all
Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/09/2016
dmi.bios.vendor: LENOVO
dmi.bios.version: R06ET35W (1.09 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20FMS2AV00
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias:
dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T460
dmi.product.name: 20FMS2AV00
dmi.product.version: ThinkPad T460
dmi.sys.vendor: LENOVO
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1758736
Title:
[USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only
mono playback
Status in pulseaudio package in Ubuntu:
In Progress
Status in pulseaudio source package in Bionic:
In Progress
Status in pulseaudio source package in Cosmic:
In Progress
Status in pulseaudio source package in Disco:
In Progress
Bug description:
[Impact]
* User is only able to get mono audio from steelseries headsets
because they provide both a stereo and mono output. PA selects the
mono output by default.
* This should be backported to stable releases because this fix is
isolated to code that only applies to the affected headsets.
Additionally other gaming headsets may be more easily enabled by adding
ATTRS{idVendor}=="", ATTRS{idProduct}=="",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
to /lib/udev/rules.d/90-pulseaudio.rules now. Such as the Lucidsound
LS31 which I own.
* The upload fixes the bug by conditionally setting a pulseaudio
profile for the headset based on specific usb vendor and product ids
in the udev rules.
[Test Case]
1. Acquire headset.
2. Open sound settings, and cl
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
I uploaded the changes to disco this morning.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1758736
Title:
[USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only
mono playback
Status in pulseaudio package in Ubuntu:
In Progress
Status in pulseaudio source package in Bionic:
In Progress
Status in pulseaudio source package in Cosmic:
In Progress
Status in pulseaudio source package in Disco:
In Progress
Bug description:
[Impact]
* User is only able to get mono audio from steelseries headsets
because they provide both a stereo and mono output. PA selects the
mono output by default.
* This should be backported to stable releases because this fix is
isolated to code that only applies to the affected headsets.
Additionally other gaming headsets may be more easily enabled by adding
ATTRS{idVendor}=="", ATTRS{idProduct}=="",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
to /lib/udev/rules.d/90-pulseaudio.rules now. Such as the Lucidsound
LS31 which I own.
* The upload fixes the bug by conditionally setting a pulseaudio
profile for the headset based on specific usb vendor and product ids
in the udev rules.
[Test Case]
1. Acquire headset.
2. Open sound settings, and click test speakers.
3. Only option available will be mono sound
[Regression Potential]
* Risk of regressions should be mitigated to those who own the
headset. In which case it is likely that their headset is already not
working.
[Other Info]
* All patches originate from upstream pulseaudio, and are documented as
such including the shas.
* I will be pursuing enabling other similar headsets in the coming weeks.
* I plan to work with upstream pulseaudio to enable my own headset and to
also make the headset templates backported here more generic.
Original Description -
There is not stereo playback only mono playback
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: pulseaudio 1:10.0-2ubuntu3.1
ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13
Uname: Linux 4.13.0-37-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio
/dev/snd/controlC1: kaj1755 F pulseaudio
/dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio
/dev/snd/controlC0: kaj1755 F pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Sun Mar 25 21:30:50 2018
InstallationDate: Installed on 2018-03-08 (17 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
SourcePackage: pulseaudio
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful
Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7
Symptom_PulsePlaybackTest: PulseAudio playback test failed
Symptom_Type: No sound at all
Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/09/2016
dmi.bios.vendor: LENOVO
dmi.bios.version: R06ET35W (1.09 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20FMS2AV00
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias:
dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T460
dmi.product.name: 20FMS2AV00
dmi.product.version: ThinkPad T460
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1758736] Re: [USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only mono playback
I uploaded these changes for bionic and cosmic. Just waiting on sru
approval now.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1758736
Title:
[USB-Audio - SteelSeries Arctis 7, playback] No stereo playback only
mono playback
Status in pulseaudio package in Ubuntu:
Fix Released
Status in pulseaudio source package in Bionic:
In Progress
Status in pulseaudio source package in Cosmic:
In Progress
Status in pulseaudio source package in Disco:
Fix Released
Bug description:
[Impact]
* User is only able to get mono audio from steelseries headsets
because they provide both a stereo and mono output. PA selects the
mono output by default.
* This should be backported to stable releases because this fix is
isolated to code that only applies to the affected headsets.
Additionally other gaming headsets may be more easily enabled by adding
ATTRS{idVendor}=="", ATTRS{idProduct}=="",
ENV{PULSE_PROFILE_SET}="steelseries-arctis-7-usb-audio.conf"
to /lib/udev/rules.d/90-pulseaudio.rules now. Such as the Lucidsound
LS31 which I own.
* The upload fixes the bug by conditionally setting a pulseaudio
profile for the headset based on specific usb vendor and product ids
in the udev rules.
[Test Case]
1. Acquire headset.
2. Open sound settings, and click test speakers.
3. Only option available will be mono sound
[Regression Potential]
* Risk of regressions should be mitigated to those who own the
headset. In which case it is likely that their headset is already not
working.
[Other Info]
* All patches originate from upstream pulseaudio, and are documented as
such including the shas.
* I will be pursuing enabling other similar headsets in the coming weeks.
* I plan to work with upstream pulseaudio to enable my own headset and to
also make the headset templates backported here more generic.
Original Description -
There is not stereo playback only mono playback
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: pulseaudio 1:10.0-2ubuntu3.1
ProcVersionSignature: Ubuntu 4.13.0-37.42-generic 4.13.13
Uname: Linux 4.13.0-37-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/pcmC1D0p: kaj1755 F...m pulseaudio
/dev/snd/controlC1: kaj1755 F pulseaudio
/dev/snd/pcmC0D0c: kaj1755 F...m pulseaudio
/dev/snd/controlC0: kaj1755 F pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Sun Mar 25 21:30:50 2018
InstallationDate: Installed on 2018-03-08 (17 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
SourcePackage: pulseaudio
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:S7 successful
Symptom_Card: SteelSeries Arctis 7 - SteelSeries Arctis 7
Symptom_PulsePlaybackTest: PulseAudio playback test failed
Symptom_Type: No sound at all
Title: [USB-Audio - SteelSeries Arctis 7, playback] No sound at all
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/09/2016
dmi.bios.vendor: LENOVO
dmi.bios.version: R06ET35W (1.09 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20FMS2AV00
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias:
dmi:bvnLENOVO:bvrR06ET35W(1.09):bd03/09/2016:svnLENOVO:pn20FMS2AV00:pvrThinkPadT460:rvnLENOVO:rn20FMS2AV00:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T460
dmi.product.name: 20FMS2AV00
dmi.product.version: ThinkPad T460
dmi.sys.vendor: LENOVO
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1758736/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1670959] Re: systemd-resolved using 100% CPU
** Tags added: indeed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1670959
Title:
systemd-resolved using 100% CPU
Status in dnsmasq package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
Confirmed
Bug description:
Sometimes systemd-resolved process is using 100% CPU.
After a while it changes back to normal.
It happens usually after connecting to the (wifi) network, like
starting the OS.
strace output:
sendmsg(12, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33589),
sin_addr=inet_addr("127.0.0.1")},
msg_iov(1)=[{"6\215\201\200\0\1\0\1\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\300\f\0\34\0\1\0\0\10\235\0\20&\6(\0\0024\0Y%L\4\6#f&\214\0\0)\377\326\0\0\0\0\0\0",
81}], msg_controllen=28, [{cmsg_len=28, cmsg_level=SOL_IP,
cmsg_type=IP_PKTINFO, {ipi_ifindex=if_nametoindex("lo"),
ipi_spec_dst=inet_addr("127.0.0.53"), ipi_addr=inet_addr("127.0.0.53")}}],
msg_flags=0}, 0) = 81
sendmsg(3, {msg_name(0)=NULL,
msg_iov(4)=[{"PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=../src/resolve/resolved-dns-stub.c\nCODE_LINE=363\nCODE_FUNCTION=dns_stub_process_query\nSYSLOG_IDENTIFIER=systemd-resolved\n",
160}, {"MESSAGE=", 8}, {"Processing query...", 19}, {"\n", 1}],
msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 188
epoll_wait(4, [{EPOLLIN, {u32=3176459184, u64=94565471415216}}], 16, -1) = 1
clock_gettime(CLOCK_BOOTTIME, {44665, 938069872}) = 0
recvfrom(12, NULL, 0, MSG_PEEK|MSG_TRUNC, NULL, NULL) = 53
recvmsg(12, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33589),
sin_addr=inet_addr("127.0.0.1")},
msg_iov(1)=[{"Z\262\1\20\0\1\0\0\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\0\0)\2\0\0\0\0\0\0\0",
3936}], msg_controllen=56, [{cmsg_len=28, cmsg_level=SOL_IP,
cmsg_type=IP_PKTINFO, {ipi_ifindex=if_nametoindex("lo"),
ipi_spec_dst=inet_addr("127.0.0.53"), ipi_addr=inet_addr("127.0.0.53")}},
{cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, {ttl=64}}], msg_flags=0}, 0)
= 53
stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0
getrandom("\365I", 2, GRND_NONBLOCK)= 2
stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0
getrandom("\203;", 2, GRND_NONBLOCK)= 2
clock_gettime(CLOCK_BOOTTIME, {44665, 938446937}) = 0
open("/run/systemd/netif/links/3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0
stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 18
connect(18, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 18, {EPOLLIN, {u32=3176610576,
u64=94565471566608}}) = 0
write(18,
"\203;\1\20\0\1\0\0\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\0\0)\2\0\0\0\0\0\0\0",
53) = 53
clock_gettime(CLOCK_BOOTTIME, {44665, 938833717}) = 0
clock_gettime(CLOCK_BOOTTIME, {44665, 938875138}) = 0
epoll_ctl(4, EPOLL_CTL_DEL, 18, NULL) = 0
close(18) = 0
journalctl output:
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query...
Mar 08 08:25:41 parsec dnsmasq[1545]: Maximum number of concurrent DNS
queries reached (max: 150)
As you can see, I would use it together with dnsmasq.
ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: systemd 232-18ubuntu1
ProcVersionSignature: Ubuntu 4.10.0-9.11-generic 4.10.0
Uname: Linux 4.10.0-9-generic x86_64
NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
Date: Wed Mar 8 08:20:18 2017
MachineType: Hewlett-Packard HP EliteBook Folio 1020 G1
ProcEnviron:
LANGUAGE=en_US:en
TERM=xterm
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/zsh
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.10.0-9-generic
root=UUID=a54fe703-35d4-47ac-9c6e-4034421531fb ro rootflags=subvol=@
SourcePackage: systemd
UpgradeStatus: Upgraded to zesty on 2015-05-24 (653 days ago)
dmi.bios.date: 03/09/2015
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: M77 Ver. 01.05
dmi.board.name: 2271
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 91.4C
dmi.chassis.asset.tag: CNU51199KV
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias:
dmi:bvnHewlett-Packard:bvrM77Ver.01.05
[Touch-packages] [Bug 1723390] Re: lxd containers have become degraded
Same thing in bionic # journalctl -u systemd-hostnamed -- Logs begin at Wed 2018-02-28 16:43:47 UTC, end at Wed 2018-02-28 16:44:28 UTC. -- Feb 28 16:44:03 bionic systemd[1]: systemd-hostnamed.service: Failed to reset devices.list: Operation not permitted Feb 28 16:44:03 bionic systemd[1]: systemd-hostnamed.service: Failed to set invocation ID on control group /system.slice/systemd-hostnamed.service, ignoring: Ope Feb 28 16:44:03 bionic systemd[1]: Starting Hostname Service... Feb 28 16:44:03 bionic systemd[1]: systemd-hostnamed.service: Main process exited, code=exited, status=225/NETWORK Feb 28 16:44:03 bionic systemd[1]: systemd-hostnamed.service: Failed with result 'exit-code'. Feb 28 16:44:03 bionic systemd[1]: Failed to start Hostname Service. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1723390 Title: lxd containers have become degraded Status in systemd package in Ubuntu: Confirmed Bug description: 20170920 container boots degraded with Oct 13 10:09:28 test20170920 systemd[256]: systemd-hostnamed.service: Failed at step NETWORK spawning /lib/systemd/systemd-hostnamed: Permission denied 20170919 container boots non-degraded. Package list changes are insignificant. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1723390/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1723390] Re: lxd containers have become degraded
Verified kind of still exists with ubuntu 17.10 amd64 (daily) (20180227) # journalctl -u systemd-hostnamed.service -- Logs begin at Wed 2018-02-28 16:38:35 UTC, end at Wed 2018-02-28 16:39:16 UTC. -- Feb 28 16:38:51 pants systemd[1]: systemd-hostnamed.service: Failed to reset devices.list: Operation not permitted Feb 28 16:38:51 pants systemd[1]: systemd-hostnamed.service: Failed to set invocation ID on control group /system.slice/systemd-hostnamed.service, ig Feb 28 16:38:51 pants systemd[1]: Starting Hostname Service... Feb 28 16:38:51 pants systemd[1]: systemd-hostnamed.service: Main process exited, code=exited, status=225/NETWORK Feb 28 16:38:51 pants systemd[1]: Failed to start Hostname Service. Feb 28 16:38:51 pants systemd[1]: systemd-hostnamed.service: Unit entered failed state. Feb 28 16:38:51 pants systemd[1]: systemd-hostnamed.service: Failed with result 'exit-code'. However I'm not sure where @xnox saw the "degraded" status -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1723390 Title: lxd containers have become degraded Status in systemd package in Ubuntu: Confirmed Bug description: 20170920 container boots degraded with Oct 13 10:09:28 test20170920 systemd[256]: systemd-hostnamed.service: Failed at step NETWORK spawning /lib/systemd/systemd-hostnamed: Permission denied 20170919 container boots non-degraded. Package list changes are insignificant. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1723390/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
** Changed in: coreutils (Ubuntu Vivid) Status: New => In Progress ** Changed in: coreutils (Ubuntu Trusty) Status: New => In Progress ** Changed in: coreutils (Ubuntu Wily) Status: Fix Released => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Trusty: In Progress Status in coreutils source package in Vivid: In Progress Status in coreutils source package in Wily: Fix Released Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
** Changed in: coreutils (Ubuntu Wily) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Trusty: In Progress Status in coreutils source package in Vivid: In Progress Status in coreutils source package in Wily: Fix Released Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Moun
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
In case anyone is wondering. The patch does not cleanly apply against Trusty, and I'm working on a backport/appropriate cherrypick. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Trusty: In Progress Status in coreutils source package in Vivid: In Progress Status in coreutils source package in Wily: Fix Released Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
Here's the debdiff for trusty. The provenance of the patches are included in the header of the debian/patches. I've tested this patch on machines with the above issue as well as machines with varying configurations of disk mounts, and remote mounts even. ** Patch added: "trusty.debdiff" https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4513696/+files/lp1432871.trusty.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Trusty: In Progress Status in coreutils source package in Vivid: Fix Committed Status in coreutils source package in Wily: Fix Released Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mo
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
** Tags removed: verification-needed ** Tags added: verification-done-vivid verification-done-wily -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Trusty: In Progress Status in coreutils source package in Vivid: Fix Committed Status in coreutils source package in Wily: Fix Released Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Av
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
Thanks a ton mterry! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Trusty: In Progress Status in coreutils source package in Vivid: Fix Committed Status in coreutils source package in Wily: Fix Released Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
Subscribing sponsors and sru team, as both are still necessary for Trusty. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Trusty: In Progress Status in coreutils source package in Vivid: Fix Released Status in coreutils source package in Wily: Fix Released Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on
[Touch-packages] [Bug 1347788] Re: find crashed when current working directory is not readable and -exec or -execdir used
** Changed in: findutils (Ubuntu)
Assignee: (unassigned) => Dave Chiluk (chiluk)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to findutils in Ubuntu.
https://bugs.launchpad.net/bugs/1347788
Title:
find crashed when current working directory is not readable and -exec
or -execdir used
Status in findutils package in Ubuntu:
Confirmed
Bug description:
bug is similar to https://savannah.gnu.org/bugs/?15384 but for current
directory (when it not readable or not executable)
steps to reproduce
DIR=`mktemp -d`
cd $DIR
mkdir -p 1/1 2
cd 2
find $DIR/1 -type d -exec echo {} \;
find $DIR/1 -type d -execdir echo {} \;
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: findutils 4.4.2-7
Uname: Linux 3.15.4-031504-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: GNOME
Date: Wed Jul 23 20:17:19 2014
Dependencies:
gcc-4.9-base 4.9-20140406-0ubuntu1
libc6 2.19-0ubuntu6
libgcc1 1:4.9-20140406-0ubuntu1
multiarch-support 2.19-0ubuntu6
InstallationDate: Installed on 2014-04-24 (89 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
SourcePackage: findutils
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: GNOME
Dependencies:
gcc-4.9-base 4.9-20140406-0ubuntu1
libc6 2.19-0ubuntu6
libgcc1 1:4.9-20140406-0ubuntu1
multiarch-support 2.19-0ubuntu6
DistroRelease: Ubuntu 14.04
InstallationDate: Installed on 2014-04-24 (89 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
Package: findutils 4.4.2-7
PackageArchitecture: amd64
Tags: trusty
Uname: Linux 3.15.4-031504-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1347788/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1347788] Re: find crashed when current working directory is not readable and -exec or -execdir used
** Changed in: findutils (Ubuntu)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to findutils in Ubuntu.
https://bugs.launchpad.net/bugs/1347788
Title:
find crashed when current working directory is not readable and -exec
or -execdir used
Status in findutils package in Ubuntu:
Confirmed
Bug description:
bug is similar to https://savannah.gnu.org/bugs/?15384 but for current
directory (when it not readable or not executable)
steps to reproduce
DIR=`mktemp -d`
cd $DIR
mkdir -p 1/1 2
cd 2
find $DIR/1 -type d -exec echo {} \;
find $DIR/1 -type d -execdir echo {} \;
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: findutils 4.4.2-7
Uname: Linux 3.15.4-031504-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: GNOME
Date: Wed Jul 23 20:17:19 2014
Dependencies:
gcc-4.9-base 4.9-20140406-0ubuntu1
libc6 2.19-0ubuntu6
libgcc1 1:4.9-20140406-0ubuntu1
multiarch-support 2.19-0ubuntu6
InstallationDate: Installed on 2014-04-24 (89 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
SourcePackage: findutils
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: GNOME
Dependencies:
gcc-4.9-base 4.9-20140406-0ubuntu1
libc6 2.19-0ubuntu6
libgcc1 1:4.9-20140406-0ubuntu1
multiarch-support 2.19-0ubuntu6
DistroRelease: Ubuntu 14.04
InstallationDate: Installed on 2014-04-24 (89 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
Package: findutils 4.4.2-7
PackageArchitecture: amd64
Tags: trusty
Uname: Linux 3.15.4-031504-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1347788/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1347788] Re: find crashed when current working directory is not readable and -exec or -execdir used
I opened
https://savannah.gnu.org/bugs/index.php?46438
against upstream findutils to see if we can't get them to to a blessed release
of 4.5 of findutils.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to findutils in Ubuntu.
https://bugs.launchpad.net/bugs/1347788
Title:
find crashed when current working directory is not readable and -exec
or -execdir used
Status in findutils package in Ubuntu:
Confirmed
Bug description:
bug is similar to https://savannah.gnu.org/bugs/?15384 but for current
directory (when it not readable or not executable)
steps to reproduce
DIR=`mktemp -d`
cd $DIR
mkdir -p 1/1 2
cd 2
find $DIR/1 -type d -exec echo {} \;
find $DIR/1 -type d -execdir echo {} \;
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: findutils 4.4.2-7
Uname: Linux 3.15.4-031504-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: GNOME
Date: Wed Jul 23 20:17:19 2014
Dependencies:
gcc-4.9-base 4.9-20140406-0ubuntu1
libc6 2.19-0ubuntu6
libgcc1 1:4.9-20140406-0ubuntu1
multiarch-support 2.19-0ubuntu6
InstallationDate: Installed on 2014-04-24 (89 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
SourcePackage: findutils
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: GNOME
Dependencies:
gcc-4.9-base 4.9-20140406-0ubuntu1
libc6 2.19-0ubuntu6
libgcc1 1:4.9-20140406-0ubuntu1
multiarch-support 2.19-0ubuntu6
DistroRelease: Ubuntu 14.04
InstallationDate: Installed on 2014-04-24 (89 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
Package: findutils 4.4.2-7
PackageArchitecture: amd64
Tags: trusty
Uname: Linux 3.15.4-031504-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1347788/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1347788] Re: find crashed when current working directory is not readable and -exec or -execdir used
I also reviewed the upstream patch that purports to resolve the issue
(7dc7006). This fix is contained within the 4.5.9 and newer versions of
findutils. That's where the good news ends. The code portion of that
single commit is 817 lines long. It doesn't apply cleanly, and it
appears to have some significant dependencies on earlier commits.
Unfortunately backportting the fix into even wily sources is proving
difficult, and may not be acceptable for a stable release. Normally in
this case we would integrate the entire upstream sources into our
development series (xenial), and then pursue package copy into the older
series. However, 4.5.9 and newer is currently part of the findutils
alpha branch, and as such wouldn't be considered acceptable for
inclusion in even our development releases.
That being said fedora, opensuse, and centos all release with 4.5 of
findutils, so we may have to consider doing the same.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to findutils in Ubuntu.
https://bugs.launchpad.net/bugs/1347788
Title:
find crashed when current working directory is not readable and -exec
or -execdir used
Status in findutils package in Ubuntu:
Confirmed
Bug description:
bug is similar to https://savannah.gnu.org/bugs/?15384 but for current
directory (when it not readable or not executable)
steps to reproduce
DIR=`mktemp -d`
cd $DIR
mkdir -p 1/1 2
cd 2
find $DIR/1 -type d -exec echo {} \;
find $DIR/1 -type d -execdir echo {} \;
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: findutils 4.4.2-7
Uname: Linux 3.15.4-031504-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: GNOME
Date: Wed Jul 23 20:17:19 2014
Dependencies:
gcc-4.9-base 4.9-20140406-0ubuntu1
libc6 2.19-0ubuntu6
libgcc1 1:4.9-20140406-0ubuntu1
multiarch-support 2.19-0ubuntu6
InstallationDate: Installed on 2014-04-24 (89 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
SourcePackage: findutils
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: GNOME
Dependencies:
gcc-4.9-base 4.9-20140406-0ubuntu1
libc6 2.19-0ubuntu6
libgcc1 1:4.9-20140406-0ubuntu1
multiarch-support 2.19-0ubuntu6
DistroRelease: Ubuntu 14.04
InstallationDate: Installed on 2014-04-24 (89 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
Package: findutils 4.4.2-7
PackageArchitecture: amd64
Tags: trusty
Uname: Linux 3.15.4-031504-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1347788/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
Fix ftbfs on tests/df/total-unprocessed.sh Apparently the buildds are running with a slightly different environment than my local build machine which is causing this test to fail due to smart quotes in the set LANG. Explicitly setting LANG=C appears to resolve this. ** Patch added: "fixftbfs.debdiff" https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4520226/+files/fixftbfs.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Trusty: Fix Committed Status in coreutils source package in Vivid: Fix Released Status in coreutils source package in Wily: Fix Released Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
** Patch removed: "fixftbfs.debdiff" https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4520226/+files/fixftbfs.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Trusty: Fix Committed Status in coreutils source package in Vivid: Fix Released Status in coreutils source package in Wily: Fix Released Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind)
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
Alright so even though the buildds seem to be getting false failures, I did find a regression in the recent build. I'm going to work through that, and possibly open up a new bug for it, at least for vivid, wily, and xenial. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Trusty: Fix Committed Status in coreutils source package in Vivid: Fix Released Status in coreutils source package in Wily: Fix Released Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw)
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
So the regression I discovered was actually just behavior change. Due to the change to /proc/self/mountinfo the filesystem type is now more explicit. In this case that means that nfs mounts are now labeled nfs4. Additionally I discovered that the test that is now failing was previously being skipped because df was not able to read mount entries on trusty *(which is now fixed in this bug). I'm still working through traces and building tests packages in a ppa to get more output. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Trusty: Fix Committed Status in coreutils source package in Vivid: Fix Released Status in coreutils source package in Wily: Fix Released Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on m
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
This same patch applies cleanly to both wily and vivid, but it has wily in the changelog. ** Patch added: "lp1432871.wily.debdiff" https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4482367/+files/lp1432871.wily.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Incomplete Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - This is a change of behavior from precise * Explanation - This patch checks to see if the source directory of a mount is contains the destination directory of the mount it's replacing *(check if it's bind mount from the original directory). [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is not upstream, and will not be upstreamed *(see other info) * df command could stop working if I wrote the patch poorly. df might not process mounts correctly. [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and likely significantly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. * Theoretically df, mount and a number of other commands could be modified to run ioctl commands to determine if the mount is from a root inode of the mounted filesystem to determine preference, but that is really more of an upstream exercise. Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Incomplete Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - This is a change of behavior from precise * Explanation - This patch checks to see if the source directory of a mount is contains the destination directory of the mount it's replacing *(check if it's bind mount from the original directory). [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+subscriptions -- Mailing list: http
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
** Description changed: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - This is a change of behavior from precise * Explanation - This patch checks to see if the source directory of a mount is contains the destination directory of the mount it's replacing *(check if it's bind mount from the original directory). [Test Case] * $ mount - 192.168.1.2:/raid on /raid type nfs + 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] - * Patch is not upstream, and will not be upstreamed *(see other info) + * Patch is upstreamed. - * df command could stop working if I wrote the patch poorly. df might - not process mounts correctly. + * df command now relies on /proc/self/mountinfo [Other Info] - * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and likely significantly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. - * Theoretically df, mount and a number of other commands could be modified to run ioctl commands to determine if the mount is from a root inode of the mounted filesystem to determine preference, but that is really more of an upstream exercise. + * The behavior of df, mount and similar number of other commands has + changed going forward. Previously these commands all processed + /etc/mtab which was maintained by the mount command. Going forward they + still process /etc/mtab, but this is simply a symlink to /proc/mounts + now which is maintained by the kernel and slightly more accurate. + Unlike the mount command, the kernel makes no distinction between bind + mounts and normal mounts. This is evident by the fact that you can + mount a device, bind mount from that device, and then unmount the + original mount. The default behavior of df in this case is to simply + pick the mounted directory for a device that is the shortest since it + has no other information to go on from /proc/mounts. Moving to using + /proc/self/mountinfo resolves this issue, and is what upstream is doing + moving forward. Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid ** Description changed: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. - * justification - This is a change of behavior from precise + * justification - When trusty moved to using /proc/mounts this changed + behavior from precise. Additionally it doesn't make sense that a bind + mount should show up in df over a real root mount. - * Explanation - This patch checks to see if the source directory of a - mount is contains the destination directory of the mount it's replacing - *(check if it's bind mount from the original directory). + * Explanation - These patches change behavior of df to rely on
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
** Description changed: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. + * In order to solve this issue, I have written patches and got them integrated upstream. + gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and + coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 + have been authored by me. + + While attempting to push these patches into Ubuntu, it became apparent + that our version of coreutils does not contain the requisite patches to + correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more + complete information than /proc/self/mounts which /etc/mtab now points + to. Using /proc/self/mountinfo is the upstream way of doing things, and + it allows us to resolve this specific bug. + + Patches required in order to support /proc/self/mountinfo are. + Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git + commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 + commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 + commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 + commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 + + Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git + commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid -- You received this bug notification because you are a member of Ubuntu Tou
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
** Changed in: coreutils (Ubuntu) Status: Incomplete => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: In Progress Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized o
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
** Changed in: coreutils (Ubuntu Vivid) Assignee: (unassigned) => Dave Chiluk (chiluk) ** Changed in: coreutils (Ubuntu Trusty) Assignee: (unassigned) => Dave Chiluk (chiluk) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: In Progress Status in coreutils source package in Trusty: New Status in coreutils source package in Vivid: New Status in coreutils source package in Wily: In Progress Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - When trusty moved to using /proc/mounts this changed behavior from precise. Additionally it doesn't make sense that a bind mount should show up in df over a real root mount. * Explanation - These patches change behavior of df to rely on /proc/self/mountinfo which has more complete info than /proc/mounts. Such as what directory of the filesystem was used as the source of the mount. Additionally given this new information there is a patch on df itself to make use of this new information. [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is upstreamed. * df command now relies on /proc/self/mountinfo [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and slightly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. Moving to using /proc/self/mountinfo resolves this issue, and is what upstream is doing moving forward. * In order to solve this issue, I have written patches and got them integrated upstream. gnulib commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe and coreutils commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9 have been authored by me. While attempting to push these patches into Ubuntu, it became apparent that our version of coreutils does not contain the requisite patches to correctly support /proc/self/mountinfo. /proc/self/mountinfo gives more complete information than /proc/self/mounts which /etc/mtab now points to. Using /proc/self/mountinfo is the upstream way of doing things, and it allows us to resolve this specific bug. Patches required in order to support /proc/self/mountinfo are. Origin: upstream, gnulib - http://git.savannah.gnu.org/gitweb/?p=gnulib.git commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3ea43e02541ece750ffc6cd1dfe34195421b4ef3 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2768ceb7994506e2cfba88be3b6bd13ef5440a90 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=de1cbdd48244c66c51a3e2bc1594ac3ad32ce038 commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=3fb6e360363744462ce15c381f0b116c6fc4ce82 Origin: upstream, coreutils - http://git.savannah.gnu.org/gitweb/?p=coreutils.git commit: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=1b1c40e1d6f8cf30b6c7c9d31bbddbc3d5cc72e6 Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bin
[Touch-packages] [Bug 1154431] Re: Unity doesn't start up
This no longer looks to be an issue in 14.04+ so I'm going to close this out as won't fix. ** Changed in: nvidia-graphics-drivers (Ubuntu) Status: Confirmed => Won't Fix ** Changed in: unity (Ubuntu) Status: Confirmed => Won't Fix ** Changed in: unity Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity in Ubuntu. https://bugs.launchpad.net/bugs/1154431 Title: Unity doesn't start up Status in Unity: Fix Released Status in nvidia-graphics-drivers package in Ubuntu: Won't Fix Status in unity package in Ubuntu: Won't Fix Bug description: I'm running stock 13.04. Previously I was affected by bug 982889. Now that X comes up, I don't see unity - no common toolbar on the top, no icons on the left side, no unity in the process list. ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: xorg 1:7.7+1ubuntu4 ProcVersionSignature: Ubuntu 3.8.0-12.21-generic 3.8.2 Uname: Linux 3.8.0-12-generic x86_64 NonfreeKernelModules: nvidia .proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 304.84 Wed Feb 27 04:58:49 PST 2013 GCC version: gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-22ubuntu3) .tmp.unity.support.test.0: ApportVersion: 2.9.1-0ubuntu1 Architecture: amd64 CompizPlugins: [core,bailer,detection,composite,opengl,decor,mousepoll,vpswitch,regex,animation,snap,expo,move,compiztoolbox,place,grid,imgpng,gnomecompat,wall,ezoom,workarounds,resize,fade,unitymtgrabhandles,scale,session,unityshell] CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true Date: Wed Mar 13 10:34:40 2013 DistUpgraded: Fresh install DistroCodename: raring DistroVariant: ubuntu DkmsStatus: nvidia-304, 304.84, 3.8.0-12-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: NVIDIA Corporation G86 [GeForce 8400 GS] [10de:0422] (rev a1) (prog-if 00 [VGA controller]) Subsystem: eVga.com. Corp. Device [3842:c733] InstallationDate: Installed on 2013-02-01 (39 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha amd64+mac (20130130) MachineType: Intel To be filled by O.E.M. MarkForUpload: True ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-12-generic root=UUID=0084a9a5-74cd-47ba-afe6-a47d02d0b262 ro quiet splash SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/29/2009 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.3 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: To be filled by O.E.M. dmi.board.vendor: Intel dmi.board.version: To be filled by O.E.M. dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.3:bd10/29/2009:svnIntel:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnIntel:rnTobefilledbyO.E.M.:rvrTobefilledbyO.E.M.:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.name: To be filled by O.E.M. dmi.product.version: To be filled by O.E.M. dmi.sys.vendor: Intel version.compiz: compiz 1:0.9.9~daily13.03.08-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.42-0ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 9.0.2-0ubuntu1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 9.0.2-0ubuntu1 version.nvidia-graphics-drivers: nvidia-graphics-drivers N/A version.xserver-xorg-core: xserver-xorg-core 2:1.13.2-0ubuntu3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.1.0-0ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.21.4-0ubuntu1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.6-0ubuntu3 xserver.bootTime: Wed Mar 13 10:17:21 2013 xserver.configfile: default xserver.errors: open /dev/dri/card0: No such file or directory open /dev/dri/card0: No such file or directory open /dev/fb0: No such file or directory xserver.logfile: /var/log/Xorg.0.log xserver.outputs: xserver.version: 2:1.13.2-0ubuntu3 To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1154431/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1432871] Re: `df` shows bind mounts instead of real mounts.
** Patch removed: "lp1432871.trusty.debdiff" https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+attachment/4447737/+files/lp1432871.trusty.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1432871 Title: `df` shows bind mounts instead of real mounts. Status in coreutils package in Ubuntu: Incomplete Bug description: [Impact] * df displays bind mounts instead of "real" mounts if the bind mount is mounted to a shorter directory. * justification - This is a change of behavior from precise * Explanation - This patch checks to see if the source directory of a mount is contains the destination directory of the mount it's replacing *(check if it's bind mount from the original directory). [Test Case] * $ mount 192.168.1.2:/raid on /raid type nfs /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid [Regression Potential] * Patch is not upstream, and will not be upstreamed *(see other info) * df command could stop working if I wrote the patch poorly. df might not process mounts correctly. [Other Info] * The behavior of df, mount and similar number of other commands has changed going forward. Previously these commands all processed /etc/mtab which was maintained by the mount command. Going forward they still process /etc/mtab, but this is simply a symlink to /proc/mounts now which is maintained by the kernel and likely significantly more accurate. Unlike the mount command, the kernel makes no distinction between bind mounts and normal mounts. This is evident by the fact that you can mount a device, bind mount from that device, and then unmount the original mount. The default behavior of df in this case is to simply pick the mounted directory for a device that is the shortest since it has no other information to go on from /proc/mounts. * Theoretically df, mount and a number of other commands could be modified to run ioctl commands to determine if the mount is from a root inode of the mounted filesystem to determine preference, but that is really more of an upstream exercise. Original bug. Depending on mount path length df sometimes prioritizes showing bind mounts over real mounts for example. $ mount 192.168.1.2:/raid on /raid type nfs (rw,nosuid,nodev,noexec,vers=4,addr=192.168.1.2,clientaddr=192.168.1.3) /dev/sdc5 on /data type ext4 (rw) /data/a on /a type none (rw,bind) /raid/temp on /b type none (rw,bind) $df Filesystem 1K-blocks Used Available Use% Mounted on /data/a 449830616 229975284 196982196 54% /a /raid/temp 7752072192 5581343744 1780023296 76% /b I'd expect to see the real mount prioritized over the bind mount. Like so. $df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdc5449830616 229975284 196982196 54% /data 192.168.1.2:/raid 7752072192 5581438976 1779929088 76% /raid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1432871/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1674680] Re: Deprecated rfcomm.conf still mentioned
** Tags added: sts-sponsor-chiluk -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: New Bug description: [Impact] * The package contains misleading documentation mentioning the use of /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config file has been dropped after 14.04 release. I have directly received a question about it from a user mislead by the documentation. * Additionally deprecated -f option is still used in legacy upstart /etc/init/bluetooth.conf. Actually this does not seem longer required due to upstart being removed. [Test Case] * Install bluez. * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, /usr/share/doc/bluez/README.Debian.gz [Regression Potential] * This is mostly a documentation correction, however if somebody still depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly some kind of upstart compatibility in systemd, is that even possible?) he/she may end up with bluetooth not being started. This seems highly unlikely. [Other Info] * Original bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1674680] Re: Deprecated rfcomm.conf still mentioned
Just so you know I'm waiting for zesty release before uploading this. I don't want to risk causing issues on the release media. Additionally policy is to only push high priority bug fixes for the few weeks leading up to release. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: New Bug description: [Impact] * The package contains misleading documentation mentioning the use of /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config file has been dropped after 14.04 release. I have directly received a question about it from a user mislead by the documentation. * Additionally deprecated -f option is still used in legacy upstart /etc/init/bluetooth.conf. Actually this does not seem longer required due to upstart being removed. [Test Case] * Install bluez. * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, /usr/share/doc/bluez/README.Debian.gz [Regression Potential] * This is mostly a documentation correction, however if somebody still depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly some kind of upstart compatibility in systemd, is that even possible?) he/she may end up with bluetooth not being started. This seems highly unlikely. [Other Info] * Original bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay
@jan-huebner Please educate yourself about the stable release process and development process https://wiki.ubuntu.com/StableReleaseUpdates https://wiki.ubuntu.com/UbuntuDevelopment A regression was discovered in another component. This is the reason for the delay. This is very uncommon, but also the entire reason for the SRU process. If you are capable of contributing in a development manner, I will gladly mentor you or help find a mentor for you. Contributing solutions is the best way to help speed fixes for which you may care about in the open-source world. As it sounds as though you are using in production in a mission critical application perhaps you'd consider financially supporting the project by purchasing a support contract, or donating when you download. https://buy.ubuntu.com/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1591411 Title: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay Status in D-Bus: Unknown Status in systemd: Unknown Status in dbus package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in dbus source package in Xenial: Fix Committed Status in systemd source package in Xenial: Invalid Status in dbus source package in Yakkety: Fix Committed Status in systemd source package in Yakkety: Invalid Bug description: [Impact] The bug affects multiple users and introduces an user visible delay (~25 seconds) on SSH connections after a large number of sessions have been processed. This has a serious impact on big systems and servers running our software. The currently proposed fix is actually a safe workaround for the bug as proposed by the dbus upstream. The workaround makes uid 0 immune to the pending_fd_timeout limit that kicks in and causes the original issue. [Test Case] lxc launch ubuntu:x test lxc exec test -- login -f ubuntu ssh-import-id Then ran a script as follows (passing in ubuntu@): while [ 1 ]; do (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log done Then checking the log file if there are any ssh sessions that are taking 25+ seconds to complete. Multiple instances of the same script can be used at the same time. [Regression Potential] The fix has a rather low regression potential as the workaround is a very small change only affecting one particular case - handling of uid 0. The fix has been tested by multiple users and has been around in zesty for a while, with multiple people involved in reviewing the change. It's also a change that has been proposed by upstream. [Original Description] I noticed on a system that accepts large numbers of SSH connections that after awhile, SSH sessions were taking ~25 seconds to complete. Looking in /var/log/auth.log, systemd-logind starts failing with the following: Jun 10 23:55:28 test sshd[3666]: pam_unix(sshd:session): session opened for user ubuntu by (uid=0) Jun 10 23:55:28 test systemd-logind[105]: New session c1052 of user ubuntu. Jun 10 23:55:28 test systemd-logind[105]: Failed to abandon session scope: Transport endpoint is not connected Jun 10 23:55:28 test sshd[3666]: pam_systemd(sshd:session): Failed to create session: Message recipient disconnected from message bus without replying I reproduced this in an LXD container by doing something like: lxc launch ubuntu:x test lxc exec test -- login -f ubuntu ssh-import-id Then ran a script as follows (passing in ubuntu@): while [ 1 ]; do (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log done In my case, after 1052 logins, the 1053rd and thereafter were taking 25+ seconds to complete. Here are some snippets from the log file: $ cat log | grep 0m0 | wc -l 1052 $ cat log | grep 0m25 | wc -l 4 $ tail -5 log real 0m0.222s real 0m25.232s real 0m25.235s real 0m25.236s real 0m25.239s ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: systemd 229-4ubuntu5 ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Sat Jun 11 00:09:34 2016 MachineType: Notebook W230SS ProcEnviron: TERM=xterm-256color PATH=(custom, no user) ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-22-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/15/2014 dmi.bios.vendor: American Megatrends
[Touch-packages] [Bug 1660388] Re: Window decorator corruption
Uploading jpg a second time so it's obvious, and not missed in the maas of auto-uploaded logs. ** Attachment added: "Awesome example of decorator corruption." https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-367/+bug/1660388/+attachment/4810973/+files/corruption.jpg -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1660388 Title: Window decorator corruption Status in mesa package in Ubuntu: New Status in nvidia-graphics-drivers-367 package in Ubuntu: New Status in unity package in Ubuntu: New Bug description: After switching back from another user or after lock screen I occasionally get corruption. This usually takes a few weeks after a restart to reproduce. Might be related to nvidia drivers or mesa, or compiz, or something else. Experienced this before recent update to mesa 12.0.6, so I don't think this is a mesa regression. Decorations shown in jpg move with window, but are not selectable. Opening against unity, as the unity taskbar often shares similar corruption. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: unity 7.4.0+16.04.20160906-0ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-34.36~16.04.1-generic 4.8.11 Uname: Linux 4.8.0-34-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia .proc.driver.nvidia.gpus..03.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:03:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 367.57 Mon Oct 3 20:37:01 PDT 2016 GCC version: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) .tmp.unity_support_test.0: ApportVersion: 2.20.1-0ubuntu2.5 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 CurrentDesktop: Unity Date: Mon Jan 30 10:54:45 2017 DistUpgraded: Fresh install DistroCodename: xenial DistroVariant: ubuntu GraphicsCard: NVIDIA Corporation Device [10de:1c03] (rev a1) (prog-if 00 [VGA controller]) Subsystem: eVga.com. Corp. Device [3842:6163] InstallationDate: Installed on 2016-01-15 (380 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160115) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-34-generic root=UUID=029afe58-00c3-4872-9556-b3fd990c5cf1 ro quiet splash crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y crashkernel=384M-:128M SourcePackage: unity UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/06/2013 dmi.bios.vendor: Intel Corp. dmi.bios.version: SIX7910J.86A.0594.2013.0806.2241 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: DX79SI dmi.board.vendor: Intel Corporation dmi.board.version: AAG28808-500 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrSIX7910J.86A.0594.2013.0806.2241:bd08/06/2013:svn:pn:pvr:rvnIntelCorporation:rnDX79SI:rvrAAG28808-500:cvn:ct3:cvr: version.compiz: compiz 1:0.9.12.2+16.04.20160823-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.70-1~ubuntu16.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 12.0.6-0ubuntu0.16.04.1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 12.0.6-0ubuntu0.16.04.1 version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20160325-1ubuntu1.2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12-1build2 xserver.bootTime: Mon Jan 9 00:41:06 2017 xserver.configfile: default xserver.errors: open /dev/fb0: No such file or directory xserver.logfile: /var/log/Xorg.0.log xserver.outputs: xserver.version: 2:1.18.4-0ubuntu0.2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1660388/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1660388] [NEW] Window decorator corruption
Public bug reported: After switching back from another user or after lock screen I occasionally get corruption. This usually takes a few weeks after a restart to reproduce. Might be related to nvidia drivers or mesa, or compiz, or something else. Experienced this before recent update to mesa 12.0.6, so I don't think this is a mesa regression. Decorations shown in jpg move with window, but are not selectable. Opening against unity, as the unity taskbar often shares similar corruption. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: unity 7.4.0+16.04.20160906-0ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-34.36~16.04.1-generic 4.8.11 Uname: Linux 4.8.0-34-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia .proc.driver.nvidia.gpus..03.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:03:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 367.57 Mon Oct 3 20:37:01 PDT 2016 GCC version: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) .tmp.unity_support_test.0: ApportVersion: 2.20.1-0ubuntu2.5 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 CurrentDesktop: Unity Date: Mon Jan 30 10:54:45 2017 DistUpgraded: Fresh install DistroCodename: xenial DistroVariant: ubuntu GraphicsCard: NVIDIA Corporation Device [10de:1c03] (rev a1) (prog-if 00 [VGA controller]) Subsystem: eVga.com. Corp. Device [3842:6163] InstallationDate: Installed on 2016-01-15 (380 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160115) ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-34-generic root=UUID=029afe58-00c3-4872-9556-b3fd990c5cf1 ro quiet splash crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y crashkernel=384M-:128M SourcePackage: unity UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/06/2013 dmi.bios.vendor: Intel Corp. dmi.bios.version: SIX7910J.86A.0594.2013.0806.2241 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: DX79SI dmi.board.vendor: Intel Corporation dmi.board.version: AAG28808-500 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrSIX7910J.86A.0594.2013.0806.2241:bd08/06/2013:svn:pn:pvr:rvnIntelCorporation:rnDX79SI:rvrAAG28808-500:cvn:ct3:cvr: version.compiz: compiz 1:0.9.12.2+16.04.20160823-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.70-1~ubuntu16.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 12.0.6-0ubuntu0.16.04.1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 12.0.6-0ubuntu0.16.04.1 version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20160325-1ubuntu1.2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12-1build2 xserver.bootTime: Mon Jan 9 00:41:06 2017 xserver.configfile: default xserver.errors: open /dev/fb0: No such file or directory xserver.logfile: /var/log/Xorg.0.log xserver.outputs: xserver.version: 2:1.18.4-0ubuntu0.2 ** Affects: mesa (Ubuntu) Importance: Undecided Status: New ** Affects: nvidia-graphics-drivers-367 (Ubuntu) Importance: Undecided Status: New ** Affects: unity (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug compiz-0.9 possible-manual-nvidia-install third-party-packages ubuntu xenial ** Attachment added: "jpg of example decorator corruption" https://bugs.launchpad.net/bugs/1660388/+attachment/4810946/+files/corruption.jpg ** Also affects: mesa (Ubuntu) Importance: Undecided Status: New ** Also affects: nvidia-graphics-drivers-367 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1660388 Title: Window decorator corruption Status in mesa package in Ubuntu: New Status in nvidia-graphics-drivers-367 package in Ubuntu: New Status in unity package in Ubuntu: New Bug description: After switching back from another user or after lock screen I occasionally get corruption. This usually takes a few weeks after a restart to reproduce. Might be related to nvidia drivers or mesa, or compiz, or something else. Experienced this before recent update to mesa 12.0.6, so I don't think this is a mesa regression. Decorations shown in jpg move with window, but are not
[Touch-packages] [Bug 1674680] Re: Deprecated rfcomm.conf still mentioned
** Also affects: bluez (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: bluez (Ubuntu Yakkety) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: New Bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1674680] Re: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README
** Also affects: bluez (Ubuntu Artful) Importance: Low Status: New ** Tags removed: sts-sponsor-chiluk -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: Won't Fix Status in bluez source package in Artful: New Status in bluez package in Debian: New Bug description: [Impact] * The package contains misleading documentation mentioning the use of /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config file has been dropped after 14.04 release. I have directly received a question about it from a user mislead by the documentation. * Additionally deprecated -f option is still used in legacy upstart /etc/init/bluetooth.conf. Actually this does not seem longer required due to upstart being removed. [Test Case] * Install bluez. * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, /usr/share/doc/bluez/README.Debian.gz [Regression Potential] * This is mostly a documentation correction, however if somebody still depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly some kind of upstart compatibility in systemd, is that even possible?) he/she may end up with bluetooth not being started. This seems highly unlikely. [Other Info] * Original bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1674680] Re: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README
Sponsored artful. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1674680 Title: Deprecated rfcomm.conf still mentioned in bluetooth.conf and README Status in bluez package in Ubuntu: New Status in bluez source package in Xenial: New Status in bluez source package in Yakkety: Won't Fix Status in bluez source package in Artful: New Status in bluez package in Debian: New Bug description: [Impact] * The package contains misleading documentation mentioning the use of /etc/bluetooth/rfcomm.conf for rfcomm setup while the support for config file has been dropped after 14.04 release. I have directly received a question about it from a user mislead by the documentation. * Additionally deprecated -f option is still used in legacy upstart /etc/init/bluetooth.conf. Actually this does not seem longer required due to upstart being removed. [Test Case] * Install bluez. * Look for misleading rfcomm.conf mentions in /etc/init/bluetooth.conf, /usr/share/doc/bluez/README.Debian.gz [Regression Potential] * This is mostly a documentation correction, however if somebody still depends bluetooth started with Ubuntu 16.04+ by upstart (or possibly some kind of upstart compatibility in systemd, is that even possible?) he/she may end up with bluetooth not being started. This seems highly unlikely. [Other Info] * Original bug description: Support for config files has been dropped upstream in 2012 (however version shipped with Trusty still supports it), but the latest versions (including Xenial and Zesty) still mention it in the docs and in the legacy /etc/init/bluetooth.conf file. Additionally the /etc/init/bluetooth.conf don't seem necessary these days. In fact it has been dropped by Debian already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1674680/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1690512] Re: shutdown/restart/suspend freezes laptop on intel graphics
Please try the latest hwe stack by. I'm using kabylake + the hwe stack without issue at the moment. sudo apt install --install-recommends linux-generic-hwe-16.04 xserver- xorg-hwe-16.04 More info is available here. https://wiki.ubuntu.com/Kernel/LTSEnablementStack I'm also closing the intel-microcode track of this bug as at the moment this does not appear to be hwe related. Thank you, ** Changed in: intel-microcode (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1690512 Title: shutdown/restart/suspend freezes laptop on intel graphics Status in intel-microcode package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in xorg package in Ubuntu: New Bug description: I'm not sure where to report this under, so please bear with me. Reporting this bug using ubuntu-bug just crashes my system if im using intel graphics, I had to switch to nvidia graphics just to file this bug report so the automatically attached log files may not be a good representation of the problem. I've attached the syslog and kern.log files below. PROBLEM: When using intel graphics: Whenever I close the laptop lid or restart / shutdown using GUI or terminal commands, it goes into a black screen with a single "_" at the top left corner, and hangs. Only long-pressing (hard reset) the power button would shut down the computer. However, when I use sudo prime-select nvidia to switch over to nvidia, everything works fine.log I have tried many things, and all do not work. I have attached the logs for /var/log/syslog and /var/log/kern.log below. Attempts so far: 1)Tried installing new intel drivers from Updated kernel to 4.8 now missing firmware warnings --> Did not work. Issue persists 2) Tried upgrading kernel from 4.8 to 4.10.15 --> Did not work. Problem got worse. Instead of the normal login screen, it gives a terminal login screen and hangs. 3) Tried the fix to nvidia-prime https://askubuntu.com/a/884506/547039, but both the poweron.sh and poweroff.sh script hangs my laptop instead. 4) Tried sudo swapoff -a && systemctl poweroff as a workaround, no avail. 5) Tried changing GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" to GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=force" Does not work either. Additional note: 'sudo lshw -C display' on intel graphics outputs PCI(sysfs) then laptop freezes. LOG FILES: /var/log/syslog https://codeshare.io/5XOPwM /var/log/kern.log https://codeshare.io/aJp6nq specs: Intel 7700HQ, NVIDIA 1060GTX, kernel 4.8, Ubuntu 16.04 Would really appreciate your help. Thank you! ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: xorg 1:7.7+13ubuntu3 ProcVersionSignature: Ubuntu 4.8.0-51.54~16.04.1-generic 4.8.17 Uname: Linux 4.8.0-51-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 381.22 Thu May 4 00:55:03 PDT 2017 GCC version: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) .tmp.unity_support_test.0: ApportVersion: 2.20.1-0ubuntu2.5 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 CurrentDesktop: Unity Date: Sat May 13 17:06:20 2017 DistUpgraded: Fresh install DistroCodename: xenial DistroVariant: ubuntu DkmsStatus: bbswitch, 0.8, 4.4.0-77-generic, x86_64: installed bbswitch, 0.8, 4.8.0-49-generic, x86_64: installed bbswitch, 0.8, 4.8.0-51-generic, x86_64: installed nvidia-381, 381.22, 4.8.0-51-generic, x86_64: installed EcryptfsInUse: Yes ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation Device [8086:591b] (rev 04) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device [1558:65a1] NVIDIA Corporation Device [10de:1c20] (rev a1) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device [1558:65a1] InstallationDate: Installed on 2017-03-30 (43 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 04f2:b5a7 Chicony Electronics Co., Ltd Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bus 001 Device 002: ID 0483:374b STMicroelectronics ST-LINK/V2.1 (Nucleo-F103RB) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Aftershock P65xHP ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-51-generic root=/
[Touch-packages] [Bug 1458204] Re: removing kernels should not require a restart afterward
** Tags added: indeed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1458204 Title: removing kernels should not require a restart afterward Status in unattended-upgrades: New Status in update notifier: New Status in linux package in Ubuntu: Confirmed Status in unattended-upgrades package in Ubuntu: Confirmed Status in update-notifier package in Ubuntu: Confirmed Status in linux source package in Artful: Confirmed Status in unattended-upgrades source package in Artful: Confirmed Status in update-notifier source package in Artful: Confirmed Bug description: 1. Perform a kernel upgrade normally via "apt-get dist-upgrade". 2. Reboot. 3. Run "apt-get autoremove" to delete the old kernel packages. 4. "System Notification Helper" now reports that the computer requires a reboot. The "autoremove" operation shouldn't require a reboot, logically speaking, because it's just removing files that are unused by the OS. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: apt 1.0.1ubuntu2.7 ProcVersionSignature: Ubuntu 3.13.0-53.89-generic 3.13.11-ckt19 Uname: Linux 3.13.0-53-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: KDE Date: Sat May 23 12:47:15 2015 InstallationDate: Installed on 2013-08-31 (629 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) SourcePackage: apt UpgradeStatus: Upgraded to trusty on 2014-04-26 (391 days ago) --- ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: KDE DistroRelease: Ubuntu 14.04 HibernationDevice: RESUME=UUID=66f11ff7-00bb-4452-9168-003cf9078308 InstallationDate: Installed on 2013-08-31 (632 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) MachineType: System manufacturer System Product Name Package: linux (not installed) ProcFB: 0 nouveaufb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-53-generic root=UUID=02741f1f-8107-4a0f-b9a6-31ef470b1389 ro libata.force=noncq quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 3.13.0-53.89-generic 3.13.11-ckt19 RelatedPackageVersions: linux-restricted-modules-3.13.0-53-generic N/A linux-backports-modules-3.13.0-53-generic N/A linux-firmware 1.127.12 RfKill: Tags: trusty Uname: Linux 3.13.0-53-generic x86_64 UpgradeStatus: Upgraded to trusty on 2014-04-26 (395 days ago) UserGroups: adm cdrom dialout dip fuse lightdm lpadmin plugdev sambashare sudo WifiSyslog: _MarkForUpload: True dmi.bios.date: 08/12/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4210 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: P9X79 dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4210:bd08/12/2013:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP9X79:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion: dmi.product.name: System Product Name dmi.product.version: System Version dmi.sys.vendor: System manufacturer To manage notifications about this bug go to: https://bugs.launchpad.net/unattended-upgrades/+bug/1458204/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1307109] Re: Alcor Micro AU9540 keeps powering down when card is present
** Changed in: pcsc-lite (Ubuntu) Assignee: Kip Warner (kip) => Dariusz Gadomski (dgadomski) ** Changed in: pcsc-lite (Ubuntu) Assignee: Dariusz Gadomski (dgadomski) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pcsc-lite in Ubuntu. https://bugs.launchpad.net/bugs/1307109 Title: Alcor Micro AU9540 keeps powering down when card is present Status in “pcsc-lite” package in Ubuntu: Confirmed Bug description: I have smart card reader built-into this laptop, however, whenever I insert a card - it'll read it for a few seconds, then the USB connection to the reader gets powered down and thus the card disappears in the systems eyes. After a few seconds, it comes back and everything's happy. Then the cycle repeats again and again and again. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: linux-image-3.13.0-23-generic 3.13.0-23.45 [modified: boot/vmlinuz-3.13.0-23-generic] ProcVersionSignature: Ubuntu 3.13.0-23.45-generic 3.13.8 Uname: Linux 3.13.0-23-generic x86_64 ApportVersion: 2.14.1-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: jpds 3933 F pulseaudio /dev/snd/controlC0: jpds 3933 F pulseaudio CurrentDesktop: Unity Date: Sun Apr 6 18:37:24 2014 HibernationDevice: RESUME=UUID=05490d4c-6800-46a1-b5ba-8b32bdc57e89 InstallationDate: Installed on 2014-04-06 (0 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140406) MachineType: Hewlett-Packard HP EliteBook Folio 1040 G1 ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-23-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-3.13.0-23-generic N/A linux-backports-modules-3.13.0-23-generic N/A linux-firmware 1.127 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/09/2014 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: L83 Ver. 01.05 dmi.board.name: 213E dmi.board.vendor: Hewlett-Packard dmi.board.version: KBC Version 24.2A dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnHewlett-Packard:bvrL83Ver.01.05:bd02/09/2014:svnHewlett-Packard:pnHPEliteBookFolio1040G1:pvrA3009DD18303:rvnHewlett-Packard:rn213E:rvrKBCVersion24.2A:cvnHewlett-Packard:ct10:cvr: dmi.product.name: HP EliteBook Folio 1040 G1 dmi.product.version: A3009DD18303 dmi.sys.vendor: Hewlett-Packard To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/1307109/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
1. So this indicates to me that the kernel is unable to control the usb device. When you mentioned earlier that you were able to investigate the usb-c device with a 16.04.1 machine, what exact kernel version was that machine running. uname -a output should be sufficient. 2. Can you similarly provide the exact kernel version that you are using during commissioning, when dropped to shell? 3. Were you able to utilize the device under this kernel or did it simply load the kernel driver there as well? I.e. do you see a device for the usb device in /sys/class/net/? 4. Also can you please provide the lsusb -vv output from that machine as well. I'd like to look up the device id's against the cdc_ether driver to see if the device id was added to one of the later 4.4 kernels. 5. Also are you using stable images or daily images. If you haven't done so already can you enable the daily images, and check using those? Instructions are available here http://maas.io/docs/en/installconfig-images The images I'm referring to are available here https://images.maas.io/ephemeral-v2/daily/ Thank you, -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
One of my collegues informed me that maas 2.1 is meant to use https://images.maas.io/ephemeral-v3/daily/ Instead of the ephemeral-v2 images. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
Alright so the problem at present appears to be that the machine is pxe booting off of a nic with a mac address that is not showing up after the kernel boots. The way the boot works is the bios/efi launches a pxe network stack. This typically makes a dhcp request. The DHCP server responds with an IP address, and the address of the PXE/TFTP server *(in this case the maas server). The network stack firmware on the client then requests the kernel, initramfs and kernel arguments from the PXE server. The bios/efi pxe network stack then downloads this, and executes the kernel. One of the arguments maas is responding with BOOTIF=01-9c- eb-e8-3c-52-cc. This means the original pxe request originates from this mac address. When the initramfs starts it runs a script function called configure_networking that attempts to set up the BOOTIF=01-9c- eb-e8-3c-52-cc NIC, but it doesn't appear to exist to the OS. This could mean a few things. - The NIC doing the initial pxe request is different than the usb-c one. Is there a chance that there's a wireless nic that has a pxe stack that you've configured? I know some newer machines are able to pxe boot off of their network cards so this would be useful to check. - The mac address is changing between the pxe request and the OS boot. - IPv6 is in the mix. Are you attempting to boot via ipv6? - The PXE server is responding with the incorrect mac address in BOOTIF. The last two can be checked by looking at /var/log/rackd.log on your maas server. You should be able to grep for 01-9c-eb-e8-3c-52-cc or 01-84-7b-eb-55-c1-95 in the rackd.log to see which nic is making the pxe request. If 01-9c-eb-e8-3c-52-cc shows up in the rackd.log then it's pretty definitive that the issue is booting using a nic with that mac somehow. Please check the above and let me know what you discover. Thanks, Dave. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
Do you know where the 9c-eb-e8-3c-52-cc originates from? There is nothing we can do so long as the request to maas originates from the 9c- eb-e8-3c-52-cc mac address. If the firmware is somehow masking the actual mac address with the above then that needs to be fixed in the firmware, or via a firmware setting. Please attempt to figure out where the 9c-eb-e8-3c-52-cc is. If it helps a mac search on 9c-eb-e8 yeilds: BizLink (Kunshan) Co. Ltd. A mac search of 84-7b-eb yeilds Dell Inc. I suspect they are really the same device. I have a feeling the usb-c adapter or docking station you are using is really just Bizlink device that Dell has rebranded. This really looks like a firmware bug, where the firmware uses the non- rebranded mac of the device for pxe while in efi, and the rebranded mac address in the OS after boot. Have you tried updating the firmware on your machine, and possibly also the firmware of the usb-c device? Thanks, Dave Chiluk -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
Another thought is that the pxe firmware of the usb-c device was missed in the rebranding process by dell. This is actually quite likely in my opinion. Either way we need to engage Dell in order to remedy this. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
So apparently this is a feature of the dell-branded usb-c devices. Please see the knowledge base. http://www.dell.com/support/article/us/en/04/SLN301147 I've heard back from our contacts at dell, and the issue you are seeing is apparently resolved via a firmware update. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1639202] Re: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter
** Changed in: initramfs-tools (Ubuntu) Status: New => Invalid ** Changed in: maas-images Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1639202 Title: Cannot enlist/commission machines in MAAS 2.1 with usb network adapter Status in MAAS: Invalid Status in maas-images: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Bug description: After upgrade from MAAS 2.0 to MAAS 2.1: Cannot enlist/commission client machines via network boot (or pre- staging machine) when using usb-c network adapter D59GG (e.g. Precision 5510). This was working ok with MAAS 2.0. Using the Xenial 16.04 base image for enlist/commission (no minimum kernel set). Enlist/Commission/Deploy works fine with other laptop and desktop models which have a built in NIC. From an already deployed Precision 5510 system (16.04.1) I can see the following module is loaded when the usb-c adapter is connected (and working): $ lsmod usbnet45056 1 cdc_ether Errors received on client during enlisting with MAAS: no /run/net-bootif.conf lvmetad is not activated ...invalid path for logical volume. gave up waiting for root device common problems: boot args (cat /proc/cmdline) check rootdelay = (did system wait long enough) check root = (did the system wait for the right device?) missing modules (cat /proc/modules) ALERT! /dev/disk/by-path/ip-:3260-iscsi-iqn,2004.05.com.ubuntu:maas:ephemeral-ubuntu-amd64-generic-xenial-daily-lun-1 does not exist. Dropping to shell! usbcore: registered new interface driver usbhid usbhid: USB HID core driver - cat /proc/cmdline shows mac address that of usb-c network adapter. - cat /proc/modules includes “usbnet 45056 cdc_ether, Live 0xc009c000” - cat /proc/modules | grep usb … includes “ usbnet 45056 and usbhid 49152” I've tried enlisting with older boot image and different kernel versions (14.04 and 16.04 with ga-16.04, hwe-16.04 set) but get the same problem. It seems like the usb-c network adapter isn't loading properly or maybe just not quickly enough? Please let me know if you require any more info. I can provide info from /var/log/maas/* and dpkg -l '*maas*'|cat if need be. To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1639202/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1626166] Re: lvm2 not starting lvm2-lvmetad on package install
** Description changed: [Impact] - * On Xenial after installing lvm2, you must reboot before you are able to run vgcreate. - * The package installer should be starting lvmetad.service. - * $ sudo vgcreate localvg - /run/lvm/lvmetad.socket: connect failed: No such file or directory - WARNING: Failed to connect to lvmetad. Falling back to internal scanning. - Please enter a physical volume path. - Run `vgcreate --help' for more information. + * On Xenial after installing lvm2, you must reboot before you are able to run vgcreate. + * The package installer should be starting lvmetad.service. + * $ sudo vgcreate localvg + /run/lvm/lvmetad.socket: connect failed: No such file or directory + WARNING: Failed to connect to lvmetad. Falling back to internal scanning. + Please enter a physical volume path. + Run `vgcreate --help' for more information. [Test Case] - * Running the below commands result in the following error. - -$ sudo apt install lvm2 -$ sudo pvcreate /dev/sdb1 -$ sudo vgcreate localvg - /run/lvm/lvmetad.socket: connect failed: No such file or directory - WARNING: Failed to connect to lvmetad. Falling back to internal scanning. - Please enter a physical volume path. - Run `vgcreate --help' for more information. + * Running the below commands result in the following error. + + $ sudo apt install lvm2 + $ sudo pvcreate /dev/sdb1 + $ sudo vgcreate localvg /dev/sdb1 + /run/lvm/lvmetad.socket: connect failed: No such file or directory + WARNING: Failed to connect to lvmetad. Falling back to internal scanning. + Please enter a physical volume path. + Run `vgcreate --help' for more information. [Regression Potential] - * Solution TBD, opening the bug so I don't forget this in the midst of + * Solution TBD, opening the bug so I don't forget this in the midst of a sprint. - * discussion of how regressions are most likely to manifest as a result + * discussion of how regressions are most likely to manifest as a result of this change. - * It is assumed that any SRU candidate patch is well-tested before -upload and has a low overall risk of regression, but it's important -to make the effort to think about what ''could'' happen in the -event of a regression. + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the + event of a regression. - * This both shows the SRU team that the risks have been considered, -and provides guidance to testers in regression-testing the SRU. + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in regression-testing the SRU. [Other Info] - - * Anything else you think is useful to include - * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board - * and address these questions in advance + + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1626166 Title: lvm2 not starting lvm2-lvmetad on package install Status in lvm2 package in Ubuntu: Confirmed Status in lvm2 source package in Xenial: Triaged Bug description: [Impact] * On Xenial after installing lvm2, you must reboot before you are able to run vgcreate. * The package installer should be starting lvmetad.service. * $ sudo vgcreate localvg /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. Please enter a physical volume path. Run `vgcreate --help' for more information. [Test Case] * Running the below commands result in the following error. $ sudo apt install lvm2 $ sudo pvcreate /dev/sdb1 $ sudo vgcreate localvg /dev/sdb1 /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. Please enter a physical volume path. Run `vgcreate --help' for more information. [Regression Potential] * Solution TBD, opening the bug so I don't forget this in the midst of a sprint. * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to tes
[Touch-packages] [Bug 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay
@Lukasz Looking good so far. Appears resolved with 1.10.6-1ubuntu3.2. Thanks, Dave. ** Tags removed: verification-needed ** Tags added: verification-done ** Tags removed: verification-done ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1591411 Title: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay Status in D-Bus: Unknown Status in systemd: Unknown Status in dbus package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in dbus source package in Xenial: Fix Committed Status in systemd source package in Xenial: Invalid Status in dbus source package in Yakkety: Fix Committed Status in systemd source package in Yakkety: Invalid Bug description: [Impact] The bug affects multiple users and introduces an user visible delay (~25 seconds) on SSH connections after a large number of sessions have been processed. This has a serious impact on big systems and servers running our software. The currently proposed fix is actually a safe workaround for the bug as proposed by the dbus upstream. The workaround makes uid 0 immune to the pending_fd_timeout limit that kicks in and causes the original issue. [Test Case] lxc launch ubuntu:x test lxc exec test -- login -f ubuntu ssh-import-id Then ran a script as follows (passing in ubuntu@): while [ 1 ]; do (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log done Then checking the log file if there are any ssh sessions that are taking 25+ seconds to complete. Multiple instances of the same script can be used at the same time. [Regression Potential] The fix has a rather low regression potential as the workaround is a very small change only affecting one particular case - handling of uid 0. The fix has been tested by multiple users and has been around in zesty for a while, with multiple people involved in reviewing the change. It's also a change that has been proposed by upstream. [Original Description] I noticed on a system that accepts large numbers of SSH connections that after awhile, SSH sessions were taking ~25 seconds to complete. Looking in /var/log/auth.log, systemd-logind starts failing with the following: Jun 10 23:55:28 test sshd[3666]: pam_unix(sshd:session): session opened for user ubuntu by (uid=0) Jun 10 23:55:28 test systemd-logind[105]: New session c1052 of user ubuntu. Jun 10 23:55:28 test systemd-logind[105]: Failed to abandon session scope: Transport endpoint is not connected Jun 10 23:55:28 test sshd[3666]: pam_systemd(sshd:session): Failed to create session: Message recipient disconnected from message bus without replying I reproduced this in an LXD container by doing something like: lxc launch ubuntu:x test lxc exec test -- login -f ubuntu ssh-import-id Then ran a script as follows (passing in ubuntu@): while [ 1 ]; do (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log done In my case, after 1052 logins, the 1053rd and thereafter were taking 25+ seconds to complete. Here are some snippets from the log file: $ cat log | grep 0m0 | wc -l 1052 $ cat log | grep 0m25 | wc -l 4 $ tail -5 log real 0m0.222s real 0m25.232s real 0m25.235s real 0m25.236s real 0m25.239s ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: systemd 229-4ubuntu5 ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Sat Jun 11 00:09:34 2016 MachineType: Notebook W230SS ProcEnviron: TERM=xterm-256color PATH=(custom, no user) ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-22-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/15/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.5 dmi.board.asset.tag: Tag 12345 dmi.board.name: W230SS dmi.board.vendor: Notebook dmi.board.version: Not Applicable dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: Notebook dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd04/15/2014:svnNotebook:pnW230SS:pvrNotApplicable:rvnNotebook:rnW230SS:rvrNotApplicable:cvnNotebook:ct9:cvrN/A: dmi.product.name: W230SS dmi.product.version: Not Applicable dmi.sys.vendor: Notebook To manage notifications about this bug
[Touch-packages] [Bug 1626166] Re: lvm2 not starting lvm2-lvmetad on package install
I just installed yakkety, and got a similar result. All of the cloud- images and maas images have lvm2 already built in, so this would not be seen there. $ sudo vgcreate localvg Command failed with status code 5. I installed yakkety like this. #!/bin/bash virt-install \ --connect qemu:///system \ --virt-type kvm \ --name yakketylvm \ --ram 2048 \ --disk pool=VMs,size=10 \ --graphics vnc \ -l ftp://ftp.utexas.edu/pub/ubuntu/dists/yakkety/main/installer-amd64/ \ --os-variant ubuntu16.04 ** Changed in: lvm2 (Ubuntu) Status: Fix Released => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1626166 Title: lvm2 not starting lvm2-lvmetad on package install Status in lvm2 package in Ubuntu: Confirmed Status in lvm2 source package in Xenial: Triaged Bug description: [Impact] * On Xenial after installing lvm2, you must reboot before you are able to run vgcreate. * The package installer should be starting lvmetad.service. * $ sudo vgcreate localvg /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. Please enter a physical volume path. Run `vgcreate --help' for more information. [Test Case] * Running the below commands result in the following error. $ sudo apt install lvm2 $ sudo pvcreate /dev/sdb1 $ sudo vgcreate localvg /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. Please enter a physical volume path. Run `vgcreate --help' for more information. [Regression Potential] * Solution TBD, opening the bug so I don't forget this in the midst of a sprint. * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1626166/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1626166] Re: lvm2 not starting lvm2-lvmetad on package install
I actually also tested this on recent cloud-images of yakkety, and I'm seeing the same thing. That may be a separate issue though as reboot does not fix it there. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1626166 Title: lvm2 not starting lvm2-lvmetad on package install Status in lvm2 package in Ubuntu: Confirmed Status in lvm2 source package in Xenial: Triaged Bug description: [Impact] * On Xenial after installing lvm2, you must reboot before you are able to run vgcreate. * The package installer should be starting lvmetad.service. * $ sudo vgcreate localvg /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. Please enter a physical volume path. Run `vgcreate --help' for more information. [Test Case] * Running the below commands result in the following error. $ sudo apt install lvm2 $ sudo pvcreate /dev/sdb1 $ sudo vgcreate localvg /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. Please enter a physical volume path. Run `vgcreate --help' for more information. [Regression Potential] * Solution TBD, opening the bug so I don't forget this in the midst of a sprint. * discussion of how regressions are most likely to manifest as a result of this change. * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1626166/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
** Tags added: regression-update -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1631474 Title: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option Status in initramfs-tools package in Ubuntu: New Bug description: initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments. Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured. The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set. AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
Dediff from 8.2 to 8.3. http://launchpadlibrarian.net/286956415/initramfs-tools_0.122ubuntu8.2_0.122ubuntu8.3.diff.gz ** Tags added: cpc sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1631474 Title: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option Status in initramfs-tools package in Ubuntu: New Bug description: initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments. Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured. The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set. AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
** Changed in: initramfs-tools (Ubuntu) Assignee: (unassigned) => Dave Chiluk (chiluk) ** Changed in: initramfs-tools (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1631474 Title: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option Status in initramfs-tools package in Ubuntu: In Progress Bug description: initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments. Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured. The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set. AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631436] Re: Some network configuration cmdline arguments doesn't work anymore with version 0.122ubuntu8.3
*** This bug is a duplicate of bug 1631474 *** https://bugs.launchpad.net/bugs/1631474 Marking as duplicate of 1631474 as I'm already working this over there. Normally we'd dupe the newer against the older, but I'm already working over there, and I don't want to lose history in the switch. ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => High ** Changed in: initramfs-tools (Ubuntu) Assignee: (unassigned) => Dave Chiluk (chiluk) ** This bug has been marked a duplicate of bug 1631474 No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1631436 Title: Some network configuration cmdline arguments doesn't work anymore with version 0.122ubuntu8.3 Status in initramfs-tools package in Ubuntu: Confirmed Bug description: In the past, until the version 0.122ubuntu8.1, we used the syntax "ip=:eth0:dhcp" as described in the kernel's documentation : https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt The version 0.122ubuntu8.3 breaks it. It works only with "ip=eth0" syntax as far as i have tested it. So, the current last package version leaves the machine without network on boot. Any host that needs network on boot (nfsroot / using dropbear for example) might not boot properly. Regards To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631436/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
I created a PPA with a proposed solution to this issue. If I could get some testing with this ppa I would appreciate it. Additionally if you test the ppa please report back and include your /proc/cmdline in your comment. Thank you, Dave Chiluk -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1631474 Title: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: New Bug description: initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments. Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured. The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set. AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
Woops I forgot to include the PPA https://launchpad.net/~chiluk/+archive/ubuntu/lp1631474 I will remove this ppa when the package hits -proposed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1631474 Title: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: New Bug description: initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments. Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured. The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set. AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
** Patch added: "lp1631474.xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+attachment/4757065/+files/lp1631474.xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1631474 Title: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: New Bug description: initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments. Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured. The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set. AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
** Patch removed: "lp1631474.xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+attachment/4757065/+files/lp1631474.xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1631474 Title: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: New Bug description: initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments. Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured. The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set. AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
I fixed up the comment, and the changelog comment and resubmit the debdiff. ** Patch added: "lp1631474.xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+attachment/4757083/+files/lp1631474.xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1631474 Title: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: New Bug description: initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments. Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured. The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set. AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
** Patch added: "lp1631474.yakkety.debdiff" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+attachment/4757084/+files/lp1631474.yakkety.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1631474 Title: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: New Bug description: initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments. Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured. The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set. AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
** Description changed:
+ [Impact]
+
+ * 0.122ubuntu8.3 of initramfs-tools no longer correctly processed
+ ip=dhcp or ip=:eth0:dhcp
+
+ * Regression-updates
+
+ * The fix better parses the ip= command line argument.
+
+ [Test Case]
+
+ * Create a machine that boots using an nfsroot.
+
+ * Use ip=:eth0:dhcp on the kernel command line. To set up
+networking.
+
+ * Discover that the device never comes up because, networking is not
+ conifgured correctly.
+
+ [Regression Potential]
+
+ * Regressions potential is limited to machines using
+ ip={""|*|on|any|dhcp} on the kernel command line. As this is
+ already broken regression potential is minimal.
+
+ [Other Info]
+
+ * There are a number of other issues in this code base that are not solved
by this fix.
+ * The networking configuration does not strictly follow the kernel
documentation as described
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This
should be fixed.
+
+ Original Bug Description Follows==
+
initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
networking is not initialized when the boot option "ip=dhcp" is
provided. We are seeing this problem in AWS, but cannot confirm if this
issue is specific to AWS or will occur with different hardware or in
different environments.
Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in
networking being configured.
The issue does not occur with 0.122ubuntu8.2 or previous versions when
"ip=dhcp" is set.
AWS has no console so debugging is not a trivial task. I do have a
console log with some output, and will update this bug shortly with it.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1631474
Title:
No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot
option
Status in initramfs-tools package in Ubuntu:
In Progress
Status in initramfs-tools source package in Xenial:
New
Bug description:
[Impact]
* 0.122ubuntu8.3 of initramfs-tools no longer correctly processed
ip=dhcp or ip=:eth0:dhcp
* Regression-updates
* The fix better parses the ip= command line argument.
[Test Case]
* Create a machine that boots using an nfsroot.
* Use ip=:eth0:dhcp on the kernel command line. To set up
networking.
* Discover that the device never comes up because, networking is not
conifgured correctly.
[Regression Potential]
* Regressions potential is limited to machines using
ip={""|*|on|any|dhcp} on the kernel command line. As this is
already broken regression potential is minimal.
[Other Info]
* There are a number of other issues in this code base that are not solved
by this fix.
* The networking configuration does not strictly follow the kernel
documentation as described
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This
should be fixed.
Original Bug Description Follows==
initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
networking is not initialized when the boot option "ip=dhcp" is
provided. We are seeing this problem in AWS, but cannot confirm if
this issue is specific to AWS or will occur with different hardware or
in different environments.
Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results
in networking being configured.
The issue does not occur with 0.122ubuntu8.2 or previous versions when
"ip=dhcp" is set.
AWS has no console so debugging is not a trivial task. I do have a
console log with some output, and will update this bug shortly with
it.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1631436] Re: Some network configuration cmdline arguments doesn't work anymore with version 0.122ubuntu8.3
*** This bug is a duplicate of bug 1631474 *** https://bugs.launchpad.net/bugs/1631474 I'd really appreciate if you tested the ppa available in bug 1631474, and reported back. I don't have access to a full nfsroot environment so this would be very helpful. Also, Please move back to the ip=:eth0:dhcp, as this should be working once more. IP=eth0, is an undocumented behavior, and ip=:eth0:dhcp should be more universally accepted. Thanks, Dave -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1631436 Title: Some network configuration cmdline arguments doesn't work anymore with version 0.122ubuntu8.3 Status in initramfs-tools package in Ubuntu: Confirmed Bug description: In the past, until the version 0.122ubuntu8.1, we used the syntax "ip=:eth0:dhcp" as described in the kernel's documentation : https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt The version 0.122ubuntu8.3 breaks it. It works only with "ip=eth0" syntax as far as i have tested it. So, the current last package version leaves the machine without network on boot. Any host that needs network on boot (nfsroot / using dropbear for example) might not boot properly. Regards To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631436/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
