[Touch-packages] [Bug 2037667] Re: Regression on Jammy's kernel 5.15 when creating ip6gre and vti6 tunnels
Testing with that commit reverted, it works. Testing on a 6.5 kernel on jammy fails. When testing on mantic, it works. When testing on mantic, on an lxc jammy container, it fails inside the container, with that same kernel. So, it looks like systemd-networkd sets up the Local tunnel address as the IFLA_ADDR, and the Remote tunnel address as the IFLA_BROADCAST netlink attributes. This is what the validation from commit b0ad3c179059 is trying to validate. Those attributes are supposed to be hardware addresses, not the tunnel addresses. This needs to be investigated on the systemd side. As I read the systemd code from the jammy version, I didn't find where this would be incorrectly set. It may be necessary to revert this kernel code, fix systemd, and wait for some time before reintroducing this kernel fix. That all depends on why exactly systemd is doing this. Depending on the resulting investigation, we will need to reassess if this can be reasonably be used to revert that commit upstream. But given newer systemd does the right thing, it might be hard to do it. Cascardo. ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Invalid ** Changed in: linux (Ubuntu Jammy) Importance: Undecided => High ** Changed in: systemd (Ubuntu Jammy) Importance: Undecided => High ** Changed in: linux (Ubuntu Jammy) Status: Confirmed => Triaged ** Changed in: linux (Ubuntu Jammy) Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo) -- 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/2037667 Title: Regression on Jammy's kernel 5.15 when creating ip6gre and vti6 tunnels Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Status in linux source package in Jammy: Triaged Status in systemd source package in Jammy: New Bug description: We noticed that some of Netplan's integration tests started to fail on Jammy. These tests will try to create ip6gre and vti6 virtual interfaces and systemd-networkd is failing to create them starting on kernel 5.15.0-83.92. As far as I can tell, kernel 5.15.0-82.91 is the last revision where it works. So, some change between 5.15.0-82.91 and 5.15.0-83.92 is causing this regression. How to reproduce the issue: # Launch a jammy cloud VM: lxc launch images:ubuntu/jammy/cloud jammy --vm lxc shell jammy # Create a netplan file that creates 2 tunnels: cat > /etc/netplan/10-tun.yaml <http://ie.archive.ubuntu.com/ubuntu/pool/main/l/linux-signed/linux-image-5.15.0-82-generic_5.15.0-82.91_amd64.deb http://ie.archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-modules-5.15.0-82-generic_5.15.0-82.91_amd64.deb dpkg -i *.deb grub-reboot '1>2' && reboot # Check with "ip link" again that both tun0 and tun1 were created # Reboot again to go back to the most recent kernel and check with "ip link" that both tun0 and tun1 were not created. --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Sep 29 12:52 seq crw-rw 1 root audio 116, 33 Sep 29 12:52 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: [Errno 2] No such file or directory: 'fuser' CRDA: N/A CasperMD5CheckResult: unknown CloudArchitecture: x86_64 CloudID: lxd CloudName: lxd CloudPlatform: lxd CloudSubPlatform: LXD socket API v. 1.0 (/dev/lxd/sock) DistroRelease: Ubuntu 22.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lspci: Error: [Errno 2] No such file or directory: 'lspci' Lspci-vt: Error: [Errno 2] No such file or directory: 'lspci' Lsusb: Error: [Errno 2] No such file or directory: 'lsusb' Lsusb-t: Error: [Errno 2] No such file or directory: 'lsusb' Lsusb-v: Error: [Errno 2] No such file or directory: 'lsusb' MachineType: QEMU Standard PC (Q35 + ICH9, 2009) Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=screen-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 virtio_gpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-84-generic root=/dev/sda2 ro quiet splash console=tty1 console=ttyS0 vt.handoff=7 ProcVersionSignature: Ubuntu 5.15.0-84.93-generic 5.15.116 RelatedPackageVersions: linux-restricted-modules-5.15.0-84-generic N/A linux-backports-modules-5.15.0-84-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'r
[Touch-packages] [Bug 1923618] Re: upgrading systemd on groovy terminates sessions
This was the upgrade in question. Aptitude 0.8.12: log report Tue, Apr 13 2021 10:34:25 -0300 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 16 packages, and remove 0 packages. 7168 B of disk space will be used [HOLD, DEPENDENCIES] grub-common:amd64 2.04-1ubuntu35.4 [HOLD, DEPENDENCIES] grub-efi-amd64-bin:amd64 2.04-1ubuntu35.4 [HOLD, DEPENDENCIES] grub-pc:amd64 2.04-1ubuntu35.4 [HOLD, DEPENDENCIES] grub-pc-bin:amd64 2.04-1ubuntu35.4 [HOLD, DEPENDENCIES] grub2-common:amd64 2.04-1ubuntu35.4 [HOLD, DEPENDENCIES] libseccomp2:amd64 2.4.3-1ubuntu4 [HOLD, DEPENDENCIES] linux-firmware:amd64 1.190.3 [HOLD] grub-efi-amd64-signed:amd64 1.155.4+2.04-1ubuntu35.4 [UPGRADE] alsa-ucm-conf:amd64 1.2.2-1ubuntu5.1 -> 1.2.2-1ubuntu5.2 [UPGRADE] apt:amd64 2.1.10ubuntu0.2 -> 2.1.10ubuntu0.3 [UPGRADE] apt-utils:amd64 2.1.10ubuntu0.2 -> 2.1.10ubuntu0.3 [UPGRADE] libapt-pkg6.0:amd64 2.1.10ubuntu0.2 -> 2.1.10ubuntu0.3 [UPGRADE] libnss-mymachines:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 [UPGRADE] libnss-systemd:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 [UPGRADE] libpam-systemd:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 [UPGRADE] libsystemd-dev:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 [UPGRADE] libsystemd0:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 [UPGRADE] libudev-dev:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 [UPGRADE] libudev1:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 [UPGRADE] systemd:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 [UPGRADE] systemd-container:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 [UPGRADE] systemd-sysv:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 [UPGRADE] systemd-timesyncd:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 [UPGRADE] udev:amd64 246.6-1ubuntu1.2 -> 246.6-1ubuntu1.3 -- 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/1923618 Title: upgrading systemd on groovy terminates sessions Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Groovy: Incomplete Bug description: Whenever I upgrade systemd on my groovy system, my gnome session is terminated. This is very annoying, as everything that was running on that session is terminated. NetworkManager also stops running. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1923618/+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 1923618] [NEW] upgrading systemd on groovy terminates sessions
Public bug reported: Whenever I upgrade systemd on my groovy system, my gnome session is terminated. This is very annoying, as everything that was running on that session is terminated. NetworkManager also stops running. ** Affects: systemd (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/1923618 Title: upgrading systemd on groovy terminates sessions Status in systemd package in Ubuntu: New Bug description: Whenever I upgrade systemd on my groovy system, my gnome session is terminated. This is very annoying, as everything that was running on that session is terminated. NetworkManager also stops running. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1923618/+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 1923618] Re: upgrading systemd on groovy terminates sessions
Hey, Dan. Thanks for looking into this. I am attaching a journal log from the time I got the failure. Cascardo. ** Attachment added: "journalctl output" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1923618/+attachment/5490397/+files/systemd_upgrade.log -- 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/1923618 Title: upgrading systemd on groovy terminates sessions Status in systemd package in Ubuntu: Incomplete Status in systemd source package in Groovy: Incomplete Bug description: Whenever I upgrade systemd on my groovy system, my gnome session is terminated. This is very annoying, as everything that was running on that session is terminated. NetworkManager also stops running. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1923618/+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 1818243] [NEW] systemd-logind takes 25s to stop when rebooting
Public bug reported: During reboot: Mar 01 14:15:52 P8lpar5 systemd[1]: Stopping Login Service... [...] Mar 01 14:16:17 P8lpar5 systemd-logind[2756]: Failed to abandon session scope, ignoring: Connection timed out Mar 01 14:16:17 P8lpar5 systemd-logind[2756]: Session 5 logged out. Waiting for processes to exit. Mar 01 14:16:17 P8lpar5 dbus-daemon[2855]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout= 25000ms) Mar 01 14:16:17 P8lpar5 systemd[1]: Stopped Login Service. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Cosmic) 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/1818243 Title: systemd-logind takes 25s to stop when rebooting Status in systemd package in Ubuntu: New Status in systemd source package in Cosmic: New Bug description: During reboot: Mar 01 14:15:52 P8lpar5 systemd[1]: Stopping Login Service... [...] Mar 01 14:16:17 P8lpar5 systemd-logind[2756]: Failed to abandon session scope, ignoring: Connection timed out Mar 01 14:16:17 P8lpar5 systemd-logind[2756]: Session 5 logged out. Waiting for processes to exit. Mar 01 14:16:17 P8lpar5 dbus-daemon[2855]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout= 25000ms) Mar 01 14:16:17 P8lpar5 systemd[1]: Stopped Login Service. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818243/+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 1778844] Re: nvme multipath does not report path relationships
That's an OOM problem. Just increase the reserved crashkernel memory size and test again, please. -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: Won't Fix Status in initramfs-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: In Progress Status in linux source package in Bionic: Invalid Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: In Progress Status in linux source package in Cosmic: Invalid Status in makedumpfile source package in Cosmic: Invalid Status in initramfs-tools source package in Disco: In Progress Status in linux source package in Disco: Invalid Status in makedumpfile source package in Disco: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a
[Touch-packages] [Bug 1819747] [NEW] dhclient does not work with busybox ip
Public bug reported: After isc-dhcp update from 4.3.5 to 4.4.1, dhclient-script uses valid_lft option when adding an IPv4 address. When used on the initrd generated by initramfs-tools, this will fail because busybox ip does not support this option. This affects the use of cloud-initramfs-dyn-netconf and ip= command line option, which breaks initramfs-tools testing. ** Affects: busybox (Ubuntu) Importance: Undecided Status: New ** Affects: cloud-initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Affects: isc-dhcp (Ubuntu) Importance: Undecided Status: New ** Affects: busybox (Ubuntu Disco) Importance: Undecided Status: New ** Affects: cloud-initramfs-tools (Ubuntu Disco) Importance: Undecided Status: New ** Affects: initramfs-tools (Ubuntu Disco) Importance: Undecided Status: New ** Affects: isc-dhcp (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: cloud-initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: busybox (Ubuntu) Importance: Undecided Status: New ** Also affects: busybox (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: isc-dhcp (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: cloud-initramfs-tools (Ubuntu Disco) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1819747 Title: dhclient does not work with busybox ip Status in busybox package in Ubuntu: New Status in cloud-initramfs-tools package in Ubuntu: New Status in initramfs-tools package in Ubuntu: New Status in isc-dhcp package in Ubuntu: New Status in busybox source package in Disco: New Status in cloud-initramfs-tools source package in Disco: New Status in initramfs-tools source package in Disco: New Status in isc-dhcp source package in Disco: New Bug description: After isc-dhcp update from 4.3.5 to 4.4.1, dhclient-script uses valid_lft option when adding an IPv4 address. When used on the initrd generated by initramfs-tools, this will fail because busybox ip does not support this option. This affects the use of cloud-initramfs-dyn-netconf and ip= command line option, which breaks initramfs-tools testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1819747/+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 1778844] Re: nvme multipath does not report path relationships
** Patch added: "initramfs-tools_0.131ubuntu19.debdiff" https://bugs.launchpad.net/ubuntu-power-systems/+bug/1778844/+attachment/5249521/+files/initramfs-tools_0.131ubuntu19.debdiff ** Description changed: + [Impact] + initramfs created with MODULES=dep or kdump initrd won't boot a system with root filesystem on a multipath nvme. + + [Test case] + Systems with nvme multipath were able to boot with the created initramfs. Also tested on systems with non-multipath nvme, and non nvme systems. + + [Regression potential] + A system could fail to boot because the generated initramfs was broken. The code should just add modules, which is safer than removing modules or doing any other changes. In any case, it was tested to boot on multipath nvme, non multipath nvme and non nvme systems. + + + - + + Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h - totalusedfree shared buff/cache available + totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: -/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic + /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: -/var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic + /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: - /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz + /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 00
[Touch-packages] [Bug 1795857] Re: enable CONFIG_DRM_BOCHS
I have tested that the module loads and works fine on POWER, on a KVM guest on top of a Power8 system. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1795857 Title: enable CONFIG_DRM_BOCHS Status in kmod package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: CONFIG_DRM_BOCHS got disabled for https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1378648 but doing so regressed running qemu with the 'std' VGA driver, where it'd fail to start X after install, as mentioned on bug 1794280 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1795857/+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 1821863] Re: Need to add Intel CML related pci-id's
** Also affects: mesa (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: libdrm (Ubuntu Disco) Importance: Undecided Status: Fix Released ** Also affects: xorg-server (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: Incomplete ** Also affects: linux-oem (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: linux-oem (Ubuntu Disco) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libdrm in Ubuntu. https://bugs.launchpad.net/bugs/1821863 Title: Need to add Intel CML related pci-id's Status in libdrm package in Ubuntu: Fix Released Status in linux package in Ubuntu: Incomplete Status in linux-oem package in Ubuntu: Fix Committed Status in mesa package in Ubuntu: New Status in xorg-server package in Ubuntu: New Status in libdrm source package in Bionic: New Status in linux source package in Bionic: Invalid Status in linux-oem source package in Bionic: New Status in mesa source package in Bionic: New Status in xorg-server source package in Bionic: New Status in libdrm source package in Disco: Fix Released Status in linux source package in Disco: Incomplete Status in linux-oem source package in Disco: Fix Committed Status in mesa source package in Disco: New Status in xorg-server source package in Disco: New Bug description: [Impact] Please make it happen in the coming oem-kernel as there will be a flood of Intel Comet Lake (CML) platforms that would need it. Thank you. The same is needed for the rest of the stack. CML is basically another iteration of Skylake/Kabylake/Coffee Lake, and doesn't need other changes than pci-id's and support for the PCH (similar to Cannon point, already supported by the kernel). [Test case] Test that i915 graphics works on CML. [Regression potential] None really, these only add a bunch of new pci-id's across the stack. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1821863/+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 1795857] Re: enable CONFIG_DRM_BOCHS
** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: Incomplete ** Also affects: kmod (Ubuntu Disco) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1795857 Title: enable CONFIG_DRM_BOCHS Status in kmod package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Status in kmod source package in Disco: New Status in linux source package in Disco: Incomplete Bug description: CONFIG_DRM_BOCHS got disabled for https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1378648 but doing so regressed running qemu with the 'std' VGA driver, where it'd fail to start X after install, as mentioned on bug 1794280 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1795857/+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 1778844] Re: nvme multipath does not report path relationships
Hi, Andrew, with the debdiff attached and ubuntu sponsors team subscribed, now we should wait for someone on that team to sponsor that update. With the SRU template attached, the only thing blocking that sponsorship now is that disco is now on freeze, so the sponsor is the one who would decide whether this warrants an upload during the freeze. -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: In Progress Status in initramfs-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: In Progress Status in linux source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: In Progress Status in linux source package in Cosmic: Invalid Status in initramfs-tools source package in Disco: In Progress Status in linux source package in Disco: Invalid Bug description: [Impact] initramfs created with MODULES=dep or kdump initrd won't boot a system with root filesystem on a multipath nvme. [Test case] Systems with nvme multipath were able to boot with the created initramfs. Also tested on systems with non-multipath nvme, and non nvme systems. [Regression potential] A system could fail to boot because the generated initramfs was broken. The code should just add modules, which is safer than removing modules or doing any other changes. In any case, it was tested to boot on multipath nvme, non multipath nvme and non nvme systems. - Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c0
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
I have been working upstream to get this fixed on the nvme driver, but it might still take some time, I already have done a back and forth with hch. Will send a v3 later this month. Meanwhile, there are multiple workarounds we documented so far in the bug, namely: 1) Disable nvme multipath, which is done by setting the multipath module parameter for the nvme module on modprobe.d config files, regenerate initrd, reboot, then regenerate kdump initrd. 2) Use MODULES=most instead of MODULES=dep on /etc/kernel/postinst.d/kdump-tools and regenerate kdump initrd. 3) Force insert nvme modules into kdump initrd. Namely, just copy the /boot/ initrd file to replace the one in /var/lib/kdump/. -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: In Progress Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Confirmed Status in linux source package in Cosmic: Confirmed Status in makedumpfile source package in Cosmic: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 28
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
Upstream discussion is progressing. I have tested some patches from hch, will send him some feedback later today and post the links here. -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: In Progress Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Confirmed Status in linux source package in Cosmic: Confirmed Status in makedumpfile source package in Cosmic: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 [ 73.058099] GPR16: 0e4f79cc94b0 0e4f79d567e0 0e4f79d88204 00
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
https://lore.kernel.org/linux-block/20181213113549.GA7543@calabresa/T/#t Upstream discussion 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: In Progress Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Confirmed Status in linux source package in Cosmic: Confirmed Status in makedumpfile source package in Cosmic: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 [ 73.058099] GPR16: 0e4f79cc94b0 0e4f79d567e0 0e4f79d88204 0e4f79d56818 [ 73.058099]
[Touch-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
After applying the two fixes, I managed to get the test running on a loop for more than 24 hours on disco. Will review the case with someone on the team before attaching the fix. -- 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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Status in linux source package in Bionic: New Status in systemd source package in Bionic: New Status in udisks2 source package in Bionic: New Status in linux source package in Disco: New Status in systemd source package in Disco: New Status in udisks2 source package in Disco: New Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: New Status in udisks2 source package in Eoan: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+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 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
https://lists.freedesktop.org/archives/systemd- devel/2019-May/042570.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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Status in linux source package in Bionic: New Status in systemd source package in Bionic: New Status in udisks2 source package in Bionic: New Status in linux source package in Disco: New Status in systemd source package in Disco: New Status in udisks2 source package in Disco: New Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: New Status in udisks2 source package in Eoan: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+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 1778844] Re: nvme multipath does not report path relationships
Hi, Manoj. There is nothing wrong in what you are doing here. This seems to be an unrelated bug. I am looking at any known problems on cpuidle for power9. Can you, please, open a different bug report, and try a different system for regression testing? From the log message, it doesn't seem there is anything related to initramfs changes, but a real kernel bug, also, apparently, unrelated to kdump. Thanks. Cascardo. -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: Fix Committed Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: Fix Released Status in initramfs-tools source package in Cosmic: Fix Committed Status in initramfs-tools source package in Disco: Fix Released Bug description: [Impact] initramfs created with MODULES=dep or kdump initrd won't boot a system with root filesystem on a multipath nvme. [Test case] Systems with nvme multipath were able to boot with the created initramfs. Also tested on systems with non-multipath nvme, and non nvme systems. In order to verify the fix, one needs to change MODULES option to dep on /etc/initramfs-tools/initramfs.conf, recreate initramfs and reboot, check the system has booted fine. That should not break on systems with non nvme disks or systems with non multipath nvme systems, and that should now work on multipath nvme systems. sed -i /MODULES=/s,=.*,=dep, /etc/initramfs-tools/initramfs.conf update-initramfs -u -k all reboot [Regression potential] A system could fail to boot because the generated initramfs was broken. The code should just add modules, which is safer than removing modules or doing any other changes. In any case, it was tested to boot on multipath nvme, non multipath nvme and non nvme systems. - Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink sy
[Touch-packages] [Bug 1844524] [NEW] text relocation of grep prevents its use under udevd
Public bug reported: [Impact] grep can't be used under udev, preventing kdump-tools to be used after a memory hotplug. [Test case] Run grep with systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline [Regression potential] The fix is a simple rebuild, so should have minimal potential for regression. - # systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline Running as unit: run-u54.service Press ^] three times within 1s to disconnect TTY. /bin/grep: error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted # Under ppc64el, grep can't be used under udev, because it restricts mapping to be Write+Execute, with MemoryDenyWriteExecute=yes. A rebuild of grep under bionic fixes the issue. ** Affects: grep (Ubuntu) Importance: Undecided Status: New ** Affects: grep (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: grep (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to grep in Ubuntu. https://bugs.launchpad.net/bugs/1844524 Title: text relocation of grep prevents its use under udevd Status in grep package in Ubuntu: New Status in grep source package in Bionic: New Bug description: [Impact] grep can't be used under udev, preventing kdump-tools to be used after a memory hotplug. [Test case] Run grep with systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline [Regression potential] The fix is a simple rebuild, so should have minimal potential for regression. - # systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline Running as unit: run-u54.service Press ^] three times within 1s to disconnect TTY. /bin/grep: error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted # Under ppc64el, grep can't be used under udev, because it restricts mapping to be Write+Execute, with MemoryDenyWriteExecute=yes. A rebuild of grep under bionic fixes the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1844524/+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 1844524] Re: text relocation of grep prevents its use under udevd
** Changed in: grep (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to grep in Ubuntu. https://bugs.launchpad.net/bugs/1844524 Title: text relocation of grep prevents its use under udevd Status in grep package in Ubuntu: Invalid Status in grep source package in Bionic: New Bug description: [Impact] grep can't be used under udev, preventing kdump-tools to be used after a memory hotplug. [Test case] Run grep with systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline [Regression potential] The fix is a simple rebuild, so should have minimal potential for regression. - # systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline Running as unit: run-u54.service Press ^] three times within 1s to disconnect TTY. /bin/grep: error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted # Under ppc64el, grep can't be used under udev, because it restricts mapping to be Write+Execute, with MemoryDenyWriteExecute=yes. A rebuild of grep under bionic fixes the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1844524/+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 1844524] Re: text relocation of grep prevents its use under udevd
root@lewis:~# dpkg -s grep | grep Version Version: 3.1-2build1 root@lewis:~# systemd-run -t --property MemoryDenyWriteExecute=yes grep -i crashkernel= /proc/cmdline Running as unit: run-u73.service Press ^] three times within 1s to disconnect TTY. root=UUID=b995e70a-9241-4f98-b451-b3ecc7fa990c ro console=hvc0 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M root@lewis:~# ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to grep in Ubuntu. https://bugs.launchpad.net/bugs/1844524 Title: text relocation of grep prevents its use under udevd Status in grep package in Ubuntu: Invalid Status in grep source package in Bionic: Fix Committed Bug description: [Impact] grep can't be used under udev, preventing kdump-tools to be used after a memory hotplug. [Test case] Run grep with systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline [Regression potential] The fix is a simple rebuild, so should have minimal potential for regression. - # systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline Running as unit: run-u54.service Press ^] three times within 1s to disconnect TTY. /bin/grep: error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted # Under ppc64el, grep can't be used under udev, because it restricts mapping to be Write+Execute, with MemoryDenyWriteExecute=yes. A rebuild of grep under bionic fixes the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1844524/+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 1844524] Re: text relocation of grep prevents its use under udevd
Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to grep in Ubuntu. https://bugs.launchpad.net/bugs/1844524 Title: text relocation of grep prevents its use under udevd Status in grep package in Ubuntu: Invalid Status in grep source package in Bionic: Fix Committed Bug description: [Impact] grep can't be used under udev, preventing kdump-tools to be used after a memory hotplug. [Test case] Run grep with systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline [Regression potential] The fix is a simple rebuild, so should have minimal potential for regression. - # systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline Running as unit: run-u54.service Press ^] three times within 1s to disconnect TTY. /bin/grep: error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted # Under ppc64el, grep can't be used under udev, because it restricts mapping to be Write+Execute, with MemoryDenyWriteExecute=yes. A rebuild of grep under bionic fixes the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1844524/+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 1844524] Re: text relocation of grep prevents its use under udevd
The autopkgtest regression was caused by a network timeout. A retry was done and was successful. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to grep in Ubuntu. https://bugs.launchpad.net/bugs/1844524 Title: text relocation of grep prevents its use under udevd Status in grep package in Ubuntu: Invalid Status in grep source package in Bionic: Fix Committed Bug description: [Impact] grep can't be used under udev, preventing kdump-tools to be used after a memory hotplug. [Test case] Run grep with systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline [Regression potential] The fix is a simple rebuild, so should have minimal potential for regression. - # systemd-run -t --property MemoryDenyWriteExecute=yes /bin/grep crashkernel /proc/cmdline Running as unit: run-u54.service Press ^] three times within 1s to disconnect TTY. /bin/grep: error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted # Under ppc64el, grep can't be used under udev, because it restricts mapping to be Write+Execute, with MemoryDenyWriteExecute=yes. A rebuild of grep under bionic fixes the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1844524/+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 1778844] Re: nvme multipath does not report path relationships
Upstream is a little reluctant to accept my changes, and seems to suggest that we find out the layout of the paths some other way (which is possible, but would be such a special case on initramfs-tools, only for nvme). Cascardo. -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: In Progress Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Confirmed Status in linux source package in Cosmic: Confirmed Status in makedumpfile source package in Cosmic: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 000
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
I have pushed a version of initramfs-tools to my ppa that seems to fix the problem. Can IBM test it? add-apt-repository ppa:cascardo/kdump2 It's a version for bionic. Only initramfs-tools should come from this source. kdump-tools and makedumpfile should be from bionic-updates or bionic. After that, remove the initrd images from /var/lib/kdump/, reboot, then test the crash. So: add-apt-repository ppa:cascardo/kdump2 apt install initramfs-tools rm /var/lib/kdump/initr* reboot After reboot: echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: In Progress Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Confirmed Status in linux source package in Cosmic: Confirmed Status in makedumpfile source package in Cosmic: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c00
[Touch-packages] [Bug 1561643] Re: initramfs-tools ignores the FRAMEBUFFER option
** Description changed: + [Impact] + initramfs-tools would always include all "framebuffer" drivers/firmware inside initramfs, which was making it ever more huge. In some systems with low memory, that would even prevent systems to boot. kdump, for example, had an impact. + + [Test case] + Different systems on different arches were tested. When cryptsetup (or cryptsetup-initramfs) was installed, framebuffer drivers were included in the ramdisk. When not installed, the initramfs was smaller. Systems booted on both cases. Systems with encrypted disks were tested as well. + + [Regression Potential] + Systems may not boot because of missing drivers. Users may have a different experience during boot because of missing "framebuffer" drivers. + + + == + initramfs-tools ignores the FRAMEBUFFER option. This means that the framebuffer hook will always include the drm modules, regardless of whether it is dealing with an encrypted system or not. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: initramfs-tools 0.122ubuntu6 ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6 Uname: Linux 4.4.0-15-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 24 18:06:24 2016 InstallationDate: Installed on 2016-02-16 (37 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160209) PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: No upgrade log present (probably fresh install) -- 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/1561643 Title: initramfs-tools ignores the FRAMEBUFFER option Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Xenial: New Status in initramfs-tools source package in Bionic: In Progress Bug description: [Impact] initramfs-tools would always include all "framebuffer" drivers/firmware inside initramfs, which was making it ever more huge. In some systems with low memory, that would even prevent systems to boot. kdump, for example, had an impact. [Test case] Different systems on different arches were tested. When cryptsetup (or cryptsetup-initramfs) was installed, framebuffer drivers were included in the ramdisk. When not installed, the initramfs was smaller. Systems booted on both cases. Systems with encrypted disks were tested as well. [Regression Potential] Systems may not boot because of missing drivers. Users may have a different experience during boot because of missing "framebuffer" drivers. == initramfs-tools ignores the FRAMEBUFFER option. This means that the framebuffer hook will always include the drm modules, regardless of whether it is dealing with an encrypted system or not. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: initramfs-tools 0.122ubuntu6 ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6 Uname: Linux 4.4.0-15-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 24 18:06:24 2016 InstallationDate: Installed on 2016-02-16 (37 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160209) PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1561643/+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 1778844] Re: nvme multipath does not report path relationships
The system has too many devices, so too many drivers are using too much memory. So, the system goes out-of-memory before makedumpfile is complete. Please, reserve more memory on crashkernel, reboot the system and repeat the crash test. To reserve more memory on crashkernel, edit file /etc/default/grub.d /kdump-tools.cfg and change crashkernel value to crashkernel=384M, for example, then run update-grub. Thanks. Cascardo. -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Confirmed Status in linux source package in Cosmic: Confirmed Status in makedumpfile source package in Cosmic: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 9000
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
Hi, Andrew and Hari. The original issue is only resolved by using an initramfs-tools from my ppa. We still need to get this fix included in our releases. I will start working to get this in disco. Cascardo. ** Changed in: initramfs-tools (Ubuntu) Status: Invalid => In Progress ** Also affects: initramfs-tools (Ubuntu Disco) Importance: Critical Assignee: Canonical Kernel Team (canonical-kernel-team) Status: In Progress ** Also affects: linux (Ubuntu Disco) Importance: Critical Assignee: Canonical Kernel Team (canonical-kernel-team) Status: Invalid ** Also affects: makedumpfile (Ubuntu Disco) Importance: Critical Assignee: Canonical Kernel Team (canonical-kernel-team) Status: Invalid ** Changed in: initramfs-tools (Ubuntu Cosmic) Status: Invalid => In Progress ** Changed in: initramfs-tools (Ubuntu Bionic) Status: Invalid => 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: Won't Fix Status in initramfs-tools package in Ubuntu: In Progress Status in linux package in Ubuntu: Invalid Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: In Progress Status in linux source package in Bionic: Invalid Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: In Progress Status in linux source package in Cosmic: Invalid Status in makedumpfile source package in Cosmic: Invalid Status in initramfs-tools source package in Disco: In Progress Status in linux source package in Disco: Invalid Status in makedumpfile source package in Disco: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_tra
[Touch-packages] [Bug 1561643] Re: initramfs-tools ignores the FRAMEBUFFER option
Tested on a chroot that the resulting initramfs is smaller and doesn't contain the framebuffer drivers. After installing some cryptsetup packages, those same drivers were included again after regenerating initrd images. Cascardo. ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- 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/1561643 Title: initramfs-tools ignores the FRAMEBUFFER option Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Xenial: New Status in initramfs-tools source package in Bionic: Fix Committed Bug description: [Impact] initramfs-tools would always include all "framebuffer" drivers/firmware inside initramfs, which was making it ever more huge. In some systems with low memory, that would even prevent systems to boot. kdump, for example, had an impact. [Test case] Different systems on different arches were tested. When cryptsetup (or cryptsetup-initramfs) was installed, framebuffer drivers were included in the ramdisk. When not installed, the initramfs was smaller. Systems booted on both cases. Systems with encrypted disks were tested as well. [Regression Potential] Systems may not boot because of missing drivers. Users may have a different experience during boot because of missing "framebuffer" drivers. == initramfs-tools ignores the FRAMEBUFFER option. This means that the framebuffer hook will always include the drm modules, regardless of whether it is dealing with an encrypted system or not. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: initramfs-tools 0.122ubuntu6 ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6 Uname: Linux 4.4.0-15-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 24 18:06:24 2016 InstallationDate: Installed on 2016-02-16 (37 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160209) PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1561643/+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 1854001] [NEW] pmtu net kernel selftests are skipped on bionic linux-hwe-edge 5.3
Public bug reported: 11:52:44 DEBUG| [stdout] # selftests: net: pmtu.sh 11:52:44 DEBUG| [stdout] # TEST: ipv4: PMTU exceptions [ OK ] 11:52:44 DEBUG| [stdout] # TEST: ipv6: PMTU exceptions [ OK ] 11:52:44 DEBUG| [stdout] # vxlan4 not supported 11:52:44 DEBUG| [stdout] # TEST: IPv4 over vxlan4: PMTU exceptions [SKIP] 11:52:44 DEBUG| [stdout] # vxlan4 not supported 11:52:44 DEBUG| [stdout] # TEST: IPv6 over vxlan4: PMTU exceptions [SKIP] 11:52:46 DEBUG| [stdout] # TEST: IPv4 over vxlan6: PMTU exceptions [ OK ] 11:52:47 DEBUG| [stdout] # TEST: IPv6 over vxlan6: PMTU exceptions [ OK ] 11:52:47 DEBUG| [stdout] # geneve4 not supported 11:52:47 DEBUG| [stdout] # TEST: IPv4 over geneve4: PMTU exceptions [SKIP] 11:52:47 DEBUG| [stdout] # geneve4 not supported 11:52:47 DEBUG| [stdout] # TEST: IPv6 over geneve4: PMTU exceptions [SKIP] 11:52:48 DEBUG| [stdout] # TEST: IPv4 over geneve6: PMTU exceptions [ OK ] 11:52:49 DEBUG| [stdout] # TEST: IPv6 over geneve6: PMTU exceptions [ OK ] 11:52:51 DEBUG| [stdout] # TEST: IPv4 over fou4: PMTU exceptions [ OK ] 11:52:52 DEBUG| [stdout] # TEST: IPv6 over fou4: PMTU exceptions [ OK ] 11:52:53 DEBUG| [stdout] # TEST: IPv4 over fou6: PMTU exceptions [ OK ] 11:52:54 DEBUG| [stdout] # TEST: IPv6 over fou6: PMTU exceptions [ OK ] 11:52:55 DEBUG| [stdout] # TEST: IPv4 over gue4: PMTU exceptions [ OK ] 11:52:57 DEBUG| [stdout] # TEST: IPv6 over gue4: PMTU exceptions [ OK ] 11:52:58 DEBUG| [stdout] # TEST: IPv4 over gue6: PMTU exceptions [ OK ] 11:52:59 DEBUG| [stdout] # TEST: IPv6 over gue6: PMTU exceptions [ OK ] 11:53:00 DEBUG| [stdout] # TEST: vti6: PMTU exceptions [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti4: PMTU exceptions [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti4: default MTU assignment [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti6: default MTU assignment [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti4: MTU setting on link creation [ OK ] 11:53:04 DEBUG| [stdout] # TEST: vti6: MTU setting on link creation [ OK ] 11:53:04 DEBUG| [stdout] # TEST: vti6: MTU changes on link changes [ OK ] 11:53:04 DEBUG| [stdout] # vxlan4 not supported 11:53:04 DEBUG| [stdout] # TEST: ipv4: cleanup of cached exceptions [SKIP] Upgrading iproute2 to 5.2 fixes this. ** Affects: ubuntu-kernel-tests Importance: Undecided Status: New ** Affects: iproute2 (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: linux-hwe-edge (Ubuntu) Importance: Undecided Status: Invalid ** Affects: iproute2 (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: linux-hwe-edge (Ubuntu Bionic) Importance: Undecided Status: Invalid ** Also affects: iproute2 (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: iproute2 (Ubuntu) Status: New => Fix Released ** Also affects: linux-hwe-edge (Ubuntu) Importance: Undecided Status: New ** Changed in: linux-hwe-edge (Ubuntu) Status: New => Invalid ** Changed in: linux-hwe-edge (Ubuntu Bionic) Status: New => Invalid ** Also affects: ubuntu-kernel-tests Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1854001 Title: pmtu net kernel selftests are skipped on bionic linux-hwe-edge 5.3 Status in ubuntu-kernel-tests: New Status in iproute2 package in Ubuntu: Fix Released Status in linux-hwe-edge package in Ubuntu: Invalid Status in iproute2 source package in Bionic: New Status in linux-hwe-edge source package in Bionic: Invalid Bug description: 11:52:44 DEBUG| [stdout] # selftests: net: pmtu.sh 11:52:44 DEBUG| [stdout] # TEST: ipv4: PMTU exceptions [ OK ] 11:52:44 DEBUG| [stdout] # TEST: ipv6: PMTU exceptions [ OK ] 11:52:44 DEBUG| [stdout] # vxlan4 not supported 11:52:44 DEBUG| [stdout] # TEST: IPv4 over vxlan4: PMTU exceptions [SKIP] 11:52:44 DEBUG| [stdout] # vxlan4 not supported 11:52:44 DEBUG| [stdout] # TEST:
[Touch-packages] [Bug 1854001] Re: pmtu net kernel selftests are skipped on bionic linux-hwe-edge 5.3
http://patchwork.ozlabs.org/patch/1202263/ Upstream change submitted to fix this. ** Changed in: linux-hwe-edge (Ubuntu) Status: Invalid => In Progress ** Changed in: linux-hwe-edge (Ubuntu Bionic) Status: Invalid => In Progress ** Description changed: + [Impact] + selftests will incorrectly indicate a failure, taking the time of developers to verify a false positive, and preventing us from finding real bugs in the corresponding code. + + [Test case] + Run the script directly and verify there are no failures. + sudo ./tools/testing/selftests/net/pmtu.sh + + [Regression potential] + No kernel code was changed, only the test. The fix could cause false positives to happen with newer versions of iproute2, but those were tested as well. + + + + 11:52:44 DEBUG| [stdout] # selftests: net: pmtu.sh 11:52:44 DEBUG| [stdout] # TEST: ipv4: PMTU exceptions [ OK ] 11:52:44 DEBUG| [stdout] # TEST: ipv6: PMTU exceptions [ OK ] 11:52:44 DEBUG| [stdout] # vxlan4 not supported 11:52:44 DEBUG| [stdout] # TEST: IPv4 over vxlan4: PMTU exceptions [SKIP] 11:52:44 DEBUG| [stdout] # vxlan4 not supported 11:52:44 DEBUG| [stdout] # TEST: IPv6 over vxlan4: PMTU exceptions [SKIP] 11:52:46 DEBUG| [stdout] # TEST: IPv4 over vxlan6: PMTU exceptions [ OK ] 11:52:47 DEBUG| [stdout] # TEST: IPv6 over vxlan6: PMTU exceptions [ OK ] 11:52:47 DEBUG| [stdout] # geneve4 not supported 11:52:47 DEBUG| [stdout] # TEST: IPv4 over geneve4: PMTU exceptions [SKIP] 11:52:47 DEBUG| [stdout] # geneve4 not supported 11:52:47 DEBUG| [stdout] # TEST: IPv6 over geneve4: PMTU exceptions [SKIP] 11:52:48 DEBUG| [stdout] # TEST: IPv4 over geneve6: PMTU exceptions [ OK ] 11:52:49 DEBUG| [stdout] # TEST: IPv6 over geneve6: PMTU exceptions [ OK ] 11:52:51 DEBUG| [stdout] # TEST: IPv4 over fou4: PMTU exceptions [ OK ] 11:52:52 DEBUG| [stdout] # TEST: IPv6 over fou4: PMTU exceptions [ OK ] 11:52:53 DEBUG| [stdout] # TEST: IPv4 over fou6: PMTU exceptions [ OK ] 11:52:54 DEBUG| [stdout] # TEST: IPv6 over fou6: PMTU exceptions [ OK ] 11:52:55 DEBUG| [stdout] # TEST: IPv4 over gue4: PMTU exceptions [ OK ] 11:52:57 DEBUG| [stdout] # TEST: IPv6 over gue4: PMTU exceptions [ OK ] 11:52:58 DEBUG| [stdout] # TEST: IPv4 over gue6: PMTU exceptions [ OK ] 11:52:59 DEBUG| [stdout] # TEST: IPv6 over gue6: PMTU exceptions [ OK ] 11:53:00 DEBUG| [stdout] # TEST: vti6: PMTU exceptions [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti4: PMTU exceptions [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti4: default MTU assignment [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti6: default MTU assignment [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti4: MTU setting on link creation [ OK ] 11:53:04 DEBUG| [stdout] # TEST: vti6: MTU setting on link creation [ OK ] 11:53:04 DEBUG| [stdout] # TEST: vti6: MTU changes on link changes [ OK ] 11:53:04 DEBUG| [stdout] # vxlan4 not supported 11:53:04 DEBUG| [stdout] # TEST: ipv4: cleanup of cached exceptions [SKIP] - Upgrading iproute2 to 5.2 fixes this. ** Changed in: linux-hwe-edge (Ubuntu) Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo) ** Changed in: linux-hwe-edge (Ubuntu Bionic) Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1854001 Title: pmtu net kernel selftests are skipped on bionic linux-hwe-edge 5.3 Status in ubuntu-kernel-tests: New Status in iproute2 package in Ubuntu: Fix Released Status in linux-hwe-edge package in Ubuntu: In Progress Status in iproute2 source package in Bionic: New Status in linux-hwe-edge source package in Bionic: In Progress Bug description: [Impact] selftests will incorrectly indicate a failure, taking the time of developers to verify a false positive, and preventing us from finding real bugs in the corresponding code. [Test case] Run the script directly and verify there are no failures. sudo ./tools/testing/selftests
[Touch-packages] [Bug 1854001] Re: pmtu net kernel selftests are skipped on bionic linux-hwe-edge 5.3
The log only shows the SKIPs. I managed to reproduce one FAIL that I have seen as well: TEST: ipv6: list and flush cached exceptions[FAIL] can't list cached exceptions This one ended up being caused by the script itself and a difference in behavior between different versions of iproute2. Recent iproute2, when introducing json output support for ip route, ended up removing the newline for IPv6, while keeping it for IPv4. The script author assumed the newest behavior, but also accounted for the two lines per entry for IPv4. iproute2, however, has a -oneline option that could just have been used in this case and that would fix the whole problem. Using it fix the FAIL, while we still have the SKIPs, which would require a new version of iproute2, at least on -backports. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1854001 Title: pmtu net kernel selftests are skipped on bionic linux-hwe-edge 5.3 Status in ubuntu-kernel-tests: New Status in iproute2 package in Ubuntu: Fix Released Status in linux-hwe-edge package in Ubuntu: In Progress Status in iproute2 source package in Bionic: New Status in linux-hwe-edge source package in Bionic: In Progress Bug description: [Impact] selftests will incorrectly indicate a failure, taking the time of developers to verify a false positive, and preventing us from finding real bugs in the corresponding code. [Test case] Run the script directly and verify there are no failures. sudo ./tools/testing/selftests/net/pmtu.sh [Regression potential] No kernel code was changed, only the test. The fix could cause false positives to happen with newer versions of iproute2, but those were tested as well. 11:52:44 DEBUG| [stdout] # selftests: net: pmtu.sh 11:52:44 DEBUG| [stdout] # TEST: ipv4: PMTU exceptions [ OK ] 11:52:44 DEBUG| [stdout] # TEST: ipv6: PMTU exceptions [ OK ] 11:52:44 DEBUG| [stdout] # vxlan4 not supported 11:52:44 DEBUG| [stdout] # TEST: IPv4 over vxlan4: PMTU exceptions [SKIP] 11:52:44 DEBUG| [stdout] # vxlan4 not supported 11:52:44 DEBUG| [stdout] # TEST: IPv6 over vxlan4: PMTU exceptions [SKIP] 11:52:46 DEBUG| [stdout] # TEST: IPv4 over vxlan6: PMTU exceptions [ OK ] 11:52:47 DEBUG| [stdout] # TEST: IPv6 over vxlan6: PMTU exceptions [ OK ] 11:52:47 DEBUG| [stdout] # geneve4 not supported 11:52:47 DEBUG| [stdout] # TEST: IPv4 over geneve4: PMTU exceptions [SKIP] 11:52:47 DEBUG| [stdout] # geneve4 not supported 11:52:47 DEBUG| [stdout] # TEST: IPv6 over geneve4: PMTU exceptions [SKIP] 11:52:48 DEBUG| [stdout] # TEST: IPv4 over geneve6: PMTU exceptions [ OK ] 11:52:49 DEBUG| [stdout] # TEST: IPv6 over geneve6: PMTU exceptions [ OK ] 11:52:51 DEBUG| [stdout] # TEST: IPv4 over fou4: PMTU exceptions [ OK ] 11:52:52 DEBUG| [stdout] # TEST: IPv6 over fou4: PMTU exceptions [ OK ] 11:52:53 DEBUG| [stdout] # TEST: IPv4 over fou6: PMTU exceptions [ OK ] 11:52:54 DEBUG| [stdout] # TEST: IPv6 over fou6: PMTU exceptions [ OK ] 11:52:55 DEBUG| [stdout] # TEST: IPv4 over gue4: PMTU exceptions [ OK ] 11:52:57 DEBUG| [stdout] # TEST: IPv6 over gue4: PMTU exceptions [ OK ] 11:52:58 DEBUG| [stdout] # TEST: IPv4 over gue6: PMTU exceptions [ OK ] 11:52:59 DEBUG| [stdout] # TEST: IPv6 over gue6: PMTU exceptions [ OK ] 11:53:00 DEBUG| [stdout] # TEST: vti6: PMTU exceptions [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti4: PMTU exceptions [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti4: default MTU assignment [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti6: default MTU assignment [ OK ] 11:53:03 DEBUG| [stdout] # TEST: vti4: MTU setting on link creation [ OK ] 11:53:04 DEBUG| [stdout] # TEST: vti6: MTU setting on link creation [ OK ] 11:53:04 DEBUG| [stdout] # TEST: vti6: MTU changes on link changes [ OK ] 11:53:04 DEBUG| [stdout] # vxlan4 not supported 11:53:04 DEBUG| [stdout] # TEST: ipv4: cleanup of cached exceptions [SKIP] Upgrading iproute2 to 5.2 fixes this. To manage notifications
[Touch-packages] [Bug 1856871] Re: i/o error if next unused loop device is queried
I did some quick testing and it seems this happens on whatever loop device that had a file attached and then detached. No matter if it's the next available or not. So, if you create a new loop device without ever attaching a file to it, it seems the block layer is not setup sufficiently so any requests will really go through it. But when it is attached, then detached, the block layer still sends requests to the loop driver, which will result in the EIO as it is detached. Cascardo. -- 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/1856871 Title: i/o error if next unused loop device is queried Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Status in udev package in Ubuntu: New Bug description: This is reproducible in Bionic and late. Here's an example running 'focal': $ lsb_release -cs focal $ uname -r 5.3.0-24-generic The error is: blk_update_request: I/O error, dev loop2, sector 0 and on more recent kernel: kernel: [18135.185709] blk_update_request: I/O error, dev loop18, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 How to trigger it: $ sosreport -o block or more precisely the cmd causing the situation inside the block plugin: $ parted -s $(losetup -f) unit s print https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52 but if I run it on the next next unused loop device, in this case /dev/loop3 (which is also unused), no errors. While I agree that sosreport shouldn't query unused loop devices, there is definitely something going on with the next unused loop device. What is differentiate loop2 and loop3 and any other unused ones ? 3 things so far I have noticed: * loop2 is the next unused loop device (losetup -f) * A reboot is needed (if some loop modification (snap install, mount loop, ...) has been made at runtime * I have also noticed that loop2 (or whatever the next unused one is) have some stat as oppose to other unused loop devices. The stat exist already right after the system boot for the next unused loop device. /sys/block/loop2/stat :: 2 0 10 0 1 0 0 0 0 0 0 2 = number of read I/Os processed 10 = number of sectors read 1 = number of write I/Os processed Explanation of each column: https://www.kernel.org/doc/html/latest/block/stat.html while /dev/loop3 doesn't /sys/block/loop3/stat :: 0 0 0 0 0 0 0 0 0 0 0 Which tells me that something during the boot process most likely acquired (on purpose or not) the next unused loop and possibly didn't released it well enough. If loop2 is generating errors, and I install a snap, the snap squashfs will take loop2, making loop3 the next unused loop device. If I query loop3 with 'parted' right after, no errors. If I reboot, and query loop3 again, then no I'll have an error. To triggers the errors it need to be after a reboot and it only impact the first unused loop device available (losetup -f). This was tested with focal/systemd whic his very close to latest upstream code. This has been test with latest v5.5 mainline kernel as well. For now, I don't think it's a kernel problem, I'm more thinking of a userspace misbehaviour dealing with loop device (or block device) at boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1856871/+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 1856871] Re: i/o error if next unused loop device is queried
so the problem is inside the block layer ? More likely the loop driver not undoing something it does when a file is attached to it. But could as well be something related to the multiqueue support, so could still be something in the block layer. Still needs investigation. Anyway, as this is not exactly a difference in behavior between the next available loop device and other detached loop devices, what is the exact problem this is causing? I don't see why getting EIO for a detached loop device is the wrong behavior here. I agree there is an inconsistency, but I would accept EIO when trying to fsync a detached device. -- 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/1856871 Title: i/o error if next unused loop device is queried Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Status in udev package in Ubuntu: New Bug description: This is reproducible in Bionic and late. Here's an example running 'focal': $ lsb_release -cs focal $ uname -r 5.3.0-24-generic The error is: blk_update_request: I/O error, dev loop2, sector 0 and on more recent kernel: kernel: [18135.185709] blk_update_request: I/O error, dev loop18, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 How to trigger it: $ sosreport -o block or more precisely the cmd causing the situation inside the block plugin: $ parted -s $(losetup -f) unit s print https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52 but if I run it on the next next unused loop device, in this case /dev/loop3 (which is also unused), no errors. While I agree that sosreport shouldn't query unused loop devices, there is definitely something going on with the next unused loop device. What is differentiate loop2 and loop3 and any other unused ones ? 3 things so far I have noticed: * loop2 is the next unused loop device (losetup -f) * A reboot is needed (if some loop modification (snap install, mount loop, ...) has been made at runtime * I have also noticed that loop2 (or whatever the next unused one is) have some stat as oppose to other unused loop devices. The stat exist already right after the system boot for the next unused loop device. /sys/block/loop2/stat :: 2 0 10 0 1 0 0 0 0 0 0 2 = number of read I/Os processed 10 = number of sectors read 1 = number of write I/Os processed Explanation of each column: https://www.kernel.org/doc/html/latest/block/stat.html while /dev/loop3 doesn't /sys/block/loop3/stat :: 0 0 0 0 0 0 0 0 0 0 0 Which tells me that something during the boot process most likely acquired (on purpose or not) the next unused loop and possibly didn't released it well enough. If loop2 is generating errors, and I install a snap, the snap squashfs will take loop2, making loop3 the next unused loop device. If I query loop3 with 'parted' right after, no errors. If I reboot, and query loop3 again, then no I'll have an error. To triggers the errors it need to be after a reboot and it only impact the first unused loop device available (losetup -f). This was tested with focal/systemd whic his very close to latest upstream code. This has been test with latest v5.5 mainline kernel as well. For now, I don't think it's a kernel problem, I'm more thinking of a userspace misbehaviour dealing with loop device (or block device) at boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1856871/+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 1856871] Re: i/o error if next unused loop device is queried
Exactly my point about consistency. They should either return EIO in both cases or succeed in both cases. Which behavior will depend on: 1) which is the easier solution; 2) what upstream thinks is okay. -- 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/1856871 Title: i/o error if next unused loop device is queried Status in linux package in Ubuntu: Incomplete Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Status in udev package in Ubuntu: New Bug description: This is reproducible in Bionic and late. Here's an example running 'focal': $ lsb_release -cs focal $ uname -r 5.3.0-24-generic The error is: blk_update_request: I/O error, dev loop2, sector 0 and on more recent kernel: kernel: [18135.185709] blk_update_request: I/O error, dev loop18, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 How to trigger it: $ sosreport -o block or more precisely the cmd causing the situation inside the block plugin: $ parted -s $(losetup -f) unit s print https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52 but if I run it on the next next unused loop device, in this case /dev/loop3 (which is also unused), no errors. While I agree that sosreport shouldn't query unused loop devices, there is definitely something going on with the next unused loop device. What is differentiate loop2 and loop3 and any other unused ones ? 3 things so far I have noticed: * loop2 is the next unused loop device (losetup -f) * A reboot is needed (if some loop modification (snap install, mount loop, ...) has been made at runtime * I have also noticed that loop2 (or whatever the next unused one is) have some stat as oppose to other unused loop devices. The stat exist already right after the system boot for the next unused loop device. /sys/block/loop2/stat :: 2 0 10 0 1 0 0 0 0 0 0 2 = number of read I/Os processed 10 = number of sectors read 1 = number of write I/Os processed Explanation of each column: https://www.kernel.org/doc/html/latest/block/stat.html while /dev/loop3 doesn't /sys/block/loop3/stat :: 0 0 0 0 0 0 0 0 0 0 0 Which tells me that something during the boot process most likely acquired (on purpose or not) the next unused loop and possibly didn't released it well enough. If loop2 is generating errors, and I install a snap, the snap squashfs will take loop2, making loop3 the next unused loop device. If I query loop3 with 'parted' right after, no errors. If I reboot, and query loop3 again, then no I'll have an error. To triggers the errors it need to be after a reboot and it only impact the first unused loop device available (losetup -f). This was tested with focal/systemd whic his very close to latest upstream code. This has been test with latest v5.5 mainline kernel as well. For now, I don't think it's a kernel problem, I'm more thinking of a userspace misbehaviour dealing with loop device (or block device) at boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856871/+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 1651170] Re: run_scripts_optional sets 'y' value but call_scripts checks for 'optional' value
*** This bug is a duplicate of bug 1561643 *** https://bugs.launchpad.net/bugs/1561643 ** This bug has been marked a duplicate of bug 1561643 initramfs-tools ignores the FRAMEBUFFER 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/1651170 Title: run_scripts_optional sets 'y' value but call_scripts checks for 'optional' value Status in initramfs-tools: New Status in initramfs-tools package in Ubuntu: New Bug description: I looked into my initramfs and found there big graphics modules for hardware which I don't have. I found a place where these modules were copied into initramfs, it was in /usr/share/initramfs-tools/hooks/framebuffer Also I found a recipe on the Internet, advising to put 'FRAMEBUFFER=n' into initramfs.conf to exclude optional hooks and scipts which have OPTION=FRAMEBUFFER in them from initramfs creation I tried to set this option and to update my initramfs, but did not succeed So I examined mkinitramfs and related scripts and found this sequence in /usr/share/initramfs-tools/hook-functions : run_scripts_optional() { call_scripts_optional=y run_scripts "$@" } ... run_scripts() { ... call_scripts $scriptdir } ... call_scripts() { ... for cs_x in ${runlist}; do ... if [ x"$call_scripts_optional" = "xoptional" ]; then option=$(sed '/^OPTION=/!d;$d;s/^OPTION=//;s/[[:space:]]*$//' "${initdir}/${cs_x}") [ -z "${option}" ] || eval test -n \"\${$option}\" -a \"\${$option}\" != \"n\" || continue fi ... done ... } As you see, variable 'call_scripts_optional' is set to vaue 'y' in run_scripts_optional function, but then it is checked for having 'optional' value in call_scripts function This is observed at least in up-to-date Ubuntu Xenial and Zesty I will also check equivalent scripts in Debian testing/unstable and report my finding in a comment below. To manage notifications about this bug go to: https://bugs.launchpad.net/initramfs-tools/+bug/1651170/+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 1561643] Re: initramfs-tools ignores the FRAMEBUFFER option
** Patch added: "for bionic" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1561643/+attachment/5126843/+files/initramfs-tools_0.130ubuntu3.1.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/1561643 Title: initramfs-tools ignores the FRAMEBUFFER option Status in initramfs-tools package in Ubuntu: Confirmed Bug description: initramfs-tools ignores the FRAMEBUFFER option. This means that the framebuffer hook will always include the drm modules, regardless of whether it is dealing with an encrypted system or not. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: initramfs-tools 0.122ubuntu6 ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6 Uname: Linux 4.4.0-15-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 24 18:06:24 2016 InstallationDate: Installed on 2016-02-16 (37 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160209) PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1561643/+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 1766727] Re: initramfs-tools exception during pm.DoInstall with do-release-upgrade from 16.04 to 18.04
This will likely break with linux-hwe-edge on xenial as well. Hence, requesting SRU for xenial with the attached debdiff. ** Also affects: s390-tools (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: ubuntu-release-upgrader (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: s390-tools (Ubuntu Xenial) Status: New => In Progress ** Patch added: "fix for s390-tools on xenial" https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1766727/+attachment/5130810/+files/s390-tools_1.34.0-0ubuntu8.6.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/1766727 Title: initramfs-tools exception during pm.DoInstall with do-release-upgrade from 16.04 to 18.04 Status in Ubuntu on IBM z Systems: Fix Released Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in s390-tools package in Ubuntu: Fix Released Status in ubuntu-release-upgrader package in Ubuntu: Invalid Status in initramfs-tools source package in Xenial: New Status in linux source package in Xenial: New Status in s390-tools source package in Xenial: In Progress Status in ubuntu-release-upgrader source package in Xenial: New Bug description: Upgrading from 16.04 to 18.04 using 'do-release-upgrade -d' results in: Errors were encountered while processing: initramfs-tools Exception during pm.DoInstall(): E:Sub-process /usr/bin/dpkg returned an error code (1) Could not install the upgrades The upgrade has aborted. Your system could be in an unusable state. A recovery will run now (dpkg --configure -a). --- Processing triggers for systemd (237-3ubuntu10) ... Processing triggers for initramfs-tools (0.130ubuntu3) ... update-initramfs: Generating /boot/initrd.img-4.4.0-121-generic Using config file '/etc/zipl.conf' Error: Ramdisk file '/boot/initrd.img' in section 'ubuntu': No such file or directory run-parts: /etc/initramfs/post-update.d//zz-zipl exited with return code 1 [1mdpkg:[0m error processing package initramfs-tools (--configure): installed initramfs-tools package post-installation script subprocess returned error exit status 1 Processing triggers for ca-certificates (20180409) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. Processing triggers for dictionaries-common (1.27.2) ... Processing triggers for linux-image-4.15.0-19-generic (4.15.0-19.20) ... /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.15.0-19-generic Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasdb (0104). Done. /etc/kernel/postinst.d/zz-zipl: Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasdb (0104). Done. Processing triggers for sgml-base (1.29) ... Processing triggers for resolvconf (1.79ubuntu10) ... Processing triggers for ureadahead (0.100.0-20) ... Errors were encountered while processing: initramfs-tools Log ended: 2018-04-24 13:12:40 --- ApportVersion: 2.20.9-0ubuntu6 Architecture: s390x DistroRelease: Ubuntu 18.04 Package: ubuntu-release-upgrader PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C SHELL=/bin/bash ProcVersionSignature: Ubuntu 4.15.0-19.20-generic 4.15.17 Tags: bionic Uname: Linux 4.15.0-19-generic s390x UpgradeStatus: Upgraded to bionic on 2018-04-24 (0 days ago) UserGroups: adm cdrom cpacfstats dip lpadmin plugdev sambashare sudo _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1766727/+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 1766727] Re: initramfs-tools exception during pm.DoInstall with do-release-upgrade from 16.04 to 18.04
** Also affects: s390-tools (Ubuntu Bionic) Importance: Undecided Status: Fix Released ** Also affects: initramfs-tools (Ubuntu Bionic) Importance: Undecided Status: Invalid ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: Invalid ** Also affects: ubuntu-release-upgrader (Ubuntu Bionic) Importance: Undecided Status: Invalid ** Changed in: linux (Ubuntu Bionic) Status: Invalid => In Progress ** Changed in: linux (Ubuntu Bionic) Status: In Progress => Fix Committed -- 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/1766727 Title: initramfs-tools exception during pm.DoInstall with do-release-upgrade from 16.04 to 18.04 Status in Ubuntu on IBM z Systems: Fix Released Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Committed Status in s390-tools package in Ubuntu: Fix Released Status in ubuntu-release-upgrader package in Ubuntu: Invalid Status in initramfs-tools source package in Xenial: New Status in linux source package in Xenial: New Status in s390-tools source package in Xenial: In Progress Status in ubuntu-release-upgrader source package in Xenial: New Status in initramfs-tools source package in Bionic: Invalid Status in linux source package in Bionic: Fix Committed Status in s390-tools source package in Bionic: Fix Released Status in ubuntu-release-upgrader source package in Bionic: Invalid Bug description: Upgrading from 16.04 to 18.04 using 'do-release-upgrade -d' results in: Errors were encountered while processing: initramfs-tools Exception during pm.DoInstall(): E:Sub-process /usr/bin/dpkg returned an error code (1) Could not install the upgrades The upgrade has aborted. Your system could be in an unusable state. A recovery will run now (dpkg --configure -a). --- Processing triggers for systemd (237-3ubuntu10) ... Processing triggers for initramfs-tools (0.130ubuntu3) ... update-initramfs: Generating /boot/initrd.img-4.4.0-121-generic Using config file '/etc/zipl.conf' Error: Ramdisk file '/boot/initrd.img' in section 'ubuntu': No such file or directory run-parts: /etc/initramfs/post-update.d//zz-zipl exited with return code 1 [1mdpkg:[0m error processing package initramfs-tools (--configure): installed initramfs-tools package post-installation script subprocess returned error exit status 1 Processing triggers for ca-certificates (20180409) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. Processing triggers for dictionaries-common (1.27.2) ... Processing triggers for linux-image-4.15.0-19-generic (4.15.0-19.20) ... /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.15.0-19-generic Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasdb (0104). Done. /etc/kernel/postinst.d/zz-zipl: Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasdb (0104). Done. Processing triggers for sgml-base (1.29) ... Processing triggers for resolvconf (1.79ubuntu10) ... Processing triggers for ureadahead (0.100.0-20) ... Errors were encountered while processing: initramfs-tools Log ended: 2018-04-24 13:12:40 --- ApportVersion: 2.20.9-0ubuntu6 Architecture: s390x DistroRelease: Ubuntu 18.04 Package: ubuntu-release-upgrader PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C SHELL=/bin/bash ProcVersionSignature: Ubuntu 4.15.0-19.20-generic 4.15.17 Tags: bionic Uname: Linux 4.15.0-19-generic s390x UpgradeStatus: Upgraded to bionic on 2018-04-24 (0 days ago) UserGroups: adm cdrom cpacfstats dip lpadmin plugdev sambashare sudo _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1766727/+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 1766727] Re: initramfs-tools exception during pm.DoInstall with do-release-upgrade from 16.04 to 18.04
** Description changed: + [Impact] + Upgrades of linux-image-generic-hwe-16.04-edge will fail to configure because the post-update script for zipl will fail. + + [Test Case] + Upgrade linux-image-generic-hwe-16.04-edge from xenial to xenial-proposed on s390x. + + [Regression] + zipl update on s390x might fail, causing the system to be unbootable. + + Upgrading from 16.04 to 18.04 using 'do-release-upgrade -d' results in: Errors were encountered while processing: initramfs-tools Exception during pm.DoInstall(): E:Sub-process /usr/bin/dpkg returned an error code (1) Could not install the upgrades The upgrade has aborted. Your system could be in an unusable state. A recovery will run now (dpkg --configure -a). --- Processing triggers for systemd (237-3ubuntu10) ... Processing triggers for initramfs-tools (0.130ubuntu3) ... update-initramfs: Generating /boot/initrd.img-4.4.0-121-generic Using config file '/etc/zipl.conf' Error: Ramdisk file '/boot/initrd.img' in section 'ubuntu': No such file or directory run-parts: /etc/initramfs/post-update.d//zz-zipl exited with return code 1 [1mdpkg:[0m error processing package initramfs-tools (--configure): - installed initramfs-tools package post-installation script subprocess returned error exit status 1 + installed initramfs-tools package post-installation script subprocess returned error exit status 1 Processing triggers for ca-certificates (20180409) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. Processing triggers for dictionaries-common (1.27.2) ... Processing triggers for linux-image-4.15.0-19-generic (4.15.0-19.20) ... /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img-4.15.0-19-generic Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasdb (0104). Done. /etc/kernel/postinst.d/zz-zipl: Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasdb (0104). Done. Processing triggers for sgml-base (1.29) ... Processing triggers for resolvconf (1.79ubuntu10) ... Processing triggers for ureadahead (0.100.0-20) ... Errors were encountered while processing: - initramfs-tools + initramfs-tools Log ended: 2018-04-24 13:12:40 - --- + --- ApportVersion: 2.20.9-0ubuntu6 Architecture: s390x DistroRelease: Ubuntu 18.04 Package: ubuntu-release-upgrader PackageArchitecture: all ProcEnviron: - TERM=xterm-256color - PATH=(custom, no user) - XDG_RUNTIME_DIR= - LANG=C - SHELL=/bin/bash + TERM=xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR= + LANG=C + SHELL=/bin/bash ProcVersionSignature: Ubuntu 4.15.0-19.20-generic 4.15.17 Tags: bionic Uname: Linux 4.15.0-19-generic s390x UpgradeStatus: Upgraded to bionic on 2018-04-24 (0 days ago) UserGroups: adm cdrom cpacfstats dip lpadmin plugdev sambashare sudo _MarkForUpload: True ** Description changed: [Impact] Upgrades of linux-image-generic-hwe-16.04-edge will fail to configure because the post-update script for zipl will fail. [Test Case] Upgrade linux-image-generic-hwe-16.04-edge from xenial to xenial-proposed on s390x. [Regression] zipl update on s390x might fail, causing the system to be unbootable. + + Upgrading from 16.04 to 18.04 using 'do-release-upgrade -d' results in: Errors were encountered while processing: initramfs-tools Exception during pm.DoInstall(): E:Sub-process /usr/bin/dpkg returned an error code (1) Could not install the upgrades The upgrade has aborted. Your system could be in an unusable state. A recovery will run now (dpkg --configure -a). --- Processing triggers for systemd (237-3ubuntu10) ... Processing triggers for initramfs-tools (0.130ubuntu3) ... update-initramfs: Generating /boot/initrd.img-4.4.0-121-generic Using config file '/etc/zipl.conf' Error: Ramdisk file '/boot/initrd.img' in section 'ubuntu': No such file or directory run-parts: /etc/initramfs/post-update.d//zz-zipl exited with return code 1 [1mdpkg:[0m error processing package initramfs-tools (--configure): installed initramfs-tools package post-installation script subprocess returned error exit status 1 Processing triggers for ca-certificates (20180409) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. Processing triggers for dictionaries-common (1.27.2) ... Processing triggers for linux-image-4.15.0-19-generic (4.15.0-19.20) ... /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating /boot/initrd.img
[Touch-packages] [Bug 1726930] Re: System fails to start (boot) on battery due to read-only root file-system
** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: laptop-mode-tools (Ubuntu Bionic) Importance: Undecided Status: Confirmed ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: Confirmed ** Changed in: linux (Ubuntu Bionic) Status: New => Fix Committed -- 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/1726930 Title: System fails to start (boot) on battery due to read-only root file- system Status in laptop-mode-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Fix Committed Status in systemd package in Ubuntu: Confirmed Status in laptop-mode-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Fix Committed Status in systemd source package in Bionic: Confirmed Status in systemd package in Debian: Fix Released Bug description: This report is to capture the extended diagnostic efforts done on IRC #ubuntu for user maszlo, who has a Lenovo T450 with SSD that was upgraded from 17.04 to 17.10 and since fails to complete start-up of services when powered on battery. We'd previously applied the "acpi=os=! 'acpi_osi=Windows 2015'" workaround in case this was an ACPI DSDT issue. This appears to be due to a read-only root file-system. What is not clear is how the rootfs goes read-only. The file-system (sda6, ext4) is fsck-ed successfully in the initrd according to the /run/initramfs/fsck.log. From the start-up logs (with "systemd.log_level=debug") we see the ext4 driver report a remount operation not once but five times. $ grep 'EXT4-fs.*sda6' systemd-debug.log Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null) Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro Oct 23 18:10:46 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:47 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:49 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Those last five appear to be carrying options generated by laptop- mode-tools. User has disabled laptop-mode.service and laptop-mode.timer, and lmt- poll.service, but the issue remains. We see several reports of "read-only file-system": $ grep 'Read-only' systemd-debug.log Oct 23 18:10:46 T450s grub-common[1792]: grub-editenv: error: cannot open `/boot/grub/grubenv': Read-only file system. Oct 23 18:10:46 T450s systemd[1]: colord.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gpu-manager[1797]: Warning: writing to /var/log/gpu-manager.log failed (Read-only file system) Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gdm3[1932]: Failed to create LogDir /var/log/gdm3: Read-only file system ... Oct 23 18:11:26 T450s cupsd[1461]: Unable to change ownership of "/var/log/cups" - Read-only file system Oct 23 18:11:26 T450s cupsd[1461]: Unable to open log file "/var/log/cups/access_log" - Read-only file system Oct 23 18:12:52 T450s login[9248]: pam_lastlog(login:session): unable to open /var/log/lastlog: Read-only file system We also see several problems with systemd's connection to Dbus: $ grep 'Transport endpoint' systemd-debug.log Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for 773: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: systemd-logind.service: Failed to send unit change signal for systemd-logind.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 156: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: lmt-poll.service: Failed to send unit change signal for lmt-poll.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 182: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 95: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: polkit.service: Failed to send unit change signal for polkit.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: cups-browsed.service:
[Touch-packages] [Bug 1776654] [NEW] systemd upstream sysusers tests fails
Public bug reported: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-cosmic-canonical-kernel-team- bootstrap/cosmic/amd64/s/systemd/20180613_003352_38c07@/log.gz == TEST-21-SYSUSERS == make: Entering directory '/tmp/autopkgtest.phv1ss/build.sqb/src/test/TEST-21-SYSUSERS' TEST CLEANUP: Sysuser-related tests TEST SETUP: Sysuser-related tests TEST RUN: Sysuser-related tests *** Running test-1.input *** Running test-2.input *** Running test-3.input *** Running test-4.input *** Running test unhappy-1.input --- /var/tmp/systemd-test.TjNA7s/tmp/err2018-06-13 00:22:12.805061468 + +++ unhappy-1.expected-err 2018-01-28 15:58:17.0 + @@ -1 +1 @@ -Creating user xxx (n/a) with uid 312 and gid 310. +Failed to parse UID: '99': Numerical result out of range Unexpected error output for unhappy-1.input Creating user xxx (n/a) with uid 312 and gid 310. make: *** [run] Error 1 Makefile:4: recipe for target 'run' failed make: Leaving directory '/tmp/autopkgtest.phv1ss/build.sqb/src/test/TEST-21-SYSUSERS' FAILED TESTS: test/TEST-21-SYSUSERS autopkgtest [00:22:13]: test upstream: ---] upstream FAIL non-zero exit status 1 ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Cosmic) Importance: Undecided Status: Incomplete ** Affects: systemd (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Cosmic) 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/1776654 Title: systemd upstream sysusers tests fails Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Status in linux source package in Cosmic: Incomplete Status in systemd source package in Cosmic: New Bug description: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-cosmic-canonical-kernel-team- bootstrap/cosmic/amd64/s/systemd/20180613_003352_38c07@/log.gz == TEST-21-SYSUSERS == make: Entering directory '/tmp/autopkgtest.phv1ss/build.sqb/src/test/TEST-21-SYSUSERS' TEST CLEANUP: Sysuser-related tests TEST SETUP: Sysuser-related tests TEST RUN: Sysuser-related tests *** Running test-1.input *** Running test-2.input *** Running test-3.input *** Running test-4.input *** Running test unhappy-1.input --- /var/tmp/systemd-test.TjNA7s/tmp/err 2018-06-13 00:22:12.805061468 + +++ unhappy-1.expected-err2018-01-28 15:58:17.0 + @@ -1 +1 @@ -Creating user xxx (n/a) with uid 312 and gid 310. +Failed to parse UID: '99': Numerical result out of range Unexpected error output for unhappy-1.input Creating user xxx (n/a) with uid 312 and gid 310. make: *** [run] Error 1 Makefile:4: recipe for target 'run' failed make: Leaving directory '/tmp/autopkgtest.phv1ss/build.sqb/src/test/TEST-21-SYSUSERS' FAILED TESTS: test/TEST-21-SYSUSERS autopkgtest [00:22:13]: test upstream: ---] upstream FAIL non-zero exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1776654/+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 1708409] Re: kdump service does not start after configure/reboot
It seems this has been reverted on systemd 235. However, as this might come to bite us back again in the future (it was mentioned that dependencies should not be added to aliases), and as Steve has pointed out, it makes more sense to use multi-user.target, I am going to fix it in a future release to come soon. -- 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/1708409 Title: kdump service does not start after configure/reboot Status in The Ubuntu-power-systems project: Triaged Status in makedumpfile package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Triaged Status in makedumpfile source package in Artful: New Status in systemd source package in Artful: New Status in makedumpfile source package in Bionic: Confirmed Status in systemd source package in Bionic: Triaged Bug description: == Comment: #0 - Harish Sriram - 2017-08-02 01:45:01 == kdump service does not start after configure/reboot --Problem Description--- kdump service does not start after configure/reboot. It has to be started/loaded manually, everytime after reboot. # kdump-config status current state : Not ready to kdump ---uname output--- Linux ltc-test-ci2 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:02:54 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux Machine Type/Model = Power 8/8247-22L Additional Info- # cat /proc/cmdline root=UUID=974df602-c0e4-4e67-8853-78ad15884c59 ro console=tty0 console=ttyS0,115200 quiet splash cgroup_enable=memory swapaccount=1 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M ---Steps to Reproduce--- 1. installed linux-crashdump 2. edited the kdump-tools.cfg crashkernel cmdline to above 3. update-grub 4. reboot Expected: kdump-config to be loaded by default after reboot # kdump-config status current state : Not ready to kdump # service kdump-tools status * kdump-tools.service - Kernel crash dump capture service Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor pres Active: inactive (dead) ... https://github.com/systemd/systemd/issues/6334 systemd in artful is not properly picking up the unit files in /etc/systemd/system/default.target.wants To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1708409/+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 1751345] [NEW] Timed out waiting for device dev-hvc0.device
Public bug reported: Once in a while I get: [ TIME ] Timed out waiting for device dev-hvc0.device. [DEPEND] Dependency failed for Serial Getty on hvc0. That means I cannot login to the system using the console, and sometimes it's the only method available. Console is on hvc0 itself. Happens on bionic and xenial. Cascardo. ** Affects: systemd (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/1751345 Title: Timed out waiting for device dev-hvc0.device Status in systemd package in Ubuntu: New Bug description: Once in a while I get: [ TIME ] Timed out waiting for device dev-hvc0.device. [DEPEND] Dependency failed for Serial Getty on hvc0. That means I cannot login to the system using the console, and sometimes it's the only method available. Console is on hvc0 itself. Happens on bionic and xenial. Cascardo. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1751345/+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 1708409] Re: kdump service does not start after configure/reboot
The systemd update fixes the problem for me on artful. ** Tags removed: verification-needed-artful ** Tags added: verification-done-artful ** Tags removed: verification-needed ** Tags added: verification-done -- 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/1708409 Title: kdump service does not start after configure/reboot Status in The Ubuntu-power-systems project: Incomplete Status in makedumpfile package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in makedumpfile source package in Artful: Confirmed Status in systemd source package in Artful: Fix Committed Status in makedumpfile source package in Bionic: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: == Comment: #0 - Harish Sriram - 2017-08-02 01:45:01 == kdump service does not start after configure/reboot --Problem Description--- kdump service does not start after configure/reboot. It has to be started/loaded manually, everytime after reboot. # kdump-config status current state : Not ready to kdump ---uname output--- Linux ltc-test-ci2 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:02:54 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux Machine Type/Model = Power 8/8247-22L Additional Info- # cat /proc/cmdline root=UUID=974df602-c0e4-4e67-8853-78ad15884c59 ro console=tty0 console=ttyS0,115200 quiet splash cgroup_enable=memory swapaccount=1 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M ---Steps to Reproduce--- 1. installed linux-crashdump 2. edited the kdump-tools.cfg crashkernel cmdline to above 3. update-grub 4. reboot Expected: kdump-config to be loaded by default after reboot # kdump-config status current state : Not ready to kdump # service kdump-tools status * kdump-tools.service - Kernel crash dump capture service Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor pres Active: inactive (dead) ... https://github.com/systemd/systemd/issues/6334 systemd in artful is not properly picking up the unit files in /etc/systemd/system/default.target.wants To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1708409/+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 1783881] Re: ltp-syscalls: msgstress03 fails because systemd limits number of processes
The number of processes (in systemd, tasks). The command below works for me. Now, should we change the default on our test systems? Running under systemd-run does not look like a good option. # systemd-run -p TasksMax=100 ./testcases/bin/msgstress03 -- 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/1783881 Title: ltp-syscalls: msgstress03 fails because systemd limits number of processes Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Status in systemd source package in Cosmic: Incomplete Bug description: As systemd limits the number of processes, this test will fail because it can't fork enough processes. That is limited to when the test is run after logging as user 1000, then running sudo. I guess that logging as root may not cause this to happen. # ./testcases/bin/msgstress03 Fork failed (may be OK if under stress) Fork failed (may be OK if under stress) msgstress031 TFAIL : msgstress03.c:157: Fork failed (may be OK if under stress) # To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+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 1561643] Re: initramfs-tools ignores the FRAMEBUFFER option
** Patch added: "fix for cosmic" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1561643/+attachment/5188455/+files/initramfs-tools_0.131ubuntu11.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/1561643 Title: initramfs-tools ignores the FRAMEBUFFER option Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools source package in Xenial: New Status in initramfs-tools source package in Bionic: New Bug description: initramfs-tools ignores the FRAMEBUFFER option. This means that the framebuffer hook will always include the drm modules, regardless of whether it is dealing with an encrypted system or not. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: initramfs-tools 0.122ubuntu6 ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6 Uname: Linux 4.4.0-15-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 24 18:06:24 2016 InstallationDate: Installed on 2016-02-16 (37 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160209) PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1561643/+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 1793369] Re: Ubuntu18.10:ppc64:s390x - Sysrq trigger disabled when writing to /proc/sysrq-trigger
The sysrq mechanism allows someone with physical access to the system to easily cause it to boot by just pressing some keys. That's why the sysrq default allows only very few commands to be issued. kdump is for real crashes. kdump testing may require using the sysrq-trigger mechanism, but that could just as well write to /proc/sys/kernel/sysrq before causing the crash. In fact, that's just what kdump-tools autopkgtest does. echo 1 > /proc/sys/kernel/sysrq echo c > /proc/sysrq-trigger So, not a bug here. ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Cosmic) Status: New => Won't Fix ** Changed in: linux (Ubuntu Cosmic) Status: Triaged => Invalid -- 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/1793369 Title: Ubuntu18.10:ppc64:s390x - Sysrq trigger disabled when writing to /proc /sysrq-trigger Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Status in linux source package in Cosmic: Invalid Status in systemd source package in Cosmic: Won't Fix Bug description: == Comment: #0 - Praveen K. Pandey - 2018-09-19 04:49:39 == ---Problem Description--- [Witherspoon-DD2.2][Ubu 18.10] [4.18.0-7-generic ] : Sysrq trigger disabled when writing to /proc/sysrq-trigger while testing kdump trying trigger kdump panic via /proc/sysrq-trigger it failed as : SysRq : This sysrq operation is disabled LOG: root@test:~# cat /proc/sys/kernel/sysrq 176 root@test:~# echo c > /proc/sysrq-trigger root@test:~# dmesg [ 380.340051] mlx5_core :01:00.1 enp1s0f1: Self test out: status flags(0x2) [ 389.404239] sysrq: SysRq : This sysrq operation is disabled. root@test~# cat /boot/config-4.18.0-7-generic | grep CONFIG_MAGIC_SYSRQ CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x01b6 CONFIG_MAGIC_SYSRQ_SERIAL=y root@test:~# cat /etc/sysctl.conf | grep kernel.sysrq #kernel.sysrq=438 root@test:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.18.0-7-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.18.0-7-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=c0302064-c5a3-49a7-8bd4-402283e6fcbe ro quiet splash nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@test:~# Regards Praveen == Comment: #2 - Praveen K. Pandey - 2018-09-19 05:16:11 == when i enable in /etc/sysctl.conf it works . i append below value in sysctl.conf echo "kernel.sysrq = 1" >> /etc/sysctl.conf I think this is should be enable by default in ubuntu 18.10 as earlier ubuntu distro it has , not sure why it got removed as kdump mechanism require this . Praveen Regards To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1793369/+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 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state
I managed to download the lp1778844_sys.tar.gz from FTP in time. It has some huge resource files, so I have to play a little with the tarball. It looks like some symlinks were tarred as empty files, so maybe I'll miss something, but I am investigating right now. I'll let you know if I need any other information. I will look at the other files as well. -- 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/1778844 Title: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash,kdump is not working and system enters into initramfs state Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: New Status in makedumpfile package in Ubuntu: New Status in initramfs-tools source package in Bionic: New Status in linux source package in Bionic: New Status in makedumpfile source package in Bionic: New Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 00
[Touch-packages] [Bug 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state
So, this is a multipath disk, whose parent is the nvme-subsys0 device, not nvme0 device. The latter is a PCI device, but the former is a virtual one. Some code to add slaves/holders relationships was added, but reverted. I will investigate any further discussion about this upstream, or look into how to relate those nodes in a way we can just fix this in initramfs-tools. -- 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/1778844 Title: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash,kdump is not working and system enters into initramfs state Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: New Status in makedumpfile package in Ubuntu: New Status in initramfs-tools source package in Bionic: New Status in linux source package in Bionic: New Status in makedumpfile source package in Bionic: New Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
** Summary changed: - ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash,kdump is not working and system enters into initramfs state + nvme multipath does not report path relationships -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Confirmed Status in linux source package in Cosmic: Confirmed Status in makedumpfile source package in Cosmic: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 [ 73.058099] G
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
So, the hidden disk was introduced by hch as commit 8ddcd653257c18a669fcb75ee42c37054908e0d6 just to support nvme multipath. This thing prevented lsblk from working when there were slaves under the multipath nvme, as lsblk would postpone processing those, and lsblk could not process the paths themselves, because they have no dev_t. Some discussion about reverting that slaves/holders patch is under the revert submission, and they decided to go on with the revert and think about how to fix that later. A link for one of the discussion messages is below. https://www.spinics.net/lists/stable/msg222846.html Going forward, we could either use nvme cli, embed the assumption that kernel won't change and some of the numbers are kept (like the subsys instance is embedded in both the multipath device and the underlying devices), or introduce this new paths subdir in the kernel. Any of those solutions would require changes to initramfs-tools. The latter would require a kernel change. The only way of not changing initramfs-tools is going back to using slaves relationships. That means we would need to get rid of the hidden disks thing. This always worked for dm-multipath, but I believe this required some use of blkdev and that is one thing hch wanted to avoid, to have a very fast path for doing multipath. I don't like the idea of using nvme cli that much, as it would be a hard dependency on initramfs-tools. I don't like assuming some of the implementation details on the kernel numbering/naming of those devices. So, I will take a stab at providing the paths interface. Cascardo. ** Also affects: initramfs-tools (Ubuntu Cosmic) Importance: Critical Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Also affects: linux (Ubuntu Cosmic) Importance: Critical Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Also affects: makedumpfile (Ubuntu Cosmic) Importance: Critical Assignee: Canonical Kernel Team (canonical-kernel-team) Status: New ** Changed in: makedumpfile (Ubuntu Cosmic) Status: New => Invalid ** Changed in: makedumpfile (Ubuntu Bionic) Status: New => Invalid ** Changed in: linux (Ubuntu Bionic) Status: New => Confirmed ** Changed in: linux (Ubuntu Cosmic) Status: New => Confirmed ** Changed in: initramfs-tools (Ubuntu Cosmic) Status: New => Confirmed ** Changed in: initramfs-tools (Ubuntu Bionic) Status: New => Confirmed -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Confirmed Status in linux source package in Cosmic: Confirmed Status in makedumpfile source package in Cosmic: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x2039950
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
As a workaround, I suggest setting nvme-core.ko multipath=0 parameter. Can you try that, rebooting, recreating the kdump-tools initrd, then crashing? Cascardo. -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Confirmed Status in linux source package in Cosmic: Confirmed Status in makedumpfile source package in Cosmic: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 [ 73.058099] GPR16: 0e4f79cc94b0 0e4f79d567e0 0
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
Just create a /etc/modprobe.d/nvme.conf file with the following contents, recreate initrd, remove kdump initrds so they are recreated in the next boot, then reboot. # cat /etc/modprobe.d/nvme.conf options nvme-core multipath=0 # update-initramfs -u # rm /var/lib/kdump/initrd.img* # reboot -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Confirmed Status in linux source package in Cosmic: Confirmed Status in makedumpfile source package in Cosmic: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
First piece of the puzzle submitted: http://lists.infradead.org/pipermail/linux-nvme/2018-September/020174.html Tested with a small change on initramfs-tools, though I will wait for comments on the first one before submitting that to initramfs-tools upstream. -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Confirmed Status in linux source package in Bionic: Confirmed Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Confirmed Status in linux source package in Cosmic: Confirmed Status in makedumpfile source package in Cosmic: Invalid Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a
[Touch-packages] [Bug 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state
** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: makedumpfile (Ubuntu) Importance: Undecided Status: New ** Also affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New -- 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/1778844 Title: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash,kdump is not working and system enters into initramfs state Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: New Status in makedumpfile package in Ubuntu: New Status in initramfs-tools source package in Bionic: New Status in linux source package in Bionic: New Status in makedumpfile source package in Bionic: New Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 [ 73.058099] GPR16: 0e4f79cc94b0 0e4f79d567e0 0e4f79d88204 0e4f79d56818 [
[Touch-packages] [Bug 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state
I have managed to test kdump and initramfs with MODULES=dep on an emulated nvme, using qemu. Both worked just fine. The sysfs tree seems reasonable too, in respect to how initramfs finds the necessary modules. So, I would really need the specific details on that failure case, that is, the sysfs tree and all the rest I requested in the previous message. Thank you. Cascardo. -- 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/1778844 Title: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash,kdump is not working and system enters into initramfs state Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: New Status in makedumpfile package in Ubuntu: New Status in initramfs-tools source package in Bionic: New Status in linux source package in Bionic: New Status in makedumpfile source package in Bionic: New Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a2e400 0e4f
[Touch-packages] [Bug 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state
Can you run apport-collect -p linux 1778844 ? Thank you. Cascardo. -- 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/1778844 Title: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash,kdump is not working and system enters into initramfs state Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: New Status in makedumpfile package in Ubuntu: New Status in initramfs-tools source package in Bionic: New Status in linux source package in Bionic: New Status in makedumpfile source package in Bionic: New Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 [ 73.058099] GPR16: 0e4f79cc94b0 0e4f79d567e0 0e4f79d88204 0e4f79d56818 [ 73.058099] GPR20: 0e4f79d8d5d8 0001 7efce644 [ 73.058099] GPR24: 7efce640 0e4f79d8afb4 c15e9aa8 0002 [
[Touch-packages] [Bug 1783881] [NEW] ltp-syscalls: msgstress03 fails because systemd limits number of processes
Public bug reported: As systemd limits the number of processes, this test will fail because it can't fork enough processes. That is limited to when the test is run after logging as user 1000, then running sudo. I guess that logging as root may not cause this to happen. # ./testcases/bin/msgstress03 Fork failed (may be OK if under stress) Fork failed (may be OK if under stress) msgstress031 TFAIL : msgstress03.c:157: Fork failed (may be OK if under stress) # ** Affects: linux (Ubuntu) Importance: Low Assignee: Canonical Kernel Team (canonical-kernel-team) Status: Incomplete ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu Cosmic) Importance: Low Assignee: Canonical Kernel Team (canonical-kernel-team) Status: Incomplete ** Affects: systemd (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Cosmic) Importance: Undecided => Low ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Cosmic) Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team) -- 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/1783881 Title: ltp-syscalls: msgstress03 fails because systemd limits number of processes Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: New Status in linux source package in Cosmic: Incomplete Status in systemd source package in Cosmic: New Bug description: As systemd limits the number of processes, this test will fail because it can't fork enough processes. That is limited to when the test is run after logging as user 1000, then running sudo. I guess that logging as root may not cause this to happen. # ./testcases/bin/msgstress03 Fork failed (may be OK if under stress) Fork failed (may be OK if under stress) msgstress031 TFAIL : msgstress03.c:157: Fork failed (may be OK if under stress) # To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1783881/+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 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state
Hi, Hari. The sosreport should be enough. I sent that message without an updated view of the bug, so did not notice the attachments. They came on the same day I asked. Just realized now that they are present. Let me look at them. Now, if kdump works with MODULES=most, then the PHB initialization could require a module that is not in the initramfs. I know some Intel systems require their vmd module that adds a new PCI domain. Is there some new pci host module these days on these new Power systems? Regards. Cascardo. -- 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/1778844 Title: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash,kdump is not working and system enters into initramfs state Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: New Status in makedumpfile package in Ubuntu: New Status in initramfs-tools source package in Bionic: New Status in linux source package in Bionic: New Status in makedumpfile source package in Bionic: New Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.0580
[Touch-packages] [Bug 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state
Ah, I see what you meant about the PHB. The two new attached logs are not at all similar to the original ones, maybe pointing to an unrelated problem. As for the sosreport, the /sys/ directory is missing almost everything that I would need to debug this. So, I need any other form of collecting /sys/. Maybe just tar czf lp1778844_sys.tar.gz /sys/. Cascardo. -- 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/1778844 Title: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash,kdump is not working and system enters into initramfs state Status in The Ubuntu-power-systems project: Triaged Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: New Status in makedumpfile package in Ubuntu: New Status in initramfs-tools source package in Bionic: New Status in linux source package in Bionic: New Status in makedumpfile source package in Bionic: New Bug description: Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 90001003 [ 73.058099] GPR12: c07f24a0 c7a2e400 0e4fa497c900 000
[Touch-packages] [Bug 1687791] Re: Install of kdump-tools fails
Adding initramfs-tools and nominating for bionic. ** Also affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New -- 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/1687791 Title: Install of kdump-tools fails Status in initramfs-tools package in Ubuntu: New Status in makedumpfile package in Ubuntu: Confirmed Bug description: When installing Ubuntu xenial via netimage, installation fails because of an error, when configuring the kdump-tools. /var/log/syslog says: ... May 2 22:15:17 in-target: Setting up grub2 (2.02~beta2-36ubuntu3.9) ...^M May 2 22:15:17 in-target: Setting up lxc-common (2.0.7-0ubuntu1~16.04.2) ...^M May 2 22:15:17 in-target: Running in chroot, ignoring request.^M May 2 22:15:17 in-target: invoke-rc.d: policy-rc.d denied execution of reload.^M May 2 22:15:17 in-target: Setting up grub-gfxpayload-lists (0.7) ...^M May 2 22:15:17 in-target: Processing triggers for libc-bin (2.23-0ubuntu7) ...^M May 2 22:15:17 in-target: Processing triggers for systemd (229-4ubuntu17) ...^M May 2 22:15:17 in-target: Processing triggers for ureadahead (0.100.0-19) ...^M May 2 22:15:17 in-target: Processing triggers for dbus (1.10.6-1ubuntu3.3) ...^M May 2 22:15:17 in-target: Errors were encountered while processing:^M May 2 22:15:17 in-target: kdump-tools^M May 2 22:15:17 in-target: linux-crashdump^M May 2 22:15:18 in-target: E: Sub-process /usr/bin/dpkg returned an error code (1) May 2 22:15:18 in-target: Setting up kdump-tools (1:1.5.9-5ubuntu0.4) ... May 2 22:15:18 in-target: dpkg: error processing package kdump-tools (--configure): May 2 22:15:18 in-target: subprocess installed post-installation script returned error exit status 1 May 2 22:15:18 in-target: dpkg: dependency problems prevent configuration of linux-crashdump: May 2 22:15:18 in-target: linux-crashdump depends on kdump-tools; however: May 2 22:15:18 in-target: Package kdump-tools is not configured yet. May 2 22:15:18 in-target: May 2 22:15:18 in-target: dpkg: error processing package linux-crashdump (--configure): May 2 22:15:18 in-target: dependency problems - leaving unconfigured May 2 22:15:18 in-target: Errors were encountered while processing: May 2 22:15:18 in-target: kdump-tools May 2 22:15:18 in-target: linux-crashdump May 2 22:15:18 main-menu[616]: WARNING **: Configuring 'pkgsel' failed with error code 100 May 2 22:15:18 main-menu[616]: WARNING **: Menu item 'pkgsel' failed. After this the 'Select and install software' dialog pops up and says, that 'Installation step failed'. If one presses '', one gets bombed back into the 'Ubuntu installer main menu'. Now you get into a loop, when choosing the 'Select and install software' item from the menu. Installer image is 'Linux foo 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 GNU/Linux'. The only workaround found so far is: cp -p /target/var/lib/dpkg/info/kdump-tools.postinst \ /target/var/lib/dpkg/info/kdump-tools.postinst.suck printf '#!/bin/sh\nexit 0\n' \ >/target/var/lib/dpkg/info/kdump-tools.postinst To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1687791/+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 696435] Re: wait-for-root fails to detect nbd root
** Changed in: linux (Ubuntu Xenial) Status: In Progress => Fix Committed -- 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/696435 Title: wait-for-root fails to detect nbd root Status in linux package in Ubuntu: Fix Released Status in nbd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Committed Status in systemd source package in Xenial: Incomplete Bug description: [Impact] Kernel does not generate any events when ndb-client connects /dev/nbd0 devices, therefore it is impossible to monitor/react to the state of /dev/nbd0. [Fix] Generate change uevent when size of /dev/nbd0 changes [Testcase] * Start udevadm monitor * modprobe nbd * use ndb-client to connect something to /dev/nbd0 * observe that there are change udev events generated on /dev/nbd0 itself [Regression Potential] There is no change to existing uevents, or their ordering. There is now an addition change event which will cause systemd to mark ndb devices as ready and trigger appropriate actions [Original Bug Report] When using an nbd root, wait-for-root blocks for 30 seconds before booting continues successfully. Using Ubuntu Natty, related packages versions: nbd-client 1:2.9.16-6ubuntu1 initramfs-tools 0.98.1ubuntu9 The wait-for-root call from /usr/share/initramfs-tools/scripts/local: while [ -z "${FSTYPE}" ]; do FSTYPE=$(wait-for-root "${ROOT}" ${ROOTDELAY:-30}) # Run failure hooks, hoping one of them can fix up the system # and we can restart the wait loop. If they all fail, abort # and move on to the panic handler and shell. if [ -z "${FSTYPE}" ] && ! try_failure_hooks; then break fi done I replaced wait-for-root with a sh script that did `set >&2`, here are the relevant environment variables at the time wait-for-root was called: ROOT='/dev/nbd0' ROOTDELAY='' ROOTFLAGS='' ROOTFSTYPE='' nbdroot='192.168.0.1,2011' It's probably worth noting that "nbd0: unknown partition table" was displayed asynchronously 1-2 seconds after wait-for-root was invoked and while it was still waiting. But I tried adding a "sleep 5" as the last line of local-top/nbd, so that the nbd message was displayed a lot before wait-for-root was called, and it didn't make a difference. So I don't think a race condition is involved in this problem. Temporarily I'm passing rootdelay=1 in the kernel command line to work around the problem. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/696435/+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 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps
** Changed in: linux (Ubuntu Xenial) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1567597 Title: implement 'complain mode' in seccomp for developer mode with snaps Status in Snappy: In Progress Status in libseccomp package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in libseccomp source package in Xenial: In Progress Status in linux source package in Xenial: Fix Committed Status in libseccomp source package in Zesty: In Progress Status in linux source package in Zesty: Fix Committed Bug description: A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier. Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary. UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug). [Impact] Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful). The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel. [libseccomp Test Case] A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-1): $ sudo apt build-dep -y libseccomp $ sudo apt install -y cython $ apt source libseccomp $ cd libseccomp-* $ autoreconf -ivf && ./configure --enable-python && make check-build $ (cd tests && ./regression -T live) All tests should pass on zesty (12 tests) and xenial (10 tests). On artful, you'll see one pre-existing failure: ... Test 20-live-basic_die%%002-1 result: FAILURE 20-live-basic_die TRAP rc=159 ... Regression Test Summary tests run: 12 tests skipped: 0 tests passed: 11 tests failed: 1 tests errored: 0 Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode: $ sudo apt install -y libseccomp-dev $ gcc -o lp1567597-test lp1567597-test.c -lseccomp $ ./lp1567597-test With a kernel that contains the logging patches and an updated libseccomp, the exit code should be 0 and you should have an entry in the system log that looks like this: audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c03e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc If you have an updated libseccomp with an old kernel, you'll see that seccomp_init() fails due to the added compatibility check inside of libseccomp determines that the kernel doesn't have proper support for the new log action: $ ./lp1567597-test ERROR: seccomp_init: Invalid argument [Linux Kernel Test Case] All of the libseccomp test cases apply here. Running the seccomp kernel selftests is also a great to exercise seccomp and the kernel patch set proposed for the SRU includes additional seccomp selftests. To build, enter into the root of the kernel source tree and build the seccomp test binary: $ make -C tools/testing/selftests TARGETS=seccomp Now you can execute tools/testing/selftests/seccomp/seccomp_bpf or even copy it to a test machine a
[Touch-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps
** Changed in: linux (Ubuntu Zesty) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1567597 Title: implement 'complain mode' in seccomp for developer mode with snaps Status in Snappy: In Progress Status in libseccomp package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in libseccomp source package in Xenial: In Progress Status in linux source package in Xenial: Fix Committed Status in libseccomp source package in Zesty: In Progress Status in linux source package in Zesty: Fix Committed Bug description: A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier. Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary. UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug). [Impact] Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful). The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel. [libseccomp Test Case] A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-1): $ sudo apt build-dep -y libseccomp $ sudo apt install -y cython $ apt source libseccomp $ cd libseccomp-* $ autoreconf -ivf && ./configure --enable-python && make check-build $ (cd tests && ./regression -T live) All tests should pass on zesty (12 tests) and xenial (10 tests). On artful, you'll see one pre-existing failure: ... Test 20-live-basic_die%%002-1 result: FAILURE 20-live-basic_die TRAP rc=159 ... Regression Test Summary tests run: 12 tests skipped: 0 tests passed: 11 tests failed: 1 tests errored: 0 Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode: $ sudo apt install -y libseccomp-dev $ gcc -o lp1567597-test lp1567597-test.c -lseccomp $ ./lp1567597-test With a kernel that contains the logging patches and an updated libseccomp, the exit code should be 0 and you should have an entry in the system log that looks like this: audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c03e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc If you have an updated libseccomp with an old kernel, you'll see that seccomp_init() fails due to the added compatibility check inside of libseccomp determines that the kernel doesn't have proper support for the new log action: $ ./lp1567597-test ERROR: seccomp_init: Invalid argument [Linux Kernel Test Case] All of the libseccomp test cases apply here. Running the seccomp kernel selftests is also a great to exercise seccomp and the kernel patch set proposed for the SRU includes additional seccomp selftests. To build, enter into the root of the kernel source tree and build the seccomp test binary: $ make -C tools/testing/selftests TARGETS=seccomp Now you can execute tools/testing/selftests/seccomp/seccomp_bpf or even copy it to a test machine an
[Touch-packages] [Bug 1673350] Re: dm-queue-length module is not included in installer/initramfs
** Changed in: linux (Ubuntu Xenial) Status: In Progress => Fix Committed -- 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/1673350 Title: dm-queue-length module is not included in installer/initramfs Status in hw-detect package in Ubuntu: Fix Released Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in multipath-tools package in Ubuntu: Fix Released Status in hw-detect source package in Xenial: In Progress Status in initramfs-tools source package in Xenial: Invalid Status in linux source package in Xenial: Fix Committed Status in multipath-tools source package in Xenial: In Progress Status in hw-detect source package in Yakkety: In Progress Status in initramfs-tools source package in Yakkety: Invalid Status in linux source package in Yakkety: New Status in multipath-tools source package in Yakkety: In Progress Bug description: [Impact] Multipath users using EMC XtremIO storage as boot device or at install time may run into this issue. With the module unavailable the device is more often than not unavailable. Any users changing path selector to 'queue-length' with other storage devices may also be affected. [Test case] 1) Install on multipath system using EMC XtremIO storage / OR: a) Start d-i install on qemu with multipath enabled b) exit to d-i menu c) modify /etc/multipath.conf to define path selector as 'queue-length' for the local qemu device. d) restart multipathd if necessary. 2) Try to complete the install, setting up storage as multipath and using the multipath device as boot disk. 3) Reboot to disk. In a success case, the install should complete successfully without requiring manual configuration from the user to support the multipath storage past the normal detection of multipath and partitioning. In a failure case, the install may not complete, or rebooting may fail or lead to a system booted on a single path of the multipath device (ie. / on /dev/sda2 rather than /dev/mpatha2). [Regression Potential] The inclusion of a new multipath path selector driver should not cause any regressions, but any failure to detect, configure or boot on multipath devices following this change on XtremIO hardware or otherwise would constitute a regression potentially caused by this change. --- ---Problem Description--- dm-queue-length module is not included in installer/initramfs On Ubuntu, multipath devices using the 'queue-length' path selector are non-functional on both the installer and initramfs environments; because the 'dm-queue-length' kernel module is not included in them. The multipath-modules.udeb (src:linux) does not include it in the installer, nor multipath-tools-boot (src:multipath-tools) installs it in the initramfs. One example is the EMC XtremIO storage, which has 'queue-length' defined as its path selector in the default multipath configuration, at least on 16.04. Other products may be affected if they are manually configured to use that path selector (e.g., via /etc/multipath.conf), and the mere switch of that might render the system _unbootable_ if booting from multipath, since the initramfs is affected. More recently this and another storage changed default path selectors out of 'queue-length', however, it's virtually possible for any storage system to be affected, with the described manual configuration change. So, this change is also desired on for the next stable release, 17.04, and later. Patches are provided for 16.04 and 17.04. Error logs in LP comment #6. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hw-detect/+bug/1673350/+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 1673350] Re: dm-queue-length module is not included in installer/initramfs
** Changed in: linux (Ubuntu Yakkety) Status: New => Fix Committed -- 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/1673350 Title: dm-queue-length module is not included in installer/initramfs Status in hw-detect package in Ubuntu: Fix Released Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in multipath-tools package in Ubuntu: Fix Released Status in hw-detect source package in Xenial: In Progress Status in initramfs-tools source package in Xenial: Invalid Status in linux source package in Xenial: Fix Committed Status in multipath-tools source package in Xenial: In Progress Status in hw-detect source package in Yakkety: In Progress Status in initramfs-tools source package in Yakkety: Invalid Status in linux source package in Yakkety: Fix Committed Status in multipath-tools source package in Yakkety: In Progress Bug description: [Impact] Multipath users using EMC XtremIO storage as boot device or at install time may run into this issue. With the module unavailable the device is more often than not unavailable. Any users changing path selector to 'queue-length' with other storage devices may also be affected. [Test case] 1) Install on multipath system using EMC XtremIO storage / OR: a) Start d-i install on qemu with multipath enabled b) exit to d-i menu c) modify /etc/multipath.conf to define path selector as 'queue-length' for the local qemu device. d) restart multipathd if necessary. 2) Try to complete the install, setting up storage as multipath and using the multipath device as boot disk. 3) Reboot to disk. In a success case, the install should complete successfully without requiring manual configuration from the user to support the multipath storage past the normal detection of multipath and partitioning. In a failure case, the install may not complete, or rebooting may fail or lead to a system booted on a single path of the multipath device (ie. / on /dev/sda2 rather than /dev/mpatha2). [Regression Potential] The inclusion of a new multipath path selector driver should not cause any regressions, but any failure to detect, configure or boot on multipath devices following this change on XtremIO hardware or otherwise would constitute a regression potentially caused by this change. --- ---Problem Description--- dm-queue-length module is not included in installer/initramfs On Ubuntu, multipath devices using the 'queue-length' path selector are non-functional on both the installer and initramfs environments; because the 'dm-queue-length' kernel module is not included in them. The multipath-modules.udeb (src:linux) does not include it in the installer, nor multipath-tools-boot (src:multipath-tools) installs it in the initramfs. One example is the EMC XtremIO storage, which has 'queue-length' defined as its path selector in the default multipath configuration, at least on 16.04. Other products may be affected if they are manually configured to use that path selector (e.g., via /etc/multipath.conf), and the mere switch of that might render the system _unbootable_ if booting from multipath, since the initramfs is affected. More recently this and another storage changed default path selectors out of 'queue-length', however, it's virtually possible for any storage system to be affected, with the described manual configuration change. So, this change is also desired on for the next stable release, 17.04, and later. Patches are provided for 16.04 and 17.04. Error logs in LP comment #6. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/hw-detect/+bug/1673350/+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 1648143] Re: tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor"
** Changed in: linux (Ubuntu Xenial) Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1648143 Title: tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor" Status in apparmor package in Ubuntu: Confirmed Status in linux package in Ubuntu: Fix Released Status in tor package in Ubuntu: Invalid Status in apparmor source package in Xenial: New Status in linux source package in Xenial: Fix Committed Status in tor source package in Xenial: Invalid Status in apparmor source package in Yakkety: New Status in linux source package in Yakkety: Triaged Status in tor source package in Yakkety: Invalid Bug description: Environment: Distribution: ubuntu Distribution version: 16.10 lxc info: apiextensions: storage_zfs_remove_snapshots container_host_shutdown_timeout container_syscall_filtering auth_pki container_last_used_at etag patch usb_devices https_allowed_credentials image_compression_algorithm directory_manipulation container_cpu_time storage_zfs_use_refquota storage_lvm_mount_options network profile_usedby container_push apistatus: stable apiversion: "1.0" auth: trusted environment: addresses: 163.172.48.149:8443 172.20.10.1:8443 172.20.11.1:8443 172.20.12.1:8443 172.20.22.1:8443 172.20.21.1:8443 10.8.0.1:8443 architectures: x86_64 i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificatefingerprint: 3048baa9f20d316f60a6c602452b58409a6d9e2c3218897e8de7c7c72af0179b driver: lxc driverversion: 2.0.5 kernel: Linux kernelarchitecture: x86_64 kernelversion: 4.8.0-27-generic server: lxd serverpid: 32694 serverversion: 2.4.1 storage: btrfs storageversion: 4.7.3 config: core.https_address: '[::]:8443' core.trust_password: true Container: ubuntu 16.10 Issue description -- tor can't start in a non privileged container Logs from the container: - Dec 7 15:03:00 anonymous tor[302]: Configuration was valid Dec 7 15:03:00 anonymous systemd[303]: tor@default.service: Failed at step APPARMOR spawning /usr/bin/tor: No such file or directory Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Main process exited, code=exited, status=231/APPARMOR Dec 7 15:03:00 anonymous systemd[1]: Failed to start Anonymizing overlay network for TCP. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Unit entered failed state. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Failed with result 'exit-code'. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Service hold-off time over, scheduling restart. Dec 7 15:03:00 anonymous systemd[1]: Stopped Anonymizing overlay network for TCP. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Failed to reset devices.list: Operation not permitted Dec 7 15:03:00 anonymous systemd[1]: Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted Dec 7 15:03:00 anonymous systemd[1]: message repeated 6 times: [ Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted] Dec 7 15:03:00 anonymous systemd[1]: Couldn't stat device /run/systemd/inaccessible/chr Dec 7 15:03:00 anonymous systemd[1]: Couldn't stat device /run/systemd/inaccessible/blk Dec 7 15:03:00 anonymous systemd[1]: Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted Logs from the host audit: type=1400 audit(1481119378.856:6950): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 namespace="root//lxd-anonymous_" profile="unconfined" name="system_tor" pid=12164 comm="(tor)" Steps to reproduce - install ubuntu container 16.10 on a ubuntu 16.10 host install tor in the container Launch tor To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1648143/+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 1660832] Re: unix domain socket cross permission check failing with nested namespaces
** Changed in: linux (Ubuntu Xenial) Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1660832 Title: unix domain socket cross permission check failing with nested namespaces Status in apparmor package in Ubuntu: Confirmed Status in linux package in Ubuntu: Fix Released Status in apparmor source package in Xenial: Confirmed Status in linux source package in Xenial: Fix Committed Status in apparmor source package in Yakkety: Confirmed Status in linux source package in Yakkety: Triaged Status in apparmor source package in Zesty: Confirmed Status in linux source package in Zesty: Fix Released Bug description: When using nested namespaces policy within the nested namespace is trying to cross validate with policy outside of the namespace that is not visible to it. This results the access being denied and with no way to add a rule to policy that would allow it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1660832/+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 1661030] Re: regession tests failing after stackprofile test is run
** Changed in: linux (Ubuntu Xenial) Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1661030 Title: regession tests failing after stackprofile test is run Status in apparmor package in Ubuntu: Fix Released Status in linux package in Ubuntu: Incomplete Status in apparmor source package in Xenial: Fix Committed Status in linux source package in Xenial: Fix Committed Status in apparmor source package in Yakkety: Fix Committed Status in linux source package in Yakkety: Triaged Status in apparmor source package in Zesty: Fix Released Status in linux source package in Zesty: Incomplete Bug description: from source, I'm running the tests and the makefile fails at the end with: running stackprofile Makefile:303: recipe for target 'tests' failed make: *** [tests] Error 1 No idea why that is happening. It's breaking on our kernel team regression tests runs, so can this be investigated? The source was fetched using "apt-get source apparmor". A full run is below: king@ubuntu:~/apparmor-2.10.95/tests/regression/apparmor$ sudo make USE_SYSTEM=1 tests running aa_exec running access xfail: ACCESS file rx (r) xfail: ACCESS file rwx (r) xfail: ACCESS file r (wx) xfail: ACCESS file rx (wx) xfail: ACCESS file rwx (wx) xfail: ACCESS dir rwx (r) xfail: ACCESS dir r (wx) xfail: ACCESS dir rx (wx) xfail: ACCESS dir rwx (wx) running at_secure running introspect running capabilities (ptrace) (sethostname) (setdomainname) (setpriority) (setscheduler) (reboot) (chroot) (mlockall) (net_raw) (ioperm) (iopl) running changeprofile running onexec running changehat running changehat_fork running changehat_misc *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12503 Killed $testexec "$@" > $outfile 2>&1 *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12537 Killed $testexec "$@" > $outfile 2>&1 running chdir running clone running coredump *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12803 Segmentation fault (core dumped) $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12833 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12869 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12905 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12941 Segmentation fault $testexec "$@" > $outfile 2>&1 XFAIL: Error: corefile present when not expected -- COREDUMP (ix confinement) running deleted running environ Fatal Error (environ): Unable to run test sub-executable running exec running exec_qual running fchdir running fd_inheritance running fork running i18n running link running link_subset running mkdir running mmap running mount using mount rules ... running mult_mount running named_pipe running namespaces running net_raw running open running openat running pipe running pivot_root running ptrace using ptrace v6 tests ... running pwrite running query_label Alert: query_label passed. Test 'QUERY file (all base perms #1)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #1) Alert: query_label passed. Test 'QUERY file (all base perms #2)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #2) running regex running rename running readdir running rw running socketpair running swap mkswap: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. swapon: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. running sd_flags running setattr running symlink running syscall running tcp running unix_fd_server runnin
[Touch-packages] [Bug 1660832] Re: unix domain socket cross permission check failing with nested namespaces
** Changed in: linux (Ubuntu Xenial) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1660832 Title: unix domain socket cross permission check failing with nested namespaces Status in apparmor package in Ubuntu: New Status in linux package in Ubuntu: In Progress Status in apparmor source package in Xenial: New Status in linux source package in Xenial: Fix Committed Status in apparmor source package in Yakkety: New Status in linux source package in Yakkety: Fix Committed Status in apparmor source package in Zesty: New Status in linux source package in Zesty: In Progress Bug description: When using nested namespaces policy within the nested namespace is trying to cross validate with policy outside of the namespace that is not visible to it. This results the access being denied and with no way to add a rule to policy that would allow it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1660832/+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 1645037] Re: apparmor_parser hangs indefinitely when called by multiple threads
** Changed in: linux (Ubuntu Xenial) Status: In Progress => Fix Committed ** Changed in: linux (Ubuntu Yakkety) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1645037 Title: apparmor_parser hangs indefinitely when called by multiple threads Status in apparmor package in Ubuntu: Triaged Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in linux source package in Zesty: In Progress Bug description: This bug surfaced when starting ~50 LXC container with LXD in parallel multiple times: # Create the containers for c in c foo{1..50}; do lxc launch images:ubuntu/xenial $c; done # Exectute this loop multiple times until you observe errors. for c in c foo{1..50}; do lxc restart $c & done After this you can ps aux | grep apparmor and you should see output similar to: root 19774 0.0 0.0 12524 1116 pts/1S+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo30 root 19775 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo26 root 19776 0.0 0.0 13592 3224 pts/1D+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo30 root 19778 0.0 0.0 13592 3384 pts/1D+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo26 root 19780 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo43 root 19782 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo34 root 19783 0.0 0.0 13592 3388 pts/1D+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo43 root 19784 0.0 0.0 13592 3252 pts/1D+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo34 root 19794 0.0 0.0 12524 1208 pts/1S+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo25 root 19795 0.0 0.0 13592 3256 pts/1D+ 20:14 0:00 apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache /var/lib/lxd/security/apparmor/profiles/lxd-foo25 apparmor_parser remains stuck even after all LXC/LXD commands have exited. dmesg output yields lines like: [41902.815174] audit: type=1400 audit(1480191089.678:43): apparmor="STATUS" operation="profile_load" profile="unconfined" name ="lxd-foo30_" pid=12545 comm="apparmor_parser" and cat /proc/12545/stack shows: [] aa_remove_profiles+0x88/0x270 21:19 brauner [] profile_remove+0x144/0x2e0 21:19 brauner [] __vfs_write+0x18/0x40 21:19 brauner [] vfs_write+0xb8/0x1b0 21:19 brauner [] SyS_write+0x55/0xc0 21:19 brauner [] entry_SYSCALL_64_fastpath+0x1e/0xa8 21:19 brauner [] 0x This looks like a potential kernel bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1645037/+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 1648143] Re: tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor"
** No longer affects: tor (Ubuntu) ** Also affects: tor (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1648143 Title: tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor" Status in apparmor package in Ubuntu: Confirmed Status in linux package in Ubuntu: Incomplete Status in tor package in Ubuntu: New Bug description: Environment: Distribution: ubuntu Distribution version: 16.10 lxc info: apiextensions: storage_zfs_remove_snapshots container_host_shutdown_timeout container_syscall_filtering auth_pki container_last_used_at etag patch usb_devices https_allowed_credentials image_compression_algorithm directory_manipulation container_cpu_time storage_zfs_use_refquota storage_lvm_mount_options network profile_usedby container_push apistatus: stable apiversion: "1.0" auth: trusted environment: addresses: 163.172.48.149:8443 172.20.10.1:8443 172.20.11.1:8443 172.20.12.1:8443 172.20.22.1:8443 172.20.21.1:8443 10.8.0.1:8443 architectures: x86_64 i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificatefingerprint: 3048baa9f20d316f60a6c602452b58409a6d9e2c3218897e8de7c7c72af0179b driver: lxc driverversion: 2.0.5 kernel: Linux kernelarchitecture: x86_64 kernelversion: 4.8.0-27-generic server: lxd serverpid: 32694 serverversion: 2.4.1 storage: btrfs storageversion: 4.7.3 config: core.https_address: '[::]:8443' core.trust_password: true Container: ubuntu 16.10 Issue description -- tor can't start in a non privileged container Logs from the container: - Dec 7 15:03:00 anonymous tor[302]: Configuration was valid Dec 7 15:03:00 anonymous systemd[303]: tor@default.service: Failed at step APPARMOR spawning /usr/bin/tor: No such file or directory Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Main process exited, code=exited, status=231/APPARMOR Dec 7 15:03:00 anonymous systemd[1]: Failed to start Anonymizing overlay network for TCP. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Unit entered failed state. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Failed with result 'exit-code'. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Service hold-off time over, scheduling restart. Dec 7 15:03:00 anonymous systemd[1]: Stopped Anonymizing overlay network for TCP. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Failed to reset devices.list: Operation not permitted Dec 7 15:03:00 anonymous systemd[1]: Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted Dec 7 15:03:00 anonymous systemd[1]: message repeated 6 times: [ Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted] Dec 7 15:03:00 anonymous systemd[1]: Couldn't stat device /run/systemd/inaccessible/chr Dec 7 15:03:00 anonymous systemd[1]: Couldn't stat device /run/systemd/inaccessible/blk Dec 7 15:03:00 anonymous systemd[1]: Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted Logs from the host audit: type=1400 audit(1481119378.856:6950): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 namespace="root//lxd-anonymous_" profile="unconfined" name="system_tor" pid=12164 comm="(tor)" Steps to reproduce - install ubuntu container 16.10 on a ubuntu 16.10 host install tor in the container Launch tor To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1648143/+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 1661030] Re: regession tests failing after stackprofile test is run
** Changed in: linux (Ubuntu Yakkety) Status: New => Fix Committed ** Changed in: linux (Ubuntu Xenial) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1661030 Title: regession tests failing after stackprofile test is run Status in apparmor package in Ubuntu: Fix Released Status in linux package in Ubuntu: New Status in apparmor source package in Xenial: Fix Committed Status in linux source package in Xenial: Fix Committed Status in apparmor source package in Yakkety: Fix Committed Status in linux source package in Yakkety: Fix Committed Status in apparmor source package in Zesty: Fix Released Status in linux source package in Zesty: New Bug description: from source, I'm running the tests and the makefile fails at the end with: running stackprofile Makefile:303: recipe for target 'tests' failed make: *** [tests] Error 1 No idea why that is happening. It's breaking on our kernel team regression tests runs, so can this be investigated? The source was fetched using "apt-get source apparmor". A full run is below: king@ubuntu:~/apparmor-2.10.95/tests/regression/apparmor$ sudo make USE_SYSTEM=1 tests running aa_exec running access xfail: ACCESS file rx (r) xfail: ACCESS file rwx (r) xfail: ACCESS file r (wx) xfail: ACCESS file rx (wx) xfail: ACCESS file rwx (wx) xfail: ACCESS dir rwx (r) xfail: ACCESS dir r (wx) xfail: ACCESS dir rx (wx) xfail: ACCESS dir rwx (wx) running at_secure running introspect running capabilities (ptrace) (sethostname) (setdomainname) (setpriority) (setscheduler) (reboot) (chroot) (mlockall) (net_raw) (ioperm) (iopl) running changeprofile running onexec running changehat running changehat_fork running changehat_misc *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12503 Killed $testexec "$@" > $outfile 2>&1 *** A 'Killed' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12537 Killed $testexec "$@" > $outfile 2>&1 running chdir running clone running coredump *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12803 Segmentation fault (core dumped) $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12833 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12869 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12905 Segmentation fault $testexec "$@" > $outfile 2>&1 *** A 'Segmentation Fault' message from bash is expected for the following test /home/king/apparmor-2.10.95/tests/regression/apparmor/prologue.inc: line 219: 12941 Segmentation fault $testexec "$@" > $outfile 2>&1 XFAIL: Error: corefile present when not expected -- COREDUMP (ix confinement) running deleted running environ Fatal Error (environ): Unable to run test sub-executable running exec running exec_qual running fchdir running fd_inheritance running fork running i18n running link running link_subset running mkdir running mmap running mount using mount rules ... running mult_mount running named_pipe running namespaces running net_raw running open running openat running pipe running pivot_root running ptrace using ptrace v6 tests ... running pwrite running query_label Alert: query_label passed. Test 'QUERY file (all base perms #1)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #1) Alert: query_label passed. Test 'QUERY file (all base perms #2)' was marked as expected pass but known problem (xpass) xpass: QUERY file (all base perms #2) running regex running rename running readdir running rw running socketpair running swap mkswap: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. swapon: /tmp/sdtest.21272-20356-eRXvtR/swapfile: insecure permissions 0644, 0600 suggested. running sd_flags running setattr running symlink run
[Touch-packages] [Bug 1648143] Re: tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor"
** Changed in: linux (Ubuntu Yakkety) Status: New => Fix Committed ** Changed in: linux (Ubuntu Xenial) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1648143 Title: tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor" Status in apparmor package in Ubuntu: Confirmed Status in linux package in Ubuntu: Incomplete Status in tor package in Ubuntu: New Status in apparmor source package in Xenial: New Status in linux source package in Xenial: Fix Committed Status in tor source package in Xenial: New Status in apparmor source package in Yakkety: New Status in linux source package in Yakkety: Fix Committed Status in tor source package in Yakkety: New Bug description: Environment: Distribution: ubuntu Distribution version: 16.10 lxc info: apiextensions: storage_zfs_remove_snapshots container_host_shutdown_timeout container_syscall_filtering auth_pki container_last_used_at etag patch usb_devices https_allowed_credentials image_compression_algorithm directory_manipulation container_cpu_time storage_zfs_use_refquota storage_lvm_mount_options network profile_usedby container_push apistatus: stable apiversion: "1.0" auth: trusted environment: addresses: 163.172.48.149:8443 172.20.10.1:8443 172.20.11.1:8443 172.20.12.1:8443 172.20.22.1:8443 172.20.21.1:8443 10.8.0.1:8443 architectures: x86_64 i686 certificate: | -BEGIN CERTIFICATE- -END CERTIFICATE- certificatefingerprint: 3048baa9f20d316f60a6c602452b58409a6d9e2c3218897e8de7c7c72af0179b driver: lxc driverversion: 2.0.5 kernel: Linux kernelarchitecture: x86_64 kernelversion: 4.8.0-27-generic server: lxd serverpid: 32694 serverversion: 2.4.1 storage: btrfs storageversion: 4.7.3 config: core.https_address: '[::]:8443' core.trust_password: true Container: ubuntu 16.10 Issue description -- tor can't start in a non privileged container Logs from the container: - Dec 7 15:03:00 anonymous tor[302]: Configuration was valid Dec 7 15:03:00 anonymous systemd[303]: tor@default.service: Failed at step APPARMOR spawning /usr/bin/tor: No such file or directory Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Main process exited, code=exited, status=231/APPARMOR Dec 7 15:03:00 anonymous systemd[1]: Failed to start Anonymizing overlay network for TCP. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Unit entered failed state. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Failed with result 'exit-code'. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Service hold-off time over, scheduling restart. Dec 7 15:03:00 anonymous systemd[1]: Stopped Anonymizing overlay network for TCP. Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Failed to reset devices.list: Operation not permitted Dec 7 15:03:00 anonymous systemd[1]: Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted Dec 7 15:03:00 anonymous systemd[1]: message repeated 6 times: [ Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted] Dec 7 15:03:00 anonymous systemd[1]: Couldn't stat device /run/systemd/inaccessible/chr Dec 7 15:03:00 anonymous systemd[1]: Couldn't stat device /run/systemd/inaccessible/blk Dec 7 15:03:00 anonymous systemd[1]: Failed to set devices.allow on /system.slice/system-tor.slice/tor@default.service: Operation not permitted Logs from the host audit: type=1400 audit(1481119378.856:6950): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 namespace="root//lxd-anonymous_" profile="unconfined" name="system_tor" pid=12164 comm="(tor)" Steps to reproduce - install ubuntu container 16.10 on a ubuntu 16.10 host install tor in the container Launch tor To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1648143/+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 1778844] Re: nvme multipath does not report path relationships
** Patch added: "fix for cosmic" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1778844/+attachment/5256423/+files/initramfs-tools_0.131ubuntu15.2.debdiff ** Changed in: initramfs-tools (Ubuntu Cosmic) Assignee: Canonical Kernel Team (canonical-kernel-team) => Thadeu Lima de Souza Cascardo (cascardo) ** Changed in: initramfs-tools (Ubuntu Bionic) Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo) -- 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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: In Progress Status in initramfs-tools source package in Cosmic: In Progress Status in initramfs-tools source package in Disco: Fix Released Bug description: [Impact] initramfs created with MODULES=dep or kdump initrd won't boot a system with root filesystem on a multipath nvme. [Test case] Systems with nvme multipath were able to boot with the created initramfs. Also tested on systems with non-multipath nvme, and non nvme systems. [Regression potential] A system could fail to boot because the generated initramfs was broken. The code should just add modules, which is safer than removing modules or doing any other changes. In any case, it was tested to boot on multipath nvme, non multipath nvme and non nvme systems. - Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
** Patch added: "fix for bionic" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1778844/+attachment/5256424/+files/initramfs-tools_0.130ubuntu3.8.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/1778844 Title: nvme multipath does not report path relationships Status in The Ubuntu-power-systems project: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: In Progress Status in initramfs-tools source package in Cosmic: In Progress Status in initramfs-tools source package in Disco: Fix Released Bug description: [Impact] initramfs created with MODULES=dep or kdump initrd won't boot a system with root filesystem on a multipath nvme. [Test case] Systems with nvme multipath were able to boot with the created initramfs. Also tested on systems with non-multipath nvme, and non nvme systems. [Regression potential] A system could fail to boot because the generated initramfs was broken. The code should just add modules, which is safer than removing modules or doing any other changes. In any case, it was tested to boot on multipath nvme, non multipath nvme and non nvme systems. - Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269f
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
@vorlon, test case updated. Thanks. Cascardo. ** Description changed: [Impact] initramfs created with MODULES=dep or kdump initrd won't boot a system with root filesystem on a multipath nvme. [Test case] Systems with nvme multipath were able to boot with the created initramfs. Also tested on systems with non-multipath nvme, and non nvme systems. + In order to verify the fix, one needs to change MODULES option to dep on + /etc/initramfs-tools/initramfs.conf, recreate initramfs and reboot, + check the system has booted fine. That should not break on systems with + non nvme disks or systems with non multipath nvme systems, and that + should now work on multipath nvme systems. + + sed -i /MODULES=/s,=.*,=dep, /etc/initramfs-tools/initramfs.conf + update-initramfs -u -k all + reboot + [Regression potential] A system could fail to boot because the generated initramfs was broken. The code should just add modules, which is safer than removing modules or doing any other changes. In any case, it was tested to boot on multipath nvme, non multipath nvme and non nvme systems. - - - Problem Description: === After triggering crash ,kdump is not working & system enters into initramfs state Steps to re-create: == >. woo is installed ubuntu180401 kernel root@woo:~# uname -a Linux woo 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 17:59:00 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux root@woo:~# >. Crashkernel value as below root@woo:~# free -h totalusedfree shared buff/cache available Mem: 503G2.0G501G 13M279M 499G Swap: 2.0G 0B2.0G root@woo:~# cat /proc/cmdline root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet crashkernel=8192M > kdump status root@woo:~# kdump-config status current state : ready to kdump root@woo:~# kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinux-4.15.0-23-generic kdump initrd: /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-23-generic current state:ready to kdump kexec command: /sbin/kexec -p --command-line="root=UUID=45bb7eb2-4c61-425d-8bf9-4e6f16829ddb ro splash quiet nr_cpus=1 systemd.unit=kdump-tools.service irqpoll noirqdistrib nousb" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz root@woo:~# dmesg | grep Reser [0.00] Reserving 8192MB of memory at 128MB for crashkernel (System RAM: 524288MB) [0.00] cma: Reserved 26224 MiB at 0x20399500 [3.545490] Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term "Broadcom" refers to Broadcom Limited and/or its subsidiaries. > Triggered crash root@woo:~# echo 1 > /proc/sys/kernel/sysrq root@woo:~# echo c > /proc/sysrq-trigger [ 73.056308] sysrq: SysRq : Trigger a crash [ 73.056357] Unable to handle kernel paging request for data at address 0x [ 73.056459] Faulting instruction address: 0xc07f24c8 [ 73.056543] Oops: Kernel access of bad area, sig: 11 [#1] [ 73.056609] LE SMP NR_CPUS=2048 NUMA PowerNV [ 73.056668] Modules linked in: rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_uverbs(OE) ib_umad(OE) esp6_offload esp6 esp4_offload esp4 xfrm_algo mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) rpcsec_gss_krb5 nfsv4 nfs fscache binfmt_misc idt_89hpesx vmx_crypto crct10dif_vpmsum ofpart cmdlinepart ipmi_powernv ipmi_devintf at24 powernv_flash ipmi_msghandler ibmpowernv mtd opal_prd uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd sch_fq_codel grace sunrpc knem(OE) ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq mlx5_ib(OE) ib_core(OE) nouveau lpfc ast i2c_algo_bit ttm mlx5_core(OE) drm_kms_helper mlxfw(OE) nvmet_fc devlink syscopyarea nvmet mlx_compat(OE) sysfillrect cxl nvme_fc sysimgblt fb_sys_fops nvme_fabrics nvme ahci crc32c_vpmsum drm scsi_transport_fc [ 73.057601] tg3 libahci nvme_core pnv_php [ 73.057652] CPU: 44 PID: 4626 Comm: bash Tainted: G OE 4.15.0-23-generic #25-Ubuntu [ 73.057767] NIP: c07f24c8 LR: c07f3568 CTR: c07f24a0 [ 73.057868] REGS: c03f8269f9f0 TRAP: 0300 Tainted: G OE (4.15.0-23-generic) [ 73.057986] MSR: 90009033 CR: 2822 XER: 2004 [ 73.058099] CFAR: c07f3564 DAR: DSISR: 4200 SOFTE: 1 [ 73.058099] GPR00: c07f3568 c03f8269fc70 c16eaf00 0063 [ 73.058099] GPR04: c03fef47ce18 c03fef494368 90009033 31da0058 [ 73.058099] GPR08: 0007 0001 0
[Touch-packages] [Bug 1825420] Re: package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to install/upgrade: triggers looping, abandoned
** Changed in: linux (Ubuntu) Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo) ** Changed in: linux (Ubuntu) Importance: Undecided => High ** Changed in: linux (Ubuntu) Status: Confirmed => 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/1825420 Title: package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to install/upgrade: triggers looping, abandoned Status in Ubuntu MATE: New Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: In Progress Status in linux-firmware package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Have Ubuntu 18.10 installed 2. Install all updates to it 3. Switch to Main server 4. Launch update-manager 5. Confirm upgrading to 19.04 6. Wait for upgrade process to finish Expected results: * upgrade process ended without errors Actual results: * upgrade process ended with warning message: Could not install 'linux-image-5.0.0-13-generic' The upgrade will continue but the 'linux-image-5.0.0-13-generic' package may not be in a working state. Please consider submitting a bug report about it. triggers looping, abandoned Workaround: Run recommended `dpkg --configure -a` before actual reboot. System info: running VirtualBox guest with virtualbox-guest-x11 (6.0.6-dfsg-1) inside VirtualBox 5.1.38 host. ProblemType: Package DistroRelease: Ubuntu 19.04 Package: linux-image-5.0.0-13-generic 5.0.0-13.14 ProcVersionSignature: Ubuntu 4.18.0-17.18-generic 4.18.20 Uname: Linux 4.18.0-17-generic x86_64 ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: mate 1542 F pulseaudio Date: Thu Apr 18 22:56:56 2019 ErrorMessage: triggers looping, abandoned InstallationDate: Installed on 2019-02-17 (60 days ago) InstallationMedia: Ubuntu-MATE 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) IwConfig: lono wireless extensions. enp0s3no wireless extensions. Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub MachineType: innotek GmbH VirtualBox ProcFB: 0 vboxdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-17-generic root=UUID=01417e27-d554-4ce8-91bc-1dda8392c976 ro quiet splash PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied No PulseAudio daemon running, or not running as session daemon. Python3Details: /usr/bin/python3.7, Python 3.7.3, python3-minimal, 3.7.3-1 PythonDetails: /usr/bin/python2.7, Python 2.7.16, python-minimal, 2.7.16-1 RelatedPackageVersions: grub-pc 2.02+dfsg1-12ubuntu2 RfKill: SourcePackage: linux StagingDrivers: vboxvideo Title: package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to install/upgrade: triggers looping, abandoned UpgradeStatus: Upgraded to disco on 2019-04-18 (0 days ago) dmi.bios.date: 12/01/2006 dmi.bios.vendor: innotek GmbH dmi.bios.version: VirtualBox dmi.board.name: VirtualBox dmi.board.vendor: Oracle Corporation dmi.board.version: 1.2 dmi.chassis.type: 1 dmi.chassis.vendor: Oracle Corporation dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr: dmi.product.family: Virtual Machine dmi.product.name: VirtualBox dmi.product.version: 1.2 dmi.sys.vendor: innotek GmbH To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-mate/+bug/1825420/+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 1825420] Re: package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to install/upgrade: triggers looping, abandoned
Upgrading a cloud image, I couldn't reproduce it. I also tried installing mate-desktop-environment-core + mate-dock-applet (because it depends on bamfdaemon) before upgrading, and still couldn't reproduce. I will install a cosmic mate desktop and see if I can reproduce this problem when upgrading. However, the dpkg terminal log mentions bamfdaemon and mime-support as possible culprits on the trigger loop. So I am adding these and dpkg as well to the bug. In my opinion, this sounds more like a symptom of some trigger loop not caused by the kernel that causes dpkg to stop, which leaves the kernel unconfigured. ** Also affects: bamf (Ubuntu) Importance: Undecided Status: New ** Also affects: mime-support (Ubuntu) Importance: Undecided Status: New ** Also affects: dpkg (Ubuntu) Importance: Undecided Status: New -- 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/1825420 Title: package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to install/upgrade: triggers looping, abandoned Status in Ubuntu MATE: New Status in bamf package in Ubuntu: New Status in dpkg package in Ubuntu: New Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: In Progress Status in linux-firmware package in Ubuntu: Confirmed Status in mime-support package in Ubuntu: New Bug description: Steps to reproduce: 1. Have Ubuntu 18.10 installed 2. Install all updates to it 3. Switch to Main server 4. Launch update-manager 5. Confirm upgrading to 19.04 6. Wait for upgrade process to finish Expected results: * upgrade process ended without errors Actual results: * upgrade process ended with warning message: Could not install 'linux-image-5.0.0-13-generic' The upgrade will continue but the 'linux-image-5.0.0-13-generic' package may not be in a working state. Please consider submitting a bug report about it. triggers looping, abandoned Workaround: Run recommended `dpkg --configure -a` before actual reboot. System info: running VirtualBox guest with virtualbox-guest-x11 (6.0.6-dfsg-1) inside VirtualBox 5.1.38 host. ProblemType: Package DistroRelease: Ubuntu 19.04 Package: linux-image-5.0.0-13-generic 5.0.0-13.14 ProcVersionSignature: Ubuntu 4.18.0-17.18-generic 4.18.20 Uname: Linux 4.18.0-17-generic x86_64 ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: mate 1542 F pulseaudio Date: Thu Apr 18 22:56:56 2019 ErrorMessage: triggers looping, abandoned InstallationDate: Installed on 2019-02-17 (60 days ago) InstallationMedia: Ubuntu-MATE 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) IwConfig: lono wireless extensions. enp0s3no wireless extensions. Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub MachineType: innotek GmbH VirtualBox ProcFB: 0 vboxdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-17-generic root=UUID=01417e27-d554-4ce8-91bc-1dda8392c976 ro quiet splash PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied No PulseAudio daemon running, or not running as session daemon. Python3Details: /usr/bin/python3.7, Python 3.7.3, python3-minimal, 3.7.3-1 PythonDetails: /usr/bin/python2.7, Python 2.7.16, python-minimal, 2.7.16-1 RelatedPackageVersions: grub-pc 2.02+dfsg1-12ubuntu2 RfKill: SourcePackage: linux StagingDrivers: vboxvideo Title: package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to install/upgrade: triggers looping, abandoned UpgradeStatus: Upgraded to disco on 2019-04-18 (0 days ago) dmi.bios.date: 12/01/2006 dmi.bios.vendor: innotek GmbH dmi.bios.version: VirtualBox dmi.board.name: VirtualBox dmi.board.vendor: Oracle Corporation dmi.board.version: 1.2 dmi.chassis.type: 1 dmi.chassis.vendor: Oracle Corporation dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr: dmi.product.family: Virtual Machine dmi.product.name: VirtualBox dmi.product.version: 1.2 dmi.sys.vendor: innotek GmbH To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-mate/+bug/1825420/+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 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
With systemd storage test, I got two different situations: Also on amd64, the test is still flaky, it needs to wait for the unit to be active before stopping it, otherwise it's canceled. I will send a comment with a preview of a fix. On ppc64el, however, even after that fix, the patch will fail once in a while, with /lib/systemd/systemd-cryptsetup crashing on an invalid free. I started investigating that, but still can't figure what the real problem is. Maybe some corruption going on, but really hard to catch when, as running under valgrind doesn't allow the bug to be reproduced. Cascardo. -- 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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+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 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
Still need to fix it so it will exit when unit is failed, and maybe after some timeout. --- debian/tests/storage | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/tests/storage b/debian/tests/storage index 04d11c8..47fbe81 100755 --- a/debian/tests/storage +++ b/debian/tests/storage @@ -73,6 +73,8 @@ class CryptsetupTest(FakeDriveTestBase): subprocess.call(['umount', self.plaintext_dev], stderr=subprocess.DEVNULL) subprocess.call(['systemctl', 'start', '--no-ask-password', 'systemd-cryptsetup@%s.service' % self.plaintext_name], stderr=subprocess.STDOUT) +while subprocess.call(['systemctl', 'is-active', 'systemd-cryptsetup@%s.service' % self.plaintext_name], stderr=subprocess.STDOUT) != 0: +pass subprocess.call(['systemctl', 'stop', 'systemd-cryptsetup@%s.service' % self.plaintext_name], stderr=subprocess.STDOUT) if os.path.exists('/etc/crypttab'): -- -- 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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+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 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
So, I tested with a 4.18 kernel and I could still reproduce the issue on eoan. Then, I tested on a bionic system, 4.15 kernel, systemd 237, glibc 2.27, and I see a failure on malloc, also memory corruption. This appears on the backtrace. 3738malloc_printerr ("malloc(): memory corruption"); I am going back to xenial. Cascardo. ** Also affects: linux (Ubuntu Eoan) Importance: Undecided Status: Confirmed ** Also affects: systemd (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: udisks2 (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: udisks2 (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: udisks2 (Ubuntu Bionic) 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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Status in linux source package in Bionic: New Status in systemd source package in Bionic: New Status in udisks2 source package in Bionic: New Status in linux source package in Disco: New Status in systemd source package in Disco: New Status in udisks2 source package in Disco: New Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: New Status in udisks2 source package in Eoan: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+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 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
It goes back to xenial. I think I found the cause on systemd, will test a fix and report back soon. -- 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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Status in linux source package in Bionic: New Status in systemd source package in Bionic: New Status in udisks2 source package in Bionic: New Status in linux source package in Disco: New Status in systemd source package in Disco: New Status in udisks2 source package in Disco: New Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: New Status in udisks2 source package in Eoan: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+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 1817721] Re: autopkgtest success rate in Bionic reached an unusable amount
So after some investigation on systemd failures on ppc64el triggered by the kernel on eoan, I noticed some coredumps on processes when running under qemu inside the ADT environment. As one of these processes is sleep, I am pretty confident this is caused by the lack of emulation or rather the failure to ignore mffsl extra bits, aka LP: #1847806. I am not sure this is the right bug as it mentions lots of other upstream failures across all arches. But it looks like the ones we are seeing, and as we are referring this bug in our results, I thought it was worht mentioning. Cascardo. -- 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/1817721 Title: autopkgtest success rate in Bionic reached an unusable amount Status in systemd package in Ubuntu: Confirmed Bug description: Hi, Sorry to bother you - it seems we have this discussion every few months or so. I was looking at this due to an SRU and I realized that the last 50-100 tests on all architectures are currently failing. http://autopkgtest.ubuntu.com/packages/s/systemd/bionic/amd64 http://autopkgtest.ubuntu.com/packages/s/systemd/bionic/i386 http://autopkgtest.ubuntu.com/packages/s/systemd/bionic/ppc64el http://autopkgtest.ubuntu.com/packages/s/systemd/bionic/s390x On one hand I see the known flaky boot-and-smoke but that is fine. On the other hand I see the test "upstream" failing always and it seems not related to the actual proposed packages. Please help to resolve this mid-term. Short term I'll submit a force-badtest for this as it seems to hold up more and more with no gain of seeing plenty of peopl just hitting retry every now and then. If test "upstream" is utterly broken consider skipping it in the next upload that you do for regular service. That would bring back at least the remaining tests coverage. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1817721/+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 1891565] Re: oss4 does not build on ppc64el on groovy
** Also affects: binutils (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1891565 Title: oss4 does not build on ppc64el on groovy Status in binutils package in Ubuntu: New Status in oss4 package in Ubuntu: In Progress Bug description: When building the focal version of oss4 with groovy version of binutils, it fails with: /tmp/ccoZchTf.s: Assembler messages: /tmp/ccoZchTf.s: Error: invalid attempt to declare external version name as default in symbol `.snd_pcm_hw_params_set_rate_near@@ALSA_0.9.0rc4' make[1]: *** [Makefile:16: pcm.lo] Error 1 Downgrading binutils to 2.34-6ubuntu1 fixes the problem. This works with gcc-9 9.3.0-10ubuntu2. Upgrading to groovy gcc-9 9.3.0-17ubuntu1 will force the upgrade of binutils, so can't be tested with the working version of binutils. Using the latest version of gcc-9 or gcc-10 from groovy with the broken binutils is still broken, so a complete upgrade does not fix the problem. The following diff does fix the problem with binutils 2.35-2ubuntu1, though: $ diff -u lib/libsalsa/alsa-symbols.h.old lib/libsalsa/alsa-symbols.h --- lib/libsalsa/alsa-symbols.h.old 2020-08-13 22:47:28.249358919 + +++ lib/libsalsa/alsa-symbols.h 2020-08-13 22:43:35.730423956 + @@ -35,7 +35,7 @@ __asm__ (".symver ." #real ",." #name "@" #version) # define default_symbol_version(real, name, version) \ __asm__ (".symver " #real "," #name "@@" #version); \ - __asm__ (".symver ." #real ",." #name "@@" #version) +// __asm__ (".symver ." #real ",." #name "@@" #version) #else # define symbol_version(real, name, version) \ __asm__ (".symver " #real "," #name "@" #version) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1891565/+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 1891565] Re: oss4 does not build on ppc64el on groovy
So, dot-symbols on powerpc are not a thing on userspace since a while (from gcc 3.4 times). And, then, I realized this header comes directly from alsa, and for a different reason, this same section has already been dropped there. So applying the same changes makes sense here. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1891565 Title: oss4 does not build on ppc64el on groovy Status in binutils package in Ubuntu: New Status in oss4 package in Ubuntu: In Progress Bug description: When building the focal version of oss4 with groovy version of binutils, it fails with: /tmp/ccoZchTf.s: Assembler messages: /tmp/ccoZchTf.s: Error: invalid attempt to declare external version name as default in symbol `.snd_pcm_hw_params_set_rate_near@@ALSA_0.9.0rc4' make[1]: *** [Makefile:16: pcm.lo] Error 1 Downgrading binutils to 2.34-6ubuntu1 fixes the problem. This works with gcc-9 9.3.0-10ubuntu2. Upgrading to groovy gcc-9 9.3.0-17ubuntu1 will force the upgrade of binutils, so can't be tested with the working version of binutils. Using the latest version of gcc-9 or gcc-10 from groovy with the broken binutils is still broken, so a complete upgrade does not fix the problem. The following diff does fix the problem with binutils 2.35-2ubuntu1, though: $ diff -u lib/libsalsa/alsa-symbols.h.old lib/libsalsa/alsa-symbols.h --- lib/libsalsa/alsa-symbols.h.old 2020-08-13 22:47:28.249358919 + +++ lib/libsalsa/alsa-symbols.h 2020-08-13 22:43:35.730423956 + @@ -35,7 +35,7 @@ __asm__ (".symver ." #real ",." #name "@" #version) # define default_symbol_version(real, name, version) \ __asm__ (".symver " #real "," #name "@@" #version); \ - __asm__ (".symver ." #real ",." #name "@@" #version) +// __asm__ (".symver ." #real ",." #name "@@" #version) #else # define symbol_version(real, name, version) \ __asm__ (".symver " #real "," #name "@" #version) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1891565/+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 1891565] Re: oss4 does not build on ppc64el on groovy
Now building on ppa:cascardo/ppa. ** Patch added: "Fix for groovy" https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1891565/+attachment/5401581/+files/oss4_4.2-build2010-5ubuntu7.debdiff ** Changed in: binutils (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1891565 Title: oss4 does not build on ppc64el on groovy Status in binutils package in Ubuntu: Invalid Status in oss4 package in Ubuntu: In Progress Bug description: When building the focal version of oss4 with groovy version of binutils, it fails with: /tmp/ccoZchTf.s: Assembler messages: /tmp/ccoZchTf.s: Error: invalid attempt to declare external version name as default in symbol `.snd_pcm_hw_params_set_rate_near@@ALSA_0.9.0rc4' make[1]: *** [Makefile:16: pcm.lo] Error 1 Downgrading binutils to 2.34-6ubuntu1 fixes the problem. This works with gcc-9 9.3.0-10ubuntu2. Upgrading to groovy gcc-9 9.3.0-17ubuntu1 will force the upgrade of binutils, so can't be tested with the working version of binutils. Using the latest version of gcc-9 or gcc-10 from groovy with the broken binutils is still broken, so a complete upgrade does not fix the problem. The following diff does fix the problem with binutils 2.35-2ubuntu1, though: $ diff -u lib/libsalsa/alsa-symbols.h.old lib/libsalsa/alsa-symbols.h --- lib/libsalsa/alsa-symbols.h.old 2020-08-13 22:47:28.249358919 + +++ lib/libsalsa/alsa-symbols.h 2020-08-13 22:43:35.730423956 + @@ -35,7 +35,7 @@ __asm__ (".symver ." #real ",." #name "@" #version) # define default_symbol_version(real, name, version) \ __asm__ (".symver " #real "," #name "@@" #version); \ - __asm__ (".symver ." #real ",." #name "@@" #version) +// __asm__ (".symver ." #real ",." #name "@@" #version) #else # define symbol_version(real, name, version) \ __asm__ (".symver " #real "," #name "@" #version) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1891565/+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 1866012] Re: depmod ERROR during Setting up linux-modules-5.4.0-17-generic
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948350#20 In particular, this seems to come to a Debian specific patch on kmod that turns that message from a DEBUG message to an ERROR message. As there has been no responses from the patch's author, we could do a quick diligence investigation in order to drop it. Or we should just simply drop it. That way, we get rid of spurious bug reports, and can work on real bugs, in case there is any, and we should get reports for those. Cascardo. ** Bug watch added: Debian Bug tracker #948350 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948350 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1866012 Title: depmod ERROR during Setting up linux-modules-5.4.0-17-generic Status in kmod package in Ubuntu: New Status in linux package in Ubuntu: Invalid Bug description: Steps to reproduce: 1. Deploy Focal on a KVM ndoe, enable proposed 2. Run sudo apt dist-upgrade The console will be flushed with: Setting up libisc1105:amd64 (1:9.11.16+dfsg-3~build1) ... Setting up linux-modules-5.4.0-17-generic (5.4.0-17.21) ... depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-17-generic/modules.builtin.bin' Setting up apt-utils (1.9.12) ... Setting up libselinux1-dev:amd64 (3.0-1build2) ... Setting up libglib2.0-0:amd64 (2.64.0-1) ... ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-14-generic 5.4.0-14.17 ProcVersionSignature: User Name 5.4.0-14.17-generic 5.4.18 Uname: Linux 5.4.0-14-generic x86_64 AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Mar 4 08:29 seq crw-rw 1 root audio 116, 33 Mar 4 08:29 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: Date: Wed Mar 4 09:06:42 2020 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M MachineType: QEMU Standard PC (i440FX + PIIX, 1996) PciMultimedia: ProcFB: 0 cirrusdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-14-generic root=UUID=36e162f3-41b5-4487-a6dc-09ba4e37d3bf ro console=tty1 console=ttyS0 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux-5.4 StagingDrivers: exfat UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.10.2-1ubuntu1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-i440fx-bionic dmi.modalias: dmi:bvnSeaBIOS:bvr1.10.2-1ubuntu1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-bionic:cvnQEMU:ct1:cvrpc-i440fx-bionic: dmi.product.name: Standard PC (i440FX + PIIX, 1996) dmi.product.version: pc-i440fx-bionic dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1866012/+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 1864992] Re: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'
https://lore.kernel.org/lkml/20200311170120.12641-1-j...@kernel.org/T/#u This patch just caught my attention. I didn't do any investigation, but as I recall seeing something about namespaces, maybe this is related. Cascardo. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to kmod in Ubuntu. https://bugs.launchpad.net/bugs/1864992 Title: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' Status in curtin: Invalid Status in subiquity: Invalid Status in kmod package in Ubuntu: In Progress Bug description: During a Focal install from the ISO image several errors like: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin' are logged in curtin's install logs. The installed system boots and works fine, but the error is clearly something we want to get rid of. At first glance this seems related to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1863261 but the version of initramfs-tools in both the installer and installed system (checked with `chroot /target dpkg -l initramfs-tools` during the installation) is 0.136ubuntu1, which should contain Rafael's fix for that bug. I wonder if the update-initramfs diversion has a role here. I verified this happens at least on amd64 and arm64. I'm attaching the full install logs for a amd64 installation. --- ProblemType: Bug AlsaVersion: Advanced Linux Sound Architecture Driver Version k5.4.0-14-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperVersion: 1.439 DistroRelease: Ubuntu 20.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200225) Lsusb: Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair Package: linux (not installed) ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 ProcFB: 0 qxldrmfb ProcKernelCmdLine: initrd=/casper/initrd quiet --- maybe-ubiquity ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18 RelatedPackageVersions: linux-restricted-modules-5.4.0-14-generic N/A linux-backports-modules-5.4.0-14-generic N/A linux-firmware1.186 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: focal uec-images Uname: Linux 5.4.0-14-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 04/01/2014 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.13.0-1 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-4.2 dmi.modalias: dmi:bvnSeaBIOS:bvr1.13.0-1:bd04/01/2014:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-4.2:cvnQEMU:ct1:cvrpc-q35-4.2: dmi.product.name: Standard PC (Q35 + ICH9, 2009) dmi.product.version: pc-q35-4.2 dmi.sys.vendor: QEMU To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1864992/+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