[Touch-packages] [Bug 1961425] Re: 22.04: FTBFS due to test failure
As 0.8.0-2ubuntu2 has fixed the build issue, marking this bug as "Fix Released". Please feel free to revert if the issue is persisting. ** Changed in: capnproto (Ubuntu) Status: Confirmed => Fix Released ** Changed in: ubuntu-power-systems Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to capnproto in Ubuntu. https://bugs.launchpad.net/bugs/1961425 Title: 22.04: FTBFS due to test failure Status in The Ubuntu-power-systems project: Fix Released Status in capnproto package in Ubuntu: Fix Released Bug description: Hi, capnproto 0.8.0-2ubuntu1 fails on ppc64el : https://launchpad.net/ubuntu/+source/capnproto/0.8.0-2ubuntu1/+build/23090234/+files/buildlog_ubuntu-jammy-ppc64el.capnproto_0.8.0-2ubuntu1_BUILDING.txt.gz Lowering optimization (O3->O2) level makes the failing test pass, for instance adding export DEB_CXXFLAGS_MAINT_APPEND=-O1 export DEB_CXXFLAGS_MAINT_STRIP=-O3 in debian/rules. For the time being that can be the way to go as 0.9.1-2 from Debian Experimental builds fine on Jammy by default with O3. F. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1961425/+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 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1898547 Title: neutron-linuxbridge-agent fails to start with iptables 1.8.5 Status in Ubuntu on IBM z Systems: Fix Released Status in iptables package in Ubuntu: Fix Released Status in neutron package in Ubuntu: Invalid Status in iptables source package in Groovy: Fix Released Status in neutron source package in Groovy: Invalid Status in iptables source package in Hirsute: Fix Released Status in neutron source package in Hirsute: Invalid Bug description: [Impact] With iptables 1.8.5 neutron-linuxbridge-agent fails to properly start. The log file shows many errors like: 2020-10-05 10:20:37.998 551 ERROR neutron.plugins.ml2.drivers.agent._common_agent ; Stdout: ; Stderr: iptables-restore: line 29 failed This can be demonstrated with a simple test case: iptables-restore
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1899621 Title: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: Description: zlib: inflateSyncPoint() returns an incorrect result on z15 Symptom: Certain rsync builds fail with "error in rsync protocol data stream" on z15. Problem: inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. Solution: Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1899621/+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 1882494] Re: [UBUNTU 20.04] zlib not working on all s390x systems configurations
@heinz-werner_seeck, this has been scheduled into the relevant team's current 2-weekly cycle. As usual we'll share progress and updates in this ticket. Thanks. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1882494 Title: [UBUNTU 20.04] zlib not working on all s390x systems configurations Status in Ubuntu on IBM z Systems: Triaged Status in zlib package in Ubuntu: New Status in zlib source package in Eoan: Won't Fix Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: Pull request (https://github.com/madler/zlib/pull/410) and tagged https://github.com/iii-i/zlib/tree/dfltcc-20200511. The new code contains the following improvements: * Added support for switching between software and hardware compression. * Added --dfltcc configure flag (the old way of building it still works). Switching between software and hardware compression is not simply a nice-to-have feature, but is actually required by Java - that's why we are requesting an update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1882494/+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 1873961] Re: tc filter show tcp_flags wrong mask value
** Changed in: ubuntu-power-systems Status: Fix Committed => Fix Released -- 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/1873961 Title: tc filter show tcp_flags wrong mask value Status in The Ubuntu-power-systems project: Fix Released Status in iproute2 package in Ubuntu: Fix Released Status in iproute2 source package in Bionic: Fix Released Bug description: [SRU Justification] Impact: The tc command does not show the correct values for tcp_flags (and ip_tos) on filter rules. This might break other scripts parsing that output but at least confuses users. Fix: Backport of "tc: fix bugs for tcp_flags and ip_attr hex output" from upstream iproute2. Testcase: tc qdisc add dev lo ingress tc filter add dev lo parent : prio 3 proto ip flower ip_tos 0x8/32 tc filter add dev lo parent : prio 5 proto ip flower ip_proto tcp \ tcp_flags 0x909/f00 tc filter show dev lo parent : filter protocol ip pref 3 flower chain 0 filter protocol ip pref 3 flower chain 0 handle 0x1 eth_type ipv4 ip_tos a9606c10 <-- bad, should be 0x8/32 not_in_hw filter protocol ip pref 5 flower chain 0 filter protocol ip pref 5 flower chain 0 handle 0x1 eth_type ipv4 ip_proto tcp tcp_flags 909909 <-- bad, should be 0x909/f00 not_in_hw Note that the ip_tos value in the -j[son] output is correct, while the tcp_flags value is is incorrect in both cases. Risk of Regression: Low: Usually scripts would use the json output and that has at least the ip output correct. And the values shown in the bad case seem to be little useful. So it seems unlikely anybody relied on them. But cannot completely be ruled out. === Original description === ---Problem Description--- Problem Descriptions "tc" utility does not show correct TC rule's tcp_flags mask correctly in current "iproute2" package shipped on Genesis. # dpkg -l |grep iproute2 ii iproute2 4.15.0-2ubuntu1 ppc64el networking and traffic control tools ---Steps to Reproduce--- Steps to reproduce the problem: 1) Add a tc rule to the testing VF (i.e. p0v2_r): # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1 flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 2 skip_sw action mirred egress redirect dev p0v0_r 2) Validate the added TC rule: # tc filter show dev p0v2_r root filter protocol ip pref 5 flower chain 1 filter protocol ip pref 5 flower chain 1 handle 0x1 src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff eth_type ipv4 ip_proto tcp tcp_flags 22 /* <--- Wrong */ skip_sw in_hw action order 1: mirred (Egress Redirect to device p0v0_r) stolen 3) If we add the tcp_flags using explicit mask 0x7: # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1 flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 0x2/7 skip_sw action mirred egress redirect dev p0v0_r After that, using "tc filter show dev p0v2_r root" to verify, we still see the same output (tcp_flags 22) as shown in 2) above, which is wrong. Userspace tool common name: tc The userspace tool has the following bit modes: 64-bit Userspace package: iproute2 == Fixes: There are 2 patches to fix the issue: patch 1: commit b85076cd74e77538918d35992b1a9cd17ff86af8 Author: Stephen Hemminger Date: Tue Sep 11 08:29:33 2018 -0700 lib: introduce print_nl Common pattern in iproute commands is to print a line seperator in non-json mode. Make that a simple function. /* This patch declares global variable "const char *_SL_ = "\n";" in lib/utils.c to be used by 2nd patch */ patch 2: commit e8bd395508cead5a81c2bebd9d3705a9e41ea8bc Author: Keara Leibovitz Date: Thu Jul 26 09:45:30 2018 -0400 tc: fix bugs for tcp_flags and ip_attr hex output Fix hex output for both the ip_attr and tcp_flags print functions. With the above 2 patches pull in, the new "tc" utility will show the correct tcp_flags mask: # tc filter show dev p0v2 root filter protocol ip pref 5 flower chain 1 filter protocol ip pref 5 flower chain 1 handle 0x1 src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff eth_type ipv4 ip_proto tcp tcp_flags 0x2/7 /* <--- Correct */ skip_sw in_hw action order 1: mirred (Egress Redirect to device p0v0_r) stolen This bug affects tc in Ubuntu 18.04.1 stock image. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1873961/+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 1873961] Re: tc filter show tcp_flags wrong mask value
** Changed in: ubuntu-power-systems Status: New => Triaged -- 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/1873961 Title: tc filter show tcp_flags wrong mask value Status in The Ubuntu-power-systems project: Triaged Status in iproute2 package in Ubuntu: Fix Released Status in iproute2 source package in Bionic: Triaged Bug description: ---Problem Description--- Problem Descriptions "tc" utility does not show correct TC rule's tcp_flags mask correctly in current "iproute2" package shipped on Genesis. # dpkg -l |grep iproute2 ii iproute2 4.15.0-2ubuntu1 ppc64el networking and traffic control tools ---Steps to Reproduce--- Steps to reproduce the problem: 1) Add a tc rule to the testing VF (i.e. p0v2_r): # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1 flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 2 skip_sw action mirred egress redirect dev p0v0_r 2) Validate the added TC rule: # tc filter show dev p0v2_r root filter protocol ip pref 5 flower chain 1 filter protocol ip pref 5 flower chain 1 handle 0x1 src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff eth_type ipv4 ip_proto tcp tcp_flags 22 /* <--- Wrong */ skip_sw in_hw action order 1: mirred (Egress Redirect to device p0v0_r) stolen 3) If we add the tcp_flags using explicit mask 0x7: # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1 flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 0x2/7 skip_sw action mirred egress redirect dev p0v0_r After that, using "tc filter show dev p0v2_r root" to verify, we still see the same output (tcp_flags 22) as shown in 2) above, which is wrong. Userspace tool common name: tc The userspace tool has the following bit modes: 64-bit Userspace package: iproute2 == Fixes: There are 2 patches to fix the issue: patch 1: commit b85076cd74e77538918d35992b1a9cd17ff86af8 Author: Stephen Hemminger Date: Tue Sep 11 08:29:33 2018 -0700 lib: introduce print_nl Common pattern in iproute commands is to print a line seperator in non-json mode. Make that a simple function. /* This patch declares global variable "const char *_SL_ = "\n";" in lib/utils.c to be used by 2nd patch */ patch 2: commit e8bd395508cead5a81c2bebd9d3705a9e41ea8bc Author: Keara Leibovitz Date: Thu Jul 26 09:45:30 2018 -0400 tc: fix bugs for tcp_flags and ip_attr hex output Fix hex output for both the ip_attr and tcp_flags print functions. With the above 2 patches pull in, the new "tc" utility will show the correct tcp_flags mask: # tc filter show dev p0v2 root filter protocol ip pref 5 flower chain 1 filter protocol ip pref 5 flower chain 1 handle 0x1 src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff eth_type ipv4 ip_proto tcp tcp_flags 0x2/7 /* <--- Correct */ skip_sw in_hw action order 1: mirred (Egress Redirect to device p0v0_r) stolen This bug affects tc in Ubuntu 18.04.1 stock image. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1873961/+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 1837443] Re: [Power9][Witherspoon dd2.3] unable to set hwclock
** No longer affects: util-linux (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1837443 Title: [Power9][Witherspoon dd2.3] unable to set hwclock Status in The Ubuntu-power-systems project: Fix Released Bug description: On the upgraded witherspoon Power9 system we are unable to set hwclock. ubuntu@bobone:~$ uname -a Linux bobone 5.0.0-20-generic #21-Ubuntu SMP Mon Jun 24 09:31:42 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux ubuntu@bobone:~$ cat /etc/issue Ubuntu 19.04 \n \l ubuntu@bobone:~$ date Mon Jul 22 18:25:04 UTC 2019 ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 5s; sudo /sbin/hwclock 2019-07-22 18:25:26.799805+00:00 ubuntu@bobone:~$ ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 5s; sudo /sbin/hwclock --verbose hwclock from util-linux 2.33.1 System Time: 1563820048.938797 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 1101096600 seconds after 1969 Last calibration done at 1101096600 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ioctl(4, RTC_UIE_ON, 0): Invalid argument Waiting in loop for time from /dev/rtc0 to change ...got clock tick Time read from Hardware Clock: 2019/07/22 18:27:29 Hw clock time : 2019/07/22 18:27:29 = 1563820049 seconds since 1969 Time since last adjustment is 462723449 seconds Calculated Hardware Clock drift is 0.00 seconds 2019-07-22 18:27:28.877732+00:00 ubuntu@bobone:~$ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1837443/+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 1842436] Re: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) ** Changed in: ubuntu-z-systems Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1842436 Title: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups Status in Ubuntu on IBM z Systems: New Status in lvm2 package in Ubuntu: New Bug description: efault blocksize of a file-system seems to be dependent on the volume-size. Big volume (at least ext4) does have 4k blk-size, even the underlaying devise with a smaller phyiscal blk-size. The patch, avoiding define mixed-sized volume groups is now upstream in the master branch of LVM2 https://sourceware.org/git/?p=lvm2.git;a=commit;h=0404539edb25e4a9d3456bb3e6b402aa2767af6b Using this patch within the distribution is for sanity reasons. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1842436/+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 1842284] Re: initramfs does not copy ehci-platform
** Changed in: initramfs-tools (Ubuntu) Status: Invalid => Confirmed ** Changed in: initramfs-tools (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/1842284 Title: initramfs does not copy ehci-platform Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: New Bug description: [Impact] If you install Ubuntu onto USB storage behind a Platform USB host controller, it will not be able to boot because the generated initramfs will not include the host controller driver. [Test Case] Install to a USB stick attached to platform USB controller and reboot. Booting will fail because it will be unable to find the root file system. [Regression Risk] Driver is only loaded when system requires ehci-platform, minimizing the impact to all other systems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1842284/+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 1837443] Re: [Power9][Witherspoon dd2.3] unable to set hwclock
Thanks to Dimitri for pointing out that the comment #2 is not designed to actually SET the HW Clock from the host, but to ALLOW the HW Clock to be set with /sbin/hwclock. I had completely missed this. Next step is to try the sequence described in comment #2 (on the BMC and also on the host), and then retry using /sbin/hwclock on the host to change the HW clock time. ** Changed in: ubuntu-power-systems Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1837443 Title: [Power9][Witherspoon dd2.3] unable to set hwclock Status in The Ubuntu-power-systems project: In Progress Status in util-linux package in Ubuntu: New Bug description: On the upgraded witherspoon Power9 system we are unable to set hwclock. ubuntu@bobone:~$ uname -a Linux bobone 5.0.0-20-generic #21-Ubuntu SMP Mon Jun 24 09:31:42 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux ubuntu@bobone:~$ cat /etc/issue Ubuntu 19.04 \n \l ubuntu@bobone:~$ date Mon Jul 22 18:25:04 UTC 2019 ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 5s; sudo /sbin/hwclock 2019-07-22 18:25:26.799805+00:00 ubuntu@bobone:~$ ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 5s; sudo /sbin/hwclock --verbose hwclock from util-linux 2.33.1 System Time: 1563820048.938797 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 1101096600 seconds after 1969 Last calibration done at 1101096600 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ioctl(4, RTC_UIE_ON, 0): Invalid argument Waiting in loop for time from /dev/rtc0 to change ...got clock tick Time read from Hardware Clock: 2019/07/22 18:27:29 Hw clock time : 2019/07/22 18:27:29 = 1563820049 seconds since 1969 Time since last adjustment is 462723449 seconds Calculated Hardware Clock drift is 0.00 seconds 2019-07-22 18:27:28.877732+00:00 ubuntu@bobone:~$ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1837443/+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 1742941] Re: zlib: improve crc32 performance on P8
** Changed in: ubuntu-power-systems Assignee: Canonical Foundations Team (canonical-foundations) => (unassigned) ** Changed in: zlib (Ubuntu) Assignee: Canonical Foundations Team (canonical-foundations) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1742941 Title: zlib: improve crc32 performance on P8 Status in The Ubuntu-power-systems project: Incomplete Status in zlib package in Ubuntu: Incomplete Bug description: Calculate the checksum of data that is 16 byte aligned and a multiple of 16 bytes. The first step is to reduce it to 1024 bits. We do this in 8 parallel chunks in order to mask the latency of the vpmsum instructions. If we have more than 32 kB of data to checksum we repeat this step multiple times, passing in the previous 1024 bits. The next step is to reduce the 1024 bits to 64 bits. This step adds 32 bits of 0s to the end - this matches what a CRC does. We just calculate constants that land the data in this 32 bits. We then use fixed point Barrett reduction to compute a mod n over GF(2) for n = CRC using POWER8 instructions. We use x = 32. http://en.wikipedia.org/wiki/Barrett_reduction To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1742941/+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 1841052] Re: [19.10 FEAT] gzip compression improvements - addl. patch required
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1841052 Title: [19.10 FEAT] gzip compression improvements - addl. patch required Status in Ubuntu on IBM z Systems: Fix Released Status in gzip package in Ubuntu: Fix Released Bug description: Due to fact that LP: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1825350 is alread fix released , this new ticket is opened to fix a configuration problem: dpkg-buildpackage: info: source package gzip dpkg-buildpackage: info: source version 1.10-0ubuntu2 ... configure: WARNING: unrecognized options: --enable-dfltc The configure flag: should be --enable-dfltcc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1841052/+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 1823157] Re: [19.10 FEAT] zlib compression improvements
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1823157 Title: [19.10 FEAT] zlib compression improvements Status in Ubuntu on IBM z Systems: Fix Released Status in zlib package in Ubuntu: Fix Released Bug description: Compression improvements for Linux on z using zlib in support of better performance. Upstream post 2019-03-15: https://github.com/madler/zlib/pull/410 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1823157/+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 1742941] Re: [18.10] zlib: improve crc32 performance on P8
danie...@au1.ibm.com: has there been any outcome from the upstream talks with Mark Adler? ** Summary changed: - [18.10] zlib: improve crc32 performance on P8 + zlib: improve crc32 performance on P8 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1742941 Title: zlib: improve crc32 performance on P8 Status in The Ubuntu-power-systems project: Incomplete Status in zlib package in Ubuntu: Incomplete Bug description: Calculate the checksum of data that is 16 byte aligned and a multiple of 16 bytes. The first step is to reduce it to 1024 bits. We do this in 8 parallel chunks in order to mask the latency of the vpmsum instructions. If we have more than 32 kB of data to checksum we repeat this step multiple times, passing in the previous 1024 bits. The next step is to reduce the 1024 bits to 64 bits. This step adds 32 bits of 0s to the end - this matches what a CRC does. We just calculate constants that land the data in this 32 bits. We then use fixed point Barrett reduction to compute a mod n over GF(2) for n = CRC using POWER8 instructions. We use x = 32. http://en.wikipedia.org/wiki/Barrett_reduction To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1742941/+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 1742941] Re: zlib: improve crc32 performance on P8
Also, removing "18.10" from the title, as this release has EOLed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1742941 Title: zlib: improve crc32 performance on P8 Status in The Ubuntu-power-systems project: Incomplete Status in zlib package in Ubuntu: Incomplete Bug description: Calculate the checksum of data that is 16 byte aligned and a multiple of 16 bytes. The first step is to reduce it to 1024 bits. We do this in 8 parallel chunks in order to mask the latency of the vpmsum instructions. If we have more than 32 kB of data to checksum we repeat this step multiple times, passing in the previous 1024 bits. The next step is to reduce the 1024 bits to 64 bits. This step adds 32 bits of 0s to the end - this matches what a CRC does. We just calculate constants that land the data in this 32 bits. We then use fixed point Barrett reduction to compute a mod n over GF(2) for n = CRC using POWER8 instructions. We use x = 32. http://en.wikipedia.org/wiki/Barrett_reduction To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1742941/+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 1837443] Re: [Power9][Witherspoon dd2.3] unable to set hwclock
I believe /sbin/hwclock is the default tool for manually setting the hwclock in Linux. I’m nervous that higher level workloads may depend on the correct functioning of the /sbin/hwclock tool for their successful operation. The /sbin/hwclock tool is shipped with the util-linux package. Adding util-linux as impacted and assigning to Foundations team to comment on whether the /sbin/hwclock tool not operating on witherspoon is a serious issue or not. ** Also affects: util-linux (Ubuntu) Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Assignee: bugproxy (bugproxy) => Canonical Foundations Team (canonical-foundations) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1837443 Title: [Power9][Witherspoon dd2.3] unable to set hwclock Status in The Ubuntu-power-systems project: Triaged Status in util-linux package in Ubuntu: New Bug description: On the upgraded witherspoon Power9 system we are unable to set hwclock. ubuntu@bobone:~$ uname -a Linux bobone 5.0.0-20-generic #21-Ubuntu SMP Mon Jun 24 09:31:42 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux ubuntu@bobone:~$ cat /etc/issue Ubuntu 19.04 \n \l ubuntu@bobone:~$ date Mon Jul 22 18:25:04 UTC 2019 ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 5s; sudo /sbin/hwclock 2019-07-22 18:25:26.799805+00:00 ubuntu@bobone:~$ ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 5s; sudo /sbin/hwclock --verbose hwclock from util-linux 2.33.1 System Time: 1563820048.938797 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 1101096600 seconds after 1969 Last calibration done at 1101096600 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ioctl(4, RTC_UIE_ON, 0): Invalid argument Waiting in loop for time from /dev/rtc0 to change ...got clock tick Time read from Hardware Clock: 2019/07/22 18:27:29 Hw clock time : 2019/07/22 18:27:29 = 1563820049 seconds since 1969 Time since last adjustment is 462723449 seconds Calculated Hardware Clock drift is 0.00 seconds 2019-07-22 18:27:28.877732+00:00 ubuntu@bobone:~$ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1837443/+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
** Changed in: ubuntu-power-systems Status: Fix Committed => Fix Released -- 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 Released 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 Released 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 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: c000
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
Following call with IBM, verification testing is in progress. Hoping to have test results posted in the next 24 hours (approx). -- 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 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 [
[Touch-packages] [Bug 1830796] Re: [Bionic][ARM64]Failure debugging linux kernel
Next step is for this patch to go into the bionic gdb SRU queue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1830796 Title: [Bionic][ARM64]Failure debugging linux kernel Status in gdb package in Ubuntu: Fix Released Status in gdb source package in Bionic: In Progress Bug description: [Impact] GDB fails to debug ARM64 vmlinux debug image with proc/kcore information. For example it is unable to print values of variables like 'jiffies_64'. [Test] # gdb /usr/lib/debug/boot/vmlinux-4.18.0-20-generic /proc/kcore [New process 1] Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic root=UUID=edb5e5a7-8272-4e13-aa25-37'. #0 0x in ?? () (gdb) p jiffies_64 Cannot access memory at address 0x09616980 (gdb) [Fix] This issue was fixed upstream (git://sourceware.org/git/binutils-gdb.git) by the following patch: 8727de56b0 Fix tagged pointer support [Regression Potential] The risk of regression after applying this patch could be to architectures other than ARM64 due to changes to gdb/util.c. Please see comment #2 where I have tested the PPA package on a ppc64el system and found it does not introduce any regressions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1830796/+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
Thanks for the verification in comment #67. From the comment, I believe this was verified with bionic. Could you also verify with Cosmic and post your results? Thanks. -- 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 Committed 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 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
[Touch-packages] [Bug 1657646] Re: [20.04]Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation
Note that this is likely to require an MIR (https://wiki.ubuntu.com/MainInclusionProcess) for thin-provisioning- tools for 20.04. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1657646 Title: [20.04]Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation Status in The Ubuntu-power-systems project: Triaged Status in lvm2 package in Ubuntu: Confirmed Status in lvm2 package in Debian: New Bug description: Creating a thin pool LV is allowed even when thin-provisioning-tools is not installed. But deactivating or activating that VG fails. Since deactivating the VG usually only happens at reboot, the user might fail to notice this big problem until then. I think the lvconvert tool, used to combine the two "thin LVs" into a thin pool LV, should refuse to run if thin-provisioning-tools, or the needed scripts, aren't installed. Steps to reproduce: root@15-89:~# vgcreate vg /dev/vdb1 Volume group "vg" successfully created root@15-89:~# vgs VG #PV #LV #SN Attr VSize VFree vg 1 0 0 wz--n- 40.00g 40.00g root@15-89:~# lvcreate -n pool0 -l 90%VG vg Logical volume "pool0" created. root@15-89:~# lvcreate -n pool0meta -l 5%VG vg Logical volume "pool0meta" created. root@15-89:~# lvs LVVG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert pool0 vg -wi-a- 36.00g pool0meta vg -wi-a- 2.00g root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 100 Jun 21 14:15 ./ drwxr-xr-x 20 root root3820 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:14 vg-pool0 -> ../dm-0 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0meta -> ../dm-1 root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0 WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data and metadata volumes. THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.) Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y Converted vg/pool0 to thin pool. root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 120 Jun 21 14:15 ./ drwxr-xr-x 20 root root3840 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0 root@15-89:~# lvs -a LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%S ync Convert [lvol0_pmspare] vg ewi--- 2.00g pool0 vg twi-a-tz-- 36.00g 0.00 0.01 [pool0_tdata] vg Twi-ao 36.00g [pool0_tmeta] vg ewi-ao 2.00g If you now reboot the system, all that is gone: root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:28 ./ drwxr-xr-x 19 root root3760 Jun 21 14:28 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control The same happens if you deactivate the VG (which the reboot undoubtedly triggers). It fails because of a missing /usr/sbin/thin_check which is provided by the thin-provisioning-tools package: root@15-89:~# vgchange -a n /usr/sbin/thin_check: execvp failed: No such file or directory WARNING: Integrity check of metadata for pool vg/pool0 failed. 0 logical volume(s) in volume group "vg" now active root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:29 ./ drwxr-xr-x 19 root root3760 Jun 21 14:29 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1657646/+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 1657646] Re: Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation
We will investigate and update this bug shortly. I notice that this issue was raised some time ago. Is there any additional information you can share as to recent specific use cases or scenarios? Thanks. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1657646 Title: Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation Status in The Ubuntu-power-systems project: Triaged Status in lvm2 package in Ubuntu: Confirmed Status in lvm2 package in Debian: New Bug description: Creating a thin pool LV is allowed even when thin-provisioning-tools is not installed. But deactivating or activating that VG fails. Since deactivating the VG usually only happens at reboot, the user might fail to notice this big problem until then. I think the lvconvert tool, used to combine the two "thin LVs" into a thin pool LV, should refuse to run if thin-provisioning-tools, or the needed scripts, aren't installed. Steps to reproduce: root@15-89:~# vgcreate vg /dev/vdb1 Volume group "vg" successfully created root@15-89:~# vgs VG #PV #LV #SN Attr VSize VFree vg 1 0 0 wz--n- 40.00g 40.00g root@15-89:~# lvcreate -n pool0 -l 90%VG vg Logical volume "pool0" created. root@15-89:~# lvcreate -n pool0meta -l 5%VG vg Logical volume "pool0meta" created. root@15-89:~# lvs LVVG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert pool0 vg -wi-a- 36.00g pool0meta vg -wi-a- 2.00g root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 100 Jun 21 14:15 ./ drwxr-xr-x 20 root root3820 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:14 vg-pool0 -> ../dm-0 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0meta -> ../dm-1 root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0 WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data and metadata volumes. THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.) Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y Converted vg/pool0 to thin pool. root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 120 Jun 21 14:15 ./ drwxr-xr-x 20 root root3840 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0 root@15-89:~# lvs -a LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%S ync Convert [lvol0_pmspare] vg ewi--- 2.00g pool0 vg twi-a-tz-- 36.00g 0.00 0.01 [pool0_tdata] vg Twi-ao 36.00g [pool0_tmeta] vg ewi-ao 2.00g If you now reboot the system, all that is gone: root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:28 ./ drwxr-xr-x 19 root root3760 Jun 21 14:28 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control The same happens if you deactivate the VG (which the reboot undoubtedly triggers). It fails because of a missing /usr/sbin/thin_check which is provided by the thin-provisioning-tools package: root@15-89:~# vgchange -a n /usr/sbin/thin_check: execvp failed: No such file or directory WARNING: Integrity check of metadata for pool vg/pool0 failed. 0 logical volume(s) in volume group "vg" now active root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:29 ./ drwxr-xr-x 19 root root3760 Jun 21 14:29 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1657646/+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 1657646] Re: Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) ** Changed in: ubuntu-power-systems Importance: Undecided => High ** Changed in: ubuntu-power-systems Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1657646 Title: Missing thin-provisioning-tools prevents VG with thin pool LV from being (de)activated, but not its creation Status in The Ubuntu-power-systems project: Triaged Status in lvm2 package in Ubuntu: Confirmed Status in lvm2 package in Debian: New Bug description: Creating a thin pool LV is allowed even when thin-provisioning-tools is not installed. But deactivating or activating that VG fails. Since deactivating the VG usually only happens at reboot, the user might fail to notice this big problem until then. I think the lvconvert tool, used to combine the two "thin LVs" into a thin pool LV, should refuse to run if thin-provisioning-tools, or the needed scripts, aren't installed. Steps to reproduce: root@15-89:~# vgcreate vg /dev/vdb1 Volume group "vg" successfully created root@15-89:~# vgs VG #PV #LV #SN Attr VSize VFree vg 1 0 0 wz--n- 40.00g 40.00g root@15-89:~# lvcreate -n pool0 -l 90%VG vg Logical volume "pool0" created. root@15-89:~# lvcreate -n pool0meta -l 5%VG vg Logical volume "pool0meta" created. root@15-89:~# lvs LVVG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert pool0 vg -wi-a- 36.00g pool0meta vg -wi-a- 2.00g root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 100 Jun 21 14:15 ./ drwxr-xr-x 20 root root3820 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:14 vg-pool0 -> ../dm-0 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0meta -> ../dm-1 root@15-89:~# lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0 WARNING: Converting logical volume vg/pool0 and vg/pool0meta to pool's data and metadata volumes. THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.) Do you really want to convert vg/pool0 and vg/pool0meta? [y/n]: y Converted vg/pool0 to thin pool. root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 120 Jun 21 14:15 ./ drwxr-xr-x 20 root root3840 Jun 21 14:15 ../ crw--- 1 root root 10, 236 Jun 21 13:15 control lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tdata -> ../dm-1 lrwxrwxrwx 1 root root 7 Jun 21 14:15 vg-pool0_tmeta -> ../dm-0 root@15-89:~# lvs -a LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%S ync Convert [lvol0_pmspare] vg ewi--- 2.00g pool0 vg twi-a-tz-- 36.00g 0.00 0.01 [pool0_tdata] vg Twi-ao 36.00g [pool0_tmeta] vg ewi-ao 2.00g If you now reboot the system, all that is gone: root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:28 ./ drwxr-xr-x 19 root root3760 Jun 21 14:28 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control The same happens if you deactivate the VG (which the reboot undoubtedly triggers). It fails because of a missing /usr/sbin/thin_check which is provided by the thin-provisioning-tools package: root@15-89:~# vgchange -a n /usr/sbin/thin_check: execvp failed: No such file or directory WARNING: Integrity check of metadata for pool vg/pool0 failed. 0 logical volume(s) in volume group "vg" now active root@15-89:~# ll /dev/mapper/ total 0 drwxr-xr-x 2 root root 60 Jun 21 14:29 ./ drwxr-xr-x 19 root root3760 Jun 21 14:29 ../ crw--- 1 root root 10, 236 Jun 21 14:28 control To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1657646/+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 1742941] Re: [18.10] zlib: improve crc32 performance on P8
** Changed in: zlib (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1742941 Title: [18.10] zlib: improve crc32 performance on P8 Status in The Ubuntu-power-systems project: Incomplete Status in zlib package in Ubuntu: Incomplete Bug description: Calculate the checksum of data that is 16 byte aligned and a multiple of 16 bytes. The first step is to reduce it to 1024 bits. We do this in 8 parallel chunks in order to mask the latency of the vpmsum instructions. If we have more than 32 kB of data to checksum we repeat this step multiple times, passing in the previous 1024 bits. The next step is to reduce the 1024 bits to 64 bits. This step adds 32 bits of 0s to the end - this matches what a CRC does. We just calculate constants that land the data in this 32 bits. We then use fixed point Barrett reduction to compute a mod n over GF(2) for n = CRC using POWER8 instructions. We use x = 32. http://en.wikipedia.org/wiki/Barrett_reduction To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1742941/+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
Added to the SRU queue on 22nd April. Thanks! -- 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. 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 [
[Touch-packages] [Bug 1818953] Re: mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by executing perl script, multiple architectures
Great. Thanks Dimitri. We'd missed that upload. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to perl in Ubuntu. https://bugs.launchpad.net/bugs/1818953 Title: mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by executing perl script, multiple architectures Status in The Ubuntu-power-systems project: Confirmed Status in perl package in Ubuntu: Confirmed Status in perl source package in Disco: Confirmed Status in perl package in Debian: Unknown Bug description: == Comment: #0 - NAGENDRA P. DONTAMSETTY - 2019-02-28 00:14:49 == ---Problem Description--- Perl core dumping core on UBUNTU 19.04 by executing perl script ---uname output--- root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux Machine Type = ppc64le and power8 ---Debugger Data--- root@p8ct1p13:/tmp# file core core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 (SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8' ---Steps to Reproduce--- Description: Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc" root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux root@p8ct1p13:~# cat /etc/os-release NAME="Ubuntu" VERSION="19.04 (Disco Dingo)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu Disco Dingo (development branch)" VERSION_ID="19.04" HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; VERSION_CODENAME=disco UBUNTU_CODENAME=disco root@p8ct1p13:~# ctversion -bv RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 RSCT_Build_Context=ppc64le_linux_2 root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test String 2" perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed. Aborted (core dumped) root@p8ct1p13:/tmp# file core core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 (SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8' root@p8ct1p13:/tmp# which mkrsrc /usr/bin/mkrsrc root@p8ct1p13:/tmp# file /usr/bin/mkrsrc /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc /opt/rsct/bin/mkrsrc: Perl script text executable Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, Anirban/anirb...@in.ibm.com Userspace tool common name: perl 5 The userspace tool has the following bit modes: 64bit Userspace rpm: ii perl 5.28.1-4 ppc64el Userspace tool obtained from project website: na *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, Anirban/anirb...@in.ibm.com: -Post a private note with access information to the machine that is currently in the debugger. -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1818953/+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 Thadeu, thanks for the update. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/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: 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
[Touch-packages] [Bug 1764628] Re: incorrect hypervisor and virtualization type reported in compat mode guest
** Changed in: ubuntu-power-systems Status: Triaged => Incomplete ** Changed in: util-linux (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1764628 Title: incorrect hypervisor and virtualization type reported in compat mode guest Status in The Ubuntu-power-systems project: Incomplete Status in util-linux package in Ubuntu: Incomplete Bug description: ---uname output--- Linux guest 4.15.0-13-generic #14~16.04.1-Ubuntu SMP Sat Mar 17 03:03:53 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux Machine Type = boston-LC ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Incorrect hypervisor and virtualization type reported in ubuntu 16.04.04 guest running in P8compat mode on P9 boston-LC: root@guest:/tmp# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):2 On-line CPU(s) list: 0,1 Thread(s) per core:2 Core(s) per socket:1 Socket(s): 1 NUMA node(s): 1 Model: 2.2 (pvr 004e 1202) Model name:POWER8 (architected), altivec supported >> Hypervisor vendor: horizontal >> Virtualization type: full L1d cache: 32K L1i cache: 32K NUMA node0 CPU(s): 0,1 Stack trace output: no Oops output: no We test what is coming along with distro. If you are not able to see issue with : https://launchpad.net/ubuntu/+source/util-linux/2.27.1-6ubuntu3.5 .. can we get this included in 16.04.x train ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1764628/+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
Next step: Thadeu to propose the diff described in comment #53 into the archive. (If this incorrect, please flag.) -- 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: 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 [
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
** Changed in: ubuntu-power-systems Status: Won't Fix => 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: 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: [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: c000
[Touch-packages] [Bug 1733870] Re: [Ubuntu 19.10] Add GDB support to access/display POWER8 registers
Based comments #6, #7 and #8, closing this bug out. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1733870 Title: [Ubuntu 19.10] Add GDB support to access/display POWER8 registers Status in The Ubuntu-power-systems project: Fix Released Status in gdb package in Ubuntu: Fix Released Bug description: This feature request is for GDB support for access to Power registers that are currently not accessible: PPR, DSCR, TAR, EBB, PMU and HTM registers. The feature is currently being worked on, so no upstream code is available yet. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1733870/+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 1818953] Re: Perl core dumping core on UBUNTU 19.04 by executing perl script
** Changed in: ubuntu-power-systems Importance: Undecided => Critical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to perl in Ubuntu. https://bugs.launchpad.net/bugs/1818953 Title: Perl core dumping core on UBUNTU 19.04 by executing perl script Status in The Ubuntu-power-systems project: Incomplete Status in perl package in Ubuntu: Incomplete Bug description: == Comment: #0 - NAGENDRA P. DONTAMSETTY - 2019-02-28 00:14:49 == ---Problem Description--- Perl core dumping core on UBUNTU 19.04 by executing perl script ---uname output--- root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux Machine Type = ppc64le and power8 ---Debugger Data--- root@p8ct1p13:/tmp# file core core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 (SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8' ---Steps to Reproduce--- Description: Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc" root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux root@p8ct1p13:~# cat /etc/os-release NAME="Ubuntu" VERSION="19.04 (Disco Dingo)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu Disco Dingo (development branch)" VERSION_ID="19.04" HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; VERSION_CODENAME=disco UBUNTU_CODENAME=disco root@p8ct1p13:~# ctversion -bv RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 RSCT_Build_Context=ppc64le_linux_2 root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test String 2" perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed. Aborted (core dumped) root@p8ct1p13:/tmp# file core core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 (SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8' root@p8ct1p13:/tmp# which mkrsrc /usr/bin/mkrsrc root@p8ct1p13:/tmp# file /usr/bin/mkrsrc /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc /opt/rsct/bin/mkrsrc: Perl script text executable Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, Anirban/anirb...@in.ibm.com Userspace tool common name: perl 5 The userspace tool has the following bit modes: 64bit Userspace rpm: ii perl 5.28.1-4 ppc64el Userspace tool obtained from project website: na *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, Anirban/anirb...@in.ibm.com: -Post a private note with access information to the machine that is currently in the debugger. -Attach ltrace and strace of userspace application. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1818953/+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
Thanks. Closing out the bug. ** Changed in: ubuntu-power-systems Status: In Progress => Won't Fix ** Changed in: initramfs-tools (Ubuntu) Status: Confirmed => Invalid ** Changed in: initramfs-tools (Ubuntu Bionic) Status: Confirmed => Invalid ** Changed in: initramfs-tools (Ubuntu Cosmic) Status: Confirmed => Invalid ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: linux (Ubuntu Bionic) Status: Confirmed => Invalid ** Changed in: linux (Ubuntu Cosmic) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/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: Invalid Status in linux package in Ubuntu: Invalid Status in makedumpfile package in Ubuntu: Invalid Status in initramfs-tools source package in Bionic: Invalid Status in linux source package in Bionic: Invalid Status in makedumpfile source package in Bionic: Invalid Status in initramfs-tools source package in Cosmic: Invalid Status in linux source package in Cosmic: Invalid 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: c07f
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
** Changed in: ubuntu-power-systems 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/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] GPR20: 0e4f79d8d5d8 00
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
** Changed in: ubuntu-power-systems Status: Incomplete => 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: 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 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 0
[Touch-packages] [Bug 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath
** Changed in: ubuntu-power-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1784347 Title: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath Status in The Ubuntu-power-systems project: Fix Released Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Bionic: Fix Released Bug description: [Impact] Any user of Ubuntu on multipath, where the default path separator has been changed to something else. This possibly affects other scenarios where the partition separator can be changed. [Test case] 1) Install Ubuntu on multipath system 2) Change /etc/multipath.conf to set "path_separator" to "" or "p". 3) Reboot 4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions where the path separator would be visible. [Regression potential] Minimal. This only affects display. Default separator on Ubuntu remains "-part". If the separator is not one of "", "p", or "-part", then "-part" would be used, as is already the case. == Comment: #0 - Chanh H. Nguyen - 2018-01-09 11:14:07 == We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the Emulex adapter to have the mpath disk. Running the fdisk -l and ls -l showing the conflict name for the mpath. :~# uname -a Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux root@boslcp4:~# cat /etc/os-release NAME="Ubuntu" VERSION="18.04 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu Bionic Beaver (development branch)" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part1 2048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 1258291199 419428352 200G 83 Linux :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:04 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha3 -> ../dm-3 == Comment: #2 - Chanh H. Nguyen - 2018-01-09 11:35:04 == I just modify the partitions and it is still showing the conflicting name on partitions. :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha3 -> ../dm-3 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha4 -> ../dm-4 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha5 -> ../dm-5 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha6 -> ../dm-6 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha7 -> ../dm-7 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha8 -> ../dm-8 :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part12048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 964691967 125829120 60G 83 Linux /dev/mapper/mpatha-part4 964691968 1258291199 293599232 140G 5 Extended /dev/mapper/mpatha-part5 964694016 1006637055 41943040 20G 83 Linux /dev/mapper/mpatha-part6 1006639104 1048582143 41943040 20G 83 Linux /dev/mapper/mpatha-part7 1048584192 1090527231 41943040 20G 83 Linux /dev/mapper/mpatha-part8 1090529280 1132472319 41943040 20G 83 Linux == Comment: #5 - Kyle Mahlkuch - 2018-06-26 13:50:12 == I have created and submitted
[Touch-packages] [Bug 1778844] Re: nvme multipath does not report path relationships
** Changed in: ubuntu-power-systems Status: In Progress => Incomplete -- 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: Incomplete 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] GPR20: 0e4f79d8d5d8 00
[Touch-packages] [Bug 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath
Update: IBM is working on the bionic verification. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1784347 Title: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath Status in The Ubuntu-power-systems project: Fix Committed Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Bionic: Incomplete Bug description: [Impact] Any user of Ubuntu on multipath, where the default path separator has been changed to something else. This possibly affects other scenarios where the partition separator can be changed. [Test case] 1) Install Ubuntu on multipath system 2) Change /etc/multipath.conf to set "path_separator" to "" or "p". 3) Reboot 4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions where the path separator would be visible. [Regression potential] Minimal. This only affects display. Default separator on Ubuntu remains "-part". If the separator is not one of "", "p", or "-part", then "-part" would be used, as is already the case. == Comment: #0 - Chanh H. Nguyen - 2018-01-09 11:14:07 == We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the Emulex adapter to have the mpath disk. Running the fdisk -l and ls -l showing the conflict name for the mpath. :~# uname -a Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux root@boslcp4:~# cat /etc/os-release NAME="Ubuntu" VERSION="18.04 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu Bionic Beaver (development branch)" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part1 2048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 1258291199 419428352 200G 83 Linux :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:04 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha3 -> ../dm-3 == Comment: #2 - Chanh H. Nguyen - 2018-01-09 11:35:04 == I just modify the partitions and it is still showing the conflicting name on partitions. :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha3 -> ../dm-3 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha4 -> ../dm-4 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha5 -> ../dm-5 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha6 -> ../dm-6 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha7 -> ../dm-7 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha8 -> ../dm-8 :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part12048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 964691967 125829120 60G 83 Linux /dev/mapper/mpatha-part4 964691968 1258291199 293599232 140G 5 Extended /dev/mapper/mpatha-part5 964694016 1006637055 41943040 20G 83 Linux /dev/mapper/mpatha-part6 1006639104 1048582143 41943040 20G 83 Linux /dev/mapper/mpatha-part7 1048584192 1090527231 41943040 20G 83 Linux /dev/mapper/mpatha-part8 1090529280 1132472319 41943040 20G 83 Linux == Comment: #5 - Kyle Mahlkuch - 2018-06-26 13:50:12 == I have created and submitted a patch that should help with
[Touch-packages] [Bug 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath
** Changed in: ubuntu-power-systems Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1784347 Title: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath Status in The Ubuntu-power-systems project: Fix Committed Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Bionic: Incomplete Bug description: [Impact] Any user of Ubuntu on multipath, where the default path separator has been changed to something else. This possibly affects other scenarios where the partition separator can be changed. [Test case] 1) Install Ubuntu on multipath system 2) Change /etc/multipath.conf to set "path_separator" to "" or "p". 3) Reboot 4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions where the path separator would be visible. [Regression potential] Minimal. This only affects display. Default separator on Ubuntu remains "-part". If the separator is not one of "", "p", or "-part", then "-part" would be used, as is already the case. == Comment: #0 - Chanh H. Nguyen - 2018-01-09 11:14:07 == We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the Emulex adapter to have the mpath disk. Running the fdisk -l and ls -l showing the conflict name for the mpath. :~# uname -a Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux root@boslcp4:~# cat /etc/os-release NAME="Ubuntu" VERSION="18.04 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu Bionic Beaver (development branch)" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part1 2048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 1258291199 419428352 200G 83 Linux :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:04 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha3 -> ../dm-3 == Comment: #2 - Chanh H. Nguyen - 2018-01-09 11:35:04 == I just modify the partitions and it is still showing the conflicting name on partitions. :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha3 -> ../dm-3 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha4 -> ../dm-4 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha5 -> ../dm-5 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha6 -> ../dm-6 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha7 -> ../dm-7 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha8 -> ../dm-8 :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part12048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 964691967 125829120 60G 83 Linux /dev/mapper/mpatha-part4 964691968 1258291199 293599232 140G 5 Extended /dev/mapper/mpatha-part5 964694016 1006637055 41943040 20G 83 Linux /dev/mapper/mpatha-part6 1006639104 1048582143 41943040 20G 83 Linux /dev/mapper/mpatha-part7 1048584192 1090527231 41943040 20G 83 Linux /dev/mapper/mpatha-part8 1090529280 1132472319 41943040 20G 83 Linux == Comment: #5 - Kyle Mahlkuch - 2018-06-26 13:50:
[Touch-packages] [Bug 1776626] Re: [18.10 FEAT] Support 4k sectors for fast clear key dm-crypt - crypttab part
** Changed in: ubuntu-z-systems Status: Fix Released => In Progress -- 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/1776626 Title: [18.10 FEAT] Support 4k sectors for fast clear key dm-crypt - crypttab part Status in Ubuntu on IBM z Systems: In Progress Status in cryptsetup package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cryptsetup source package in Bionic: New Status in systemd source package in Bionic: Fix Committed Bug description: [Impact] * cryptsetup in bionic supports creating luks volumes with a non- standard sector-size option, and thus this option also needs to be used when activating the LUKS volumes. Add sector-size= option support to /etc/crypttab. [Test Case] * Create a plain LUKS volume with sector-size 4096 * Specify sector-size=4096 option in /etc/crypttab * reload systemd, start systemd-cryptsetup@.service for that volume * check the journal, to ensure that `sector-size` option was recognized and is active. (i.e. there is not error messages about unrecognized option `sector-size` from systemd-cryptsetup) [Regression Potential] * This is an optional argument, not used by default. Currently custom sector-size crypttab does not work correctly, and thus cannot regress. [Other Info] * Original bug report Support fast clear key dm-crypt with 4k support Extend /etc/crypttab to enable 4k sector support in plain mode The proposed enhancements are posted on github, see https://github.com/systemd/systemd/issues/8881 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1776626/+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 1784347] Re: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath
** Changed in: ubuntu-power-systems Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1784347 Title: ISST-LTE: KVM:UBUNTU1804: BostonLC: fdisk -l shows the conflicting partitions name for the mpath Status in The Ubuntu-power-systems project: Fix Committed Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Bionic: Fix Committed Bug description: [Impact] Any user of Ubuntu on multipath, where the default path separator has been changed to something else. This possibly affects other scenarios where the partition separator can be changed. [Test case] 1) Install Ubuntu on multipath system 2) Change /etc/multipath.conf to set "path_separator" to "" or "p". 3) Reboot 4) Run 'sudo fdisk -l /dev/mapper/mpathX', to display a device's partitions where the path separator would be visible. [Regression potential] Minimal. This only affects display. Default separator on Ubuntu remains "-part". If the separator is not one of "", "p", or "-part", then "-part" would be used, as is already the case. == Comment: #0 - Chanh H. Nguyen - 2018-01-09 11:14:07 == We have the Ubuntu1804 installed on our BostonLC system. Create a SAN via the Emulex adapter to have the mpath disk. Running the fdisk -l and ls -l showing the conflict name for the mpath. :~# uname -a Linux boslcp4 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:03:08 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux root@boslcp4:~# cat /etc/os-release NAME="Ubuntu" VERSION="18.04 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu Bionic Beaver (development branch)" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part1 2048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 1258291199 419428352 200G 83 Linux :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:04 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:03 /dev/mapper/mpatha3 -> ../dm-3 == Comment: #2 - Chanh H. Nguyen - 2018-01-09 11:35:04 == I just modify the partitions and it is still showing the conflicting name on partitions. :~# ls -l /dev/mapper/mpatha* lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha2 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha3 -> ../dm-3 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha4 -> ../dm-4 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha5 -> ../dm-5 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha6 -> ../dm-6 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha7 -> ../dm-7 lrwxrwxrwx 1 root root 7 Jan 9 04:33 /dev/mapper/mpatha8 -> ../dm-8 :~# fdisk -l /dev/mapper/mpatha Disk /dev/mapper/mpatha: 600 GiB, 644245094400 bytes, 1258291200 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0xa5be904b Device Boot StartEnd Sectors Size Id Type /dev/mapper/mpatha-part12048 419432447 419430400 200G 83 Linux /dev/mapper/mpatha-part2 419432448 838862847 419430400 200G 83 Linux /dev/mapper/mpatha-part3 838862848 964691967 125829120 60G 83 Linux /dev/mapper/mpatha-part4 964691968 1258291199 293599232 140G 5 Extended /dev/mapper/mpatha-part5 964694016 1006637055 41943040 20G 83 Linux /dev/mapper/mpatha-part6 1006639104 1048582143 41943040 20G 83 Linux /dev/mapper/mpatha-part7 1048584192 1090527231 41943040 20G 83 Linux /dev/mapper/mpatha-part8 1090529280 1132472319 41943040 20G 83 Linux == Comment: #5 - Kyle Mahlkuch - 2018-06-26 13:50:12 == I have created and submitted a
[Touch-packages] [Bug 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state
** Changed in: ubuntu-power-systems Status: Incomplete => Triaged -- 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 1793369] Re: Ubuntu18.10:ppc64:s390x - Sysrq trigger disabled when writing to /proc/sysrq-trigger
** Changed in: systemd (Ubuntu) Status: New => 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: Invalid Status in linux package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid 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 1781242] Re: as segfault with invalid -march= option
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- 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/1781242 Title: as segfault with invalid -march= option Status in Ubuntu on IBM z Systems: Fix Released Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Xenial: Fix Released Bug description: [Impact] * as segfaults, instead of exiting gracefully, when one specifies unsupported arch option (ie. one from future - cause xenial did not support z14) * this is bad, as detection fails around supported march options - as if binutils are completely broken, rather than just not supporting this or that CPU level of optimisations. [Test Case] Bad result: $ as -march=foo Segmentation fault Expected result: # as -march=foo Assembler messages: Error: invalid switch -march=foo Error: unrecognized option -march=foo [Regression Potential] * The result is still a failure condition, but with a proper exit code and standard error messages, rather than an unexplainable generic segfault. [Other Info] * Original bug report The GNU assembler segfaults with an invalid -march= option Contact Information = n/a ---uname output--- n/a Machine Type = n/a ---Debugger--- A debugger is not configured ---Steps to Reproduce--- $ as -march=foo Segmentation fault Expected result: # as -march=foo Assembler messages: Error: invalid switch -march=foo Error: unrecognized option -march=foo Userspace tool common name: as The userspace tool has the following bit modes: 64 Userspace rpm: binutils-2.26.1-1ubuntu1~16.04.6 Userspace tool obtained from project website: na *Additional Instructions for n/a: -Attach ltrace and strace of userspace application. The problem is not critical since usually 'as' is invoked through the gcc driver which itself errors out for wrong -march= options. It will only be a problem if somebody builds a more recent GCC from source and uses an -march= option for a machine not supported by the default binutils. Please consider integrating the attached patch into 16.04 binutils. The problem has been fixed in later binutils already. Ubuntu 18.04 does not appear to be affected. --> Package has to set corectly by Canonical To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1781242/+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 1786940] Re: Enable arm-linux-gnueabi target on ppc64el toolchain
** Changed in: ubuntu-power-systems Status: Triaged => Incomplete -- 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/1786940 Title: Enable arm-linux-gnueabi target on ppc64el toolchain Status in The Ubuntu-power-systems project: Incomplete Status in binutils package in Ubuntu: Fix Released Status in gcc-7-cross package in Ubuntu: New Status in gcc-8-cross package in Ubuntu: New Status in gcc-defaults package in Ubuntu: Incomplete Bug description: Dear Canonical. We would like to have arm-linux-gnueabi target on ppc64el cross toolchain. This would enable us to use a ppc64el host to do cross compilation for aarch64. I talked to Matthias Klose already, and he is aware of this request. Thank you, Breno To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1786940/+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 1776626] Re: [18.10 FEAT] Support 4k sectors for fast clear key dm-crypt - crypttab part
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- 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/1776626 Title: [18.10 FEAT] Support 4k sectors for fast clear key dm-crypt - crypttab part Status in Ubuntu on IBM z Systems: Fix Released Status in cryptsetup package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Bug description: Support fast clear key dm-crypt with 4k support Extend /etc/crypttab to enable 4k sector support in plain mode The proposed enhancements are posted on github, see https://github.com/systemd/systemd/issues/8881 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1776626/+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 1733870] Re: [Ubuntu 19.04] Add GDB support to access/display POWER8 registers
** Summary changed: - [Ubuntu 18.10] Add GDB support to access/display POWER8 registers + [Ubuntu 19.04] Add GDB support to access/display POWER8 registers -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1733870 Title: [Ubuntu 19.04] Add GDB support to access/display POWER8 registers Status in The Ubuntu-power-systems project: Incomplete Status in gdb package in Ubuntu: Incomplete Bug description: This feature request is for GDB support for access to Power registers that are currently not accessible: PPR, DSCR, TAR, EBB, PMU and HTM registers. The feature is currently being worked on, so no upstream code is available yet. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1733870/+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 1732865] Re: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies
** Changed in: ubuntu-power-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1732865 Title: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies Status in The Ubuntu-power-systems project: Fix Released Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: Fix Released Status in util-linux source package in Artful: Fix Released Bug description: [Impact] lscpu fails to list CPU max and min frequencies if some CPUs are guarded. [Regression potential] Isolated change to lscpu min/max CPU frequency output, so the worst that could happen is that it fails to work elsewhere. [Test case] 1. Clone https://github.com/open-power/op-test-framework 2. Run this command to GUARD the cpu. ./op-test --bmc-type FSP --bmc-ip $FSPIP --bmc-username dev --bmc-password FipSdev --host-ip $HOSTIP --host-user root --host-password passw0rd --ffdcdir test-reports/ --run testcases.OpTestHMIHandling.MalfunctionAlert 3. Repeat again, so that multiple CPUs are guarded. 4. Run lscpu 5. Observe that no CPU frequencies are displayed: CPU max MHz: (null) CPU min MHz: (null) 6. Install util-linux from -proposed. 7. Run lscpu again 8. Observe that max and min CPU frequencies are correctly displayed. == Comment: #0 - Pridhiviraj Paidipeddi - 2017-01-03 05:34:32 == ---Problem Description--- After 3 CPU's are garded, lscpu failed to list CPU max and min frequencies Contact Information = ppaid...@in.ibm.com ---uname output--- Linux p8wookie 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux Machine Type = PowerNV 8284-22A ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Read lscpu output 2. Inject HMI Non recoverable error three times 3. Read lscpu output again compare the output cpu frequencies will list as NULL Stack trace output: no Oops output: no Userspace tool common name: lscpu Userspace rpm: util-linux The userspace tool has the following bit modes: 64-bit System Dump Info: The system is not configured to capture a system dump. Userspace tool obtained from project website: na *Additional Instructions for ppaid...@in.ibm.com: -Post a private note with access information to the machine that the bug is occuring on. -Attach sysctl -a output output to the bug. -Attach ltrace and strace of userspace application. Before CPU's are garded: root@p8wookie:~# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):112 On-line CPU(s) list: 0-71,80-103,112-127 Thread(s) per core:8 Core(s) per socket:3 Socket(s): 4 NUMA node(s): 4 Model: 2.1 (pvr 004b 0201) Model name:POWER8E (raw), altivec supported CPU max MHz: 4322. CPU min MHz: 2061. L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 0-31 NUMA node1 CPU(s): 32-63 NUMA node16 CPU(s):64-71,80-95 NUMA node17 CPU(s):96-103,112-127 After 4 cores are garded: root@p8wookie:~# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):96 On-line CPU(s) list: 8-55,64-71,80-103,112-127 Thread(s) per core:8 Core(s) per socket:3 Socket(s): 4 NUMA node(s): 4 Model: 2.1 (pvr 004b 0201) Model name:POWER8E (raw), altivec supported CPU max MHz: (null) CPU min MHz: (null) L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 8-31 NUMA node1 CPU(s): 32-55 NUMA node16 CPU(s):64-71,80-95 NUMA node17 CPU(s):96-103,112-127 == Comment: #1 - Pridhiviraj Paidipeddi - 2017-01-11 07:06:59 == root@p8wookie:~# dmesg |grep -i powernv [0.00] Using PowerNV machine description [0.331564] EEH: PowerNV platform initialized [0.907250] powernv-rng: Registering arch random hook. [1.504063] powernv-cpufreq: cpufreq pstate min -68 nominal -5 max 0 [1.507167] powernv_idle_driver registered [ 34.184048] powernv_rng: Registered powernv hwrng. [ 34.185619] ipmi-powernv ibm,opal:ipmi: Unable to map irq from device tree [ 34.210966] ipmi-powernv ibm,opal:ipmi: Found new BMC (man_id: 0x00, prod_id: 0x, dev_id: 0x00) root@p8wookie:~# cat /sys/firmware/opal/msglog | grep -i occ [ 42.297825315,7] OCC Common Area at 0x3b0 size 1MB [ 42.297854780,7] OCC Common Area at 0x200080 size 1MB [ 42.297884305,7] OCC
[Touch-packages] [Bug 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state
** Changed in: ubuntu-power-systems Status: Incomplete => Triaged -- 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 1778844] Re: ISST-LTE:PNV:Ubuntu180401:Witherspoon:woo: After triggering crash, kdump is not working and system enters into initramfs state
** Changed in: ubuntu-power-systems Status: Triaged => Incomplete -- 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: Incomplete 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 0
[Touch-packages] [Bug 1751813] Re: Ubuntu 18.04 installer does not detect any IPR based HDD/RAID array [S822L] [ipr]
** Changed in: ubuntu-power-systems Status: Fix Committed => Fix Released -- 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/1751813 Title: Ubuntu 18.04 installer does not detect any IPR based HDD/RAID array [S822L] [ipr] Status in The Ubuntu-power-systems project: Fix Released Status in debian-installer package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Bug description: ---Problem Description--- Ubuntu 18.04 ppc64el installer does detect IPR (IBM Power RAID) based HDD/RAID arrays Tried with current bionic and current bionic-proposed installers wget http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/vmlinux wget http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/initrd.gz kexec -l vmlinux -i initrd.gz kexec -e wget http://ports.ubuntu.com/ubuntu-ports/dists/bionic-proposed/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/vmlinux wget http://ports.ubuntu.com/ubuntu-ports/dists/bionic-proposed/main/installer-ppc64el/current/images/netboot/ubuntu-installer/ppc64el/initrd.gz kexec -l vmlinux -i initrd.gz kexec -e ---uname output--- uname -a Linux ltciofvtr-s822l2-lp1 4.13.0-32-generic #35-Ubuntu SMP Thu Jan 25 09:05:20 UTC 2018 ppc64le GNU/Linux Machine Type = 8247-22L (S822L) ---boot type--- Network boot ---bootloader--- petitboot shell ---Kernel cmdline used to launch install--- #cat /proc/cmdline ---Bootloader protocol--- http ---Install repository type--- Internet repository ---Install repository Location--- US ---Point of failure--- Problem during post-install (stage 2) configuration or other problem seen after reboot ===console error log=== ?? [!!] Partition disks ??? ? ? ? Note that all data on the disk you select will be erased, but not ? ? before you have confirmed that you really want to make the changes. ? ? ? ? Select disk to partition: ? ? ? ? SCSI1 (0,0,0) (sda) - 2.0 GB SMART USB-IBM ? ? SCSI2 (0,0,0) (sdb) - 1.0 TB IBM T RDX-USB3 ? ? ? ?? ? ? ??? moves; selects; activates buttons ~ # lsmod | grep -i ipr ipr 148677 0 ~ # modinfo ipr filename: /lib/modules/4.13.0-32-generic/kernel/drivers/scsi/ipr.ko version:2.6.4 license:GPL description:IBM Power RAID SCSI Adapter Driver author: Brian King srcversion: 05BB872A11F65B3A73AB352 alias: pci:v1014d04DAsv1014sd04FBbc*sc*i* alias: pci:v1014d04DAsv1014sd04FCbc*sc*i* alias: pci:v1014d034Asv1014sd04C9bc*sc*i* alias: pci:v1014d034Asv1014sd04C8bc*sc*i* alias: pci:v1014d034Asv1014sd04C7bc*sc*i* alias: pci:v1014d034Asv1014sd049Cbc*sc*i* alias: pci:v1014d034Asv1014sd049Bbc*sc*i* alias: pci:v1014d034Asv1014sd049Abc*sc*i* alias: pci:v1014d034Asv1014sd0499bc*sc*i* alias: pci:v1014d034Asv1014sd0475bc*sc*i* alias: pci:v1014d034Asv1014sd0474bc*sc*i* alias: pci:v1014d034Asv1014sd04CAbc*sc*i* alias: pci:v1014d034Asv1014sd046Dbc*sc*i* alias: pci:v1014d034Asv1014sd03FEbc*sc*i* alias: pci:v1014d034Asv1014sd03FFbc*sc*i* alias: pci:v1014d034Asv1014sd03FCbc*sc*i* alias: pci:v1014d034Asv1014sd03FBbc*sc*i* alias: pci:v1014d034Asv1014sd035Ebc*sc*i* alias: pci:v1014d034Asv1014sd035Dbc*sc*i* alias: pci:v1014d034Asv1014sd0357bc*sc*i* alias: pci:v1014d034Asv1014sd0355bc*sc*i* alias: pci:v1014d034Asv1014sd033Bbc*sc*i* alias: pci:v
[Touch-packages] [Bug 1719579] Re: [Ubuntu 18.04] [libvirt] virsh restore fails from state file saved in /var/tmp folder using virsh save
>From comment #22: "Distro team, Is there any update based on the previous update we posted. ?" I'm afraid this bug report is now a little complex and involved, and it is now marked as "Fix Released" in Launchpad. Could you please be specific about the comment or question that you require more information about? Alternatively, it may be best to raise a new bug report. -- 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/1719579 Title: [Ubuntu 18.04] [libvirt] virsh restore fails from state file saved in /var/tmp folder using virsh save Status in The Ubuntu-power-systems project: Fix Released Status in apparmor package in Ubuntu: Invalid Status in libvirt package in Ubuntu: Fix Released Bug description: == Comment: #1 - SEETEENA THOUFEEK - 2017-01-17 00:09:16 == Bala, Please mail me the machine information. == Comment: #3 - SEETEENA THOUFEEK - 2017-01-17 02:14:06 == 2017-01-16 12:09:37.707+: 7024: info : virSecurityDACRestoreFileLabelInternal:388 : Restoring DAC user and group on '/var/tmp/bala' 2017-01-16 12:09:37.707+: 7024: info : virSecurityDACSetOwnershipInternal:290 : Setting DAC user and group on '/var/tmp/bala' to '0:0' 2017-01-16 12:09:37.707+: 7024: warning : qemuDomainSaveImageStartVM:6750 : failed to restore save state label on /var/tmp/bala 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff4ca62b00 2017-01-16 12:09:37.707+: 7024: debug : qemuDomainObjEndAsyncJob:1848 : Stopping async job: start (vm=0x3fff4ca535c0 name=virt-tests-vm1-bala) 2017-01-16 12:09:37.707+: 7024: info : virObjectRef:296 : OBJECT_REF: obj=0x3fff4ca62b00 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff4ca62b00 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff4ca535c0 2017-01-16 12:09:37.707+: 7024: debug : virThreadJobClear:121 : Thread 7024 (virNetServerHandleJob) finished job remoteDispatchDomainRestore with ret=-1 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff7c002c10 2017-01-16 12:09:37.707+: 7024: debug : virNetServerProgramSendError:153 : prog=536903814 ver=1 proc=54 type=1 serial=4 msg=0x100133d2590 rerr=0x3fffa59be3c0 2017-01-16 12:09:37.707+: 7024: debug : virNetMessageEncodePayload:376 : Encode length as 172 2017-01-16 12:09:37.707+: 7024: debug : virNetServerClientSendMessageLocked:1399 : msg=0x100133d2590 proc=54 len=172 offset=0 2017-01-16 12:09:37.707+: 7024: info : virNetServerClientSendMessageLocked:1407 : RPC_SERVER_CLIENT_MSG_TX_QUEUE: client=0x100133d23c0 len=172 prog=536903814 vers=1 proc=54 type=1 status=1 serial=4 2017-01-16 12:09:37.707+: 7024: debug : virNetServerClientCalculateHandleMode:157 : tls=(nil) hs=-1, rx=0x100133d0670 tx=0x100133d2590 2017-01-16 12:09:37.707+: 7024: debug : virNetServerClientCalculateHandleMode:192 : mode=3 2017-01-16 12:09:37.707+: 7024: info : virEventPollUpdateHandle:152 : EVENT_POLL_UPDATE_HANDLE: watch=417 events=3 2017-01-16 12:09:37.707+: 7024: debug : virEventPollInterruptLocked:727 : Interrupting 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff7c002c10 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x100133caea0 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x100133d23c0 . 2017-01-16 12:14:28.445+: 7019: info : qemuMonitorJSONIOProcessLine:201 : QEMU_MONITOR_RECV_EVENT: mon=0x3fff94004d90 event={"timestamp": {"seconds": 1484568868, "microseconds": 444620}, "event": "MIGRATION", "data": {"status": "failed"}} 2017-01-16 12:14:28.445+: 7019: debug : qemuMonitorJSONIOProcessEvent:147 : mon=0x3fff94004d90 obj=0x100133b5670 2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToString:1762 : object=0x100133a8000 2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToStringOne:1691 : object=0x100133a8000 type=0 gen=0x100133d1160 2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToStringOne:1691 : object=0x100133d2a80 type=2 gen=0x100133d1160 2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToString:1795 : result={"status":"failed"} 2017-01-16 12:14:28.445+: 7019: debug : qemuMonitorEmitEvent:1218 : mon=0x3fff94004d90 event=MIGRATION 2017-01-16 12:14:28.445+: 7019: info : virObjectRef:296 : OBJECT_REF: obj=0x3fff94004d90 2017-01-16 12:14:28.445+: 7019: debug : qemuProcessHandleEvent:629 : vm=0x3fff4ca535c0 2017-01-16 12:14:28.445+: 7019: info : virObjectNew:202 : OBJECT_NEW: obj=0x100133d2870 classname=virDomainQemuMonitorEvent 2017-01-16 12:14:28.445+: 7019: debug : virObjectEventNew:645 : obj=0x100133d2870 2017-01-16 12:14:28.445+: 7019: info : virO
[Touch-packages] [Bug 1679704] Re: libvirt profile is blocking global setrlimit despite having no rlimit rule
** Changed in: ubuntu-power-systems Assignee: (unassigned) => Canonical Security Team (canonical-security) -- 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/1679704 Title: libvirt profile is blocking global setrlimit despite having no rlimit rule Status in The Ubuntu-power-systems project: In Progress Status in apparmor package in Ubuntu: In Progress Bug description: Hi, while debugging bug 1678322 I was running along apparmor issues. Thanks to jjohansen we debugged some of it and eventually I was asked to report to a bug. Symptom: [ 8976.950635] audit: type=1400 audit(1491310016.224:48): apparmor="DENIED" operation="setrlimit" profile="/usr/sbin/libvirtd" pid=10034 comm="libvirtd" rlimit=memlock value=1610612736 But none of the profiles has any rlimit statement in it: $ grep -Hirn limit /etc/apparmor* /etc/apparmor.d/sbin.dhclient:58: # such, if the dhclient3 daemon is subverted, this effectively limits it to /etc/apparmor.d/abstractions/ubuntu-helpers:16:# Limitations: /etc/apparmor.d/abstractions/ubuntu-helpers:64: # in limited libraries so glibc's secure execution should be enough to not /etc/apparmor.d/cache/.features:13:rlimit {mask {cpu fsize data stack core rss nproc nofile memlock as locks sigpending msgqueue nice rtprio rttime The profile contains a child profile which makes reading the dumps a bit painful, but I'll attach them anyway for you to take a look. To "recreate" if needed check out bug 1678322 - TL;DR hot-add some VFs via libvirt. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1679704/+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
** Changed in: ubuntu-power-systems Status: Fix Committed => Fix Released -- 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: Fix Released Status in makedumpfile package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in makedumpfile source package in Artful: Invalid Status in systemd source package in Artful: Fix Released 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 1708409] Re: kdump service does not start after configure/reboot
** Changed in: makedumpfile (Ubuntu Artful) Status: Confirmed => 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/1708409 Title: kdump service does not start after configure/reboot Status in The Ubuntu-power-systems project: Fix Committed Status in makedumpfile package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in makedumpfile source package in Artful: Invalid 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 1708409] Re: kdump service does not start after configure/reboot
** Tags removed: triage-a ** Tags added: triage-g -- 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: Fix Committed 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 1732032] Re: ip maddr show and ip maddr show dev enP20p96s0 show different data
** Changed in: ubuntu-power-systems Status: Fix Committed => Fix Released -- 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/1732032 Title: ip maddr show and ip maddr show dev enP20p96s0 show different data Status in The Ubuntu-power-systems project: Fix Released Status in iproute2 package in Ubuntu: Fix Released Status in iproute2 source package in Trusty: Fix Released Status in iproute2 source package in Xenial: Fix Released Status in iproute2 source package in Zesty: Won't Fix Status in iproute2 source package in Artful: Fix Released Bug description: [Impact] When a nic has a long enough name such that there is no space between the name and the ":" in /proc/net/igmp, ip maddr show dev will miss the IPV4 addresses which is otherwise shown with "ip maddr show". This is inconsistent behavior and can break scripts and tests, as shown in this bug's original description. Three patches from upstream were taken to fix this bug, and they were used individually instead of being merged into one single patch so it's easier to track and recognize authorship: https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=530903dd9003492edb0714e937ad4a5d1219e376 https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=b48a1161f5f9b6a0cda399a224bbbf72eba4a5c6 https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=21503ed2af233ffe795926f6641ac84ec1b15bf9 [Test Case] * deploy the ubuntu release under test. Please use bare metal or a VM instead of containers, because the ip tool parses a file in /proc. Make sure iproute2 is installed: sudo apt install iproute2 * Run these commands to setup a dummy interface with a long name and an IPv4 address. Please change the address if it conflicts with a real network you might have available on that machine: sudo ip link add dummylongnic0 type dummy sudo ip addr add 192.168.199.10/24 dev dummylongnic0 sudo ip link set dev dummylongnic0 up * Compare the output of these two commands with regards to the dummylongnic0 interface: sudo ip maddr show sudo ip maddr show dev dummylongnic0 * With the buggy iproute2 package installed, the more specific output "ip maddr show dev dummylongnic0" should lack the "inet 224.0.0.1" line: ip maddr show dev dummylongnic0 2:dummylongnic0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 inet6 ff02::1 inet6 ff01::1 Whereas the less specific command, which lists all interfaces, will have it listed for dummylongnic0: 2:dummylongnic0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 inet 224.0.0.1 inet6 ff02::1 inet6 ff01::1 * With the fixed iproute2 package, all dummylongnic0 addresses will be present in both outputs. [Regression Potential] In the end, the ip tool is parsing a text file produced by the kernel. As most parsing done in C, it's pretty low level and sensitive to changes in the file it's reading. [Other Info] I suggest to conduct the tests in VMs instead of containers (LXD) because the ip maddr command parses /proc/net/igmp, which is produced by the kernel. If you use a container, then it's the host's kernel that will be providing that file and it might not be the same as with the native kernel of that particular ubuntu release. --- Original description --- Attn. Canonical: Please make sure that the existing iproute2 package gets updated with the two referenced patches as the missing information is impacting our standard test suites. Thanks. == Comment: #0 - Alton L. Pundt - 2017-03-29 14:37:57 == ---Problem Description--- ip maddr show and ip maddr show dev enP20p96s0 show different data ---uname output--- Linux roselp1 4.10.0-14-generic #16-Ubuntu SMP Fri Mar 17 15:19:05 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux Machine Type = 8286-42A ---Steps to Reproduce--- run these at command line: root@roselp1:~# ip maddr show ... 10: enP20p96s0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 link 33:33:ff:6d:d0:d0 link 01:00:5e:00:00:fc link 33:33:00:01:00:03 inet 224.0.0.252 inet 224.0.0.1 inet6 ff02::1:3 inet6 ff02::1:ff6d:d0d0 users 3 inet6 ff02::1 inet6 ff01::1 ... root@roselp1:~# ip maddr show dev enP20p96s0 10: enP20p96s0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 link 33:33:ff:6d:d0:d0 link 01:00:5e:00:00:fc link 33:33:00:01:00:03 inet6 ff02::1:3 inet6 ff02::1:ff6d:d0d0 users 3 inet6 ff02::1 inet6 ff01::1 == Comment: #12 - David Z. Dai - 2017-11-13 15:07:32 == I found upstream already ha
[Touch-packages] [Bug 1733870] Re: [Ubuntu 18.10] Add GDB support to access/display POWER8 registers
** Summary changed: - [Ubuntu 18.04] Add GDB support to access/display POWER8 registers + [Ubuntu 18.10] Add GDB support to access/display POWER8 registers -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1733870 Title: [Ubuntu 18.10] Add GDB support to access/display POWER8 registers Status in The Ubuntu-power-systems project: Incomplete Status in gdb package in Ubuntu: Incomplete Bug description: This feature request is for GDB support for access to Power registers that are currently not accessible: PPR, DSCR, TAR, EBB, PMU and HTM registers. The feature is currently being worked on, so no upstream code is available yet. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1733870/+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 1742941] Re: zlib: improve crc32 performance on P8
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Importance: Undecided => Low ** Changed in: ubuntu-power-systems Assignee: (unassigned) => David Britton (davidpbritton) ** Tags added: triage-g -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1742941 Title: zlib: improve crc32 performance on P8 Status in The Ubuntu-power-systems project: New Status in zlib package in Ubuntu: New Bug description: Calculate the checksum of data that is 16 byte aligned and a multiple of 16 bytes. The first step is to reduce it to 1024 bits. We do this in 8 parallel chunks in order to mask the latency of the vpmsum instructions. If we have more than 32 kB of data to checksum we repeat this step multiple times, passing in the previous 1024 bits. The next step is to reduce the 1024 bits to 64 bits. This step adds 32 bits of 0s to the end - this matches what a CRC does. We just calculate constants that land the data in this 32 bits. We then use fixed point Barrett reduction to compute a mod n over GF(2) for n = CRC using POWER8 instructions. We use x = 32. http://en.wikipedia.org/wiki/Barrett_reduction To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1742941/+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 1724152] Re: ISST-LTE: pVM: aureport couldn't get the right auid from the audit log on ubuntu16.04
** Tags added: triage-g -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to audit in Ubuntu. https://bugs.launchpad.net/bugs/1724152 Title: ISST-LTE: pVM: aureport couldn't get the right auid from the audit log on ubuntu16.04 Status in The Ubuntu-power-systems project: Fix Committed Status in audit package in Ubuntu: Invalid Status in audit source package in Xenial: Fix Committed Status in audit source package in Zesty: Fix Committed Bug description: [Impact] The aureport command, part of the audit userspace utilities, incorrectly reports the user id of successful logins. "-1" is printed instead of the expected user id. [Test Case] As root, run `login`. Proceed as follows: 1. Login with a blank username and any password 2. Login with an invalid username and any password 3. Login with a valid username and an invalid password 4. Login with a valid username and a valid password 5. Exit from the login shell 6. Run `aureport -l` and examine the last for login records An unpatched aureport will print the following: # date time auid host term exe success event ... 2. 10/17/2017 23:45:32 UNKNOWN ? /dev/pts/8 /bin/login no 97 3. 10/17/2017 23:45:39 UNKNOWN ? /dev/pts/8 /bin/login no 99 4. 10/17/2017 23:45:45 tyhicks ? /dev/pts/8 /bin/login no 101 5. 10/17/2017 23:45:49 -1 ? /dev/pts/8 /bin/login yes 107 A patch aureport will print the correct output: Login Report # date time auid host term exe success event ... 2. 10/17/2017 23:52:44 UNKNOWN ? /dev/pts/8 /bin/login no 165 3. 10/17/2017 23:52:52 UNKNOWN ? /dev/pts/8 /bin/login no 167 4. 10/17/2017 23:52:58 tyhicks ? /dev/pts/8 /bin/login no 169 5. 10/17/2017 23:53:02 1000 ? /dev/pts/8 /bin/login yes 175 Note the "1000" in the auid column on the #5 row. It should *not* be "-1". [Regression Potential] The regression potential is limited due to the change only affecting a single line of code, the fix comes from upstream, and that the aureport utility is not critical. [Original Report] == Comment: #0 - Miao Tao Feng - 2016-11-23 02:46:25 == When we develop new testcase for audit, we found that command "aureport -l" print out wrong auid "-1" on ubuntu16.04 and it should be 1000 according to the audit.log. The following are details: root@roselp2:~# aureport -l Login Report # date time auid host term exe success event 1. 11/23/2016 02:20:12 -1 10.33.24.118 /dev/pts/0 /usr/sbin/sshd yes 18 The auid "-1" on the above line should be "1000? according to the audit.log. root@roselp2:~# grep ":18" /var/log/audit/audit.log type=USER_LOGIN msg=audit(1479889212.292:18): pid=4177 uid=0 auid=1000 ses=4 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.33.24.118 addr=10.33.24.118 terminal=/dev/pts/0 res=success' root@roselp2:~# dpkg -s auditd Package: auditd Status: install ok installed Priority: extra Section: admin Installed-Size: 1051 Maintainer: Ubuntu Developers Architecture: ppc64el Source: audit Version: 1:2.4.5-1ubuntu2 Depends: lsb-base (>= 3.0-6), mawk | gawk, init-system-helpers (>= 1.18~), libaudit1 (>= 1:2.4.2), libauparse0 (>= 1:2.3.1), libc6 (>= 2.17) Suggests: audispd-plugins root@roselp2:~# uname -a Linux roselp2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:38:24 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux root@roselp2:~# service auditd status ? auditd.service - Security Auditing Service Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: e Active: active (running) since Wed 2016-11-23 02:19:21 CST; 19s ago Main PID: 4085 (auditd) CGroup: /system.slice/auditd.service ??4085 /sbin/auditd -n Nov 23 02:19:21 roselp2 auditctl[4086]: enabled 0 Nov 23 02:19:21 roselp2 auditctl[4086]: failure 1 Nov 23 02:19:21 roselp2 auditctl[4086]: pid 0 Nov 23 02:19:21 roselp2 auditctl[4086]: rate_limit 0 Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_limit 320 Nov 23 02:19:21 roselp2 auditctl[4086]: lost 0 Nov 23 02:19:21 roselp2 auditctl[4086]: backlog 0 Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_wait_time 15000 Nov 23 02:19:21 roselp2 systemd[1]: Started Security Auditing Service. Nov 23 02:19:21 roselp2 auditd[4085]: Init complete, auditd 2.4.5 listening for Please cherry pick https://github.com/linux-audit/audit- userspace/commit/25097d64344828a80acf681da5c1dacc4ea3c069 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1724152/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.la
[Touch-packages] [Bug 1719720] Re: [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with exit code 127
Since this issue cannot be reproduced with 4.13, marking "invalid". ** Changed in: ubuntu-power-systems Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1719720 Title: [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with exit code 127 Status in The Ubuntu-power-systems project: Invalid Status in coreutils package in Ubuntu: Invalid Bug description: ---Problem Description--- Currently syslog is getting flooded with below log messages .. Sep 25 03:16:41 ubuntu1710 systemd-udevd[2654]: Process '/bin/touch /run/run.vpdd update' failed with exit code 127. This is on UBuntu 17.10 latest build.. ---uname output--- Linux ubuntu1710 4.12.0-11-generic #12-Ubuntu SMP Fri Aug 11 12:23:06 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux Machine Type = ZZ-L ---Steps to Reproduce--- I have seen these messages logged more often when we do any hotplug operations.. ex. cpu hotplug.. Ok. .this is the continuation of LTC #144627 / Launchpad #1682774. As suggested in that bug, we did change udev script to create temporary file under /run and that patch is available in ubuntu 17.10. Looks like this is udev script issue. If I modify systemd-udevd like below it works fine. I've limited udev knowledge. I don't know if you have any other better solution to this issue. root@ltc-boston123:/lib/systemd/system# diff -Naurp systemd-udevd.service.org systemd-udevd.service --- systemd-udevd.service.org 2017-09-26 04:37:47.090057318 -0500 +++ systemd-udevd.service 2017-09-26 04:37:55.381739372 -0500 @@ -25,7 +25,7 @@ KillMode=mixed WatchdogSec=3min TasksMax=infinity MountFlags=slave -MemoryDenyWriteExecute=yes +#MemoryDenyWriteExecute=yes RestrictRealtime=yes RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 SystemCallArchitectures=native -Vasant To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1719720/+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 1732032] Re: ip maddr show and ip maddr show dev enP20p96s0 show different data
** Changed in: ubuntu-power-systems Status: Triaged => In Progress -- 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/1732032 Title: ip maddr show and ip maddr show dev enP20p96s0 show different data Status in The Ubuntu-power-systems project: In Progress Status in iproute2 package in Ubuntu: Fix Released Status in iproute2 source package in Trusty: New Status in iproute2 source package in Xenial: New Status in iproute2 source package in Zesty: New Status in iproute2 source package in Artful: New Bug description: [Impact] When a nic has a long enough name such that there is no space between the name and the ":" in /proc/net/igmp, ip maddr show dev will miss the IPV4 addresses which is otherwise shown with "ip maddr show". This is inconsistent behavior and can break scripts and tests, as shown in this bug's original description. Three patches from upstream were taken to fix this bug, and they were used individually instead of being merged into one single patch so it's easier to track and recognize authorship: https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=530903dd9003492edb0714e937ad4a5d1219e376 https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=b48a1161f5f9b6a0cda399a224bbbf72eba4a5c6 https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?id=21503ed2af233ffe795926f6641ac84ec1b15bf9 [Test Case] * deploy the ubuntu release under test. Please use bare metal or a VM instead of containers, because the ip tool parses a file in /proc. Make sure iproute2 is installed: sudo apt install iproute2 * Run these commands to setup a dummy interface with a long name and an IPv4 address. Please change the address if it conflicts with a real network you might have available on that machine: sudo ip link add dummylongnic0 type dummy sudo ip addr add 192.168.199.10/24 dev dummylongnic0 sudo ip link set dev dummylongnic0 up * Compare the output of these two commands with regards to the dummylongnic0 interface: sudo ip maddr show sudo ip maddr show dev dummylongnic0 * With the buggy iproute2 package installed, the more specific output "ip maddr show dev dummylongnic0" should lack the "inet 224.0.0.1" line: ip maddr show dev dummylongnic0 2:dummylongnic0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 inet6 ff02::1 inet6 ff01::1 Whereas the less specific command, which lists all interfaces, will have it listed for dummylongnic0: 2:dummylongnic0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 inet 224.0.0.1 inet6 ff02::1 inet6 ff01::1 * With the fixed iproute2 package, all dummylongnic0 addresses will be present in both outputs. [Regression Potential] In the end, the ip tool is parsing a text file produced by the kernel. As most parsing done in C, it's pretty low level and sensitive to changes in the file it's reading. [Other Info] I suggest to conduct the tests in VMs instead of containers (LXD) because the ip maddr command parses /proc/net/igmp, which is produced by the kernel. If you use a container, then it's the host's kernel that will be providing that file and it might not be the same as with the native kernel of that particular ubuntu release. --- Original description --- Attn. Canonical: Please make sure that the existing iproute2 package gets updated with the two referenced patches as the missing information is impacting our standard test suites. Thanks. == Comment: #0 - Alton L. Pundt - 2017-03-29 14:37:57 == ---Problem Description--- ip maddr show and ip maddr show dev enP20p96s0 show different data ---uname output--- Linux roselp1 4.10.0-14-generic #16-Ubuntu SMP Fri Mar 17 15:19:05 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux Machine Type = 8286-42A ---Steps to Reproduce--- run these at command line: root@roselp1:~# ip maddr show ... 10: enP20p96s0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 link 33:33:ff:6d:d0:d0 link 01:00:5e:00:00:fc link 33:33:00:01:00:03 inet 224.0.0.252 inet 224.0.0.1 inet6 ff02::1:3 inet6 ff02::1:ff6d:d0d0 users 3 inet6 ff02::1 inet6 ff01::1 ... root@roselp1:~# ip maddr show dev enP20p96s0 10: enP20p96s0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 link 33:33:ff:6d:d0:d0 link 01:00:5e:00:00:fc link 33:33:00:01:00:03 inet6 ff02::1:3 inet6 ff02::1:ff6d:d0d0 users 3 inet6 ff02::1 inet6 ff01::1 == Comment: #12 - David Z. Dai - 2017-11-13 15:07:32 == I found upstream already had patches that fix this problem: 1) ht
[Touch-packages] [Bug 1732865] Re: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies
** Changed in: ubuntu-power-systems Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1732865 Title: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies Status in The Ubuntu-power-systems project: Triaged Status in util-linux package in Ubuntu: New Bug description: == Comment: #0 - Pridhiviraj Paidipeddi - 2017-01-03 05:34:32 == ---Problem Description--- After 3 CPU's are garded, lscpu failed to list CPU max and min frequencies Contact Information = ppaid...@in.ibm.com ---uname output--- Linux p8wookie 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux Machine Type = PowerNV 8284-22A ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Read lscpu output 2. Inject HMI Non recoverable error three times 3. Read lscpu output again compare the output cpu frequencies will list as NULL Stack trace output: no Oops output: no Userspace tool common name: lscpu Userspace rpm: util-linux The userspace tool has the following bit modes: 64-bit System Dump Info: The system is not configured to capture a system dump. Userspace tool obtained from project website: na *Additional Instructions for ppaid...@in.ibm.com: -Post a private note with access information to the machine that the bug is occuring on. -Attach sysctl -a output output to the bug. -Attach ltrace and strace of userspace application. Before CPU's are garded: root@p8wookie:~# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):112 On-line CPU(s) list: 0-71,80-103,112-127 Thread(s) per core:8 Core(s) per socket:3 Socket(s): 4 NUMA node(s): 4 Model: 2.1 (pvr 004b 0201) Model name:POWER8E (raw), altivec supported CPU max MHz: 4322. CPU min MHz: 2061. L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 0-31 NUMA node1 CPU(s): 32-63 NUMA node16 CPU(s):64-71,80-95 NUMA node17 CPU(s):96-103,112-127 After 4 cores are garded: root@p8wookie:~# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):96 On-line CPU(s) list: 8-55,64-71,80-103,112-127 Thread(s) per core:8 Core(s) per socket:3 Socket(s): 4 NUMA node(s): 4 Model: 2.1 (pvr 004b 0201) Model name:POWER8E (raw), altivec supported CPU max MHz: (null) CPU min MHz: (null) L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 8-31 NUMA node1 CPU(s): 32-55 NUMA node16 CPU(s):64-71,80-95 NUMA node17 CPU(s):96-103,112-127 == Comment: #1 - Pridhiviraj Paidipeddi - 2017-01-11 07:06:59 == root@p8wookie:~# dmesg |grep -i powernv [0.00] Using PowerNV machine description [0.331564] EEH: PowerNV platform initialized [0.907250] powernv-rng: Registering arch random hook. [1.504063] powernv-cpufreq: cpufreq pstate min -68 nominal -5 max 0 [1.507167] powernv_idle_driver registered [ 34.184048] powernv_rng: Registered powernv hwrng. [ 34.185619] ipmi-powernv ibm,opal:ipmi: Unable to map irq from device tree [ 34.210966] ipmi-powernv ibm,opal:ipmi: Found new BMC (man_id: 0x00, prod_id: 0x, dev_id: 0x00) root@p8wookie:~# cat /sys/firmware/opal/msglog | grep -i occ [ 42.297825315,7] OCC Common Area at 0x3b0 size 1MB [ 42.297854780,7] OCC Common Area at 0x200080 size 1MB [ 42.297884305,7] OCC Common Area at 0x200080 size 1MB [ 42.297914258,7] OCC Common Area at 0x200080 size 1MB [ 42.310897465,7] HBRT: OCC common base 00200080 : 0080 [ 42.317109440,7] HBRT: OCC common base 00200080 : 0080 [ 42.323969570,7] HBRT: OCC common base 00200080 : 0080 [ 42.330941943,7] HBRT: OCC common base 00200080 : 0080 [5.349544066,6] OCC: Got OCC Load message, scope=0x2 dbob=0x0 seq=0x29 [6.017413373,7] HBRT: OCC Load requested [6.017414365,7] HBRT: Calling loadOCC() homer 00200140, occ_common_area 00200080, chip [6.017553013,7] HBRT: Calling loadOCC() homer 3a00, occ_common_area 00200080, chip 0001 [6.017666150,7] HBRT: Calling loadOCC() homer 00280040, occ_common_area 00200080, chip 0010 [6.017790110,7] HBRT: Calling loadOCC() homer 0010004000
[Touch-packages] [Bug 1732032] Re: ip maddr show and ip maddr show dev enP20p96s0 show different data
** Changed in: ubuntu-power-systems Status: New => Triaged -- 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/1732032 Title: ip maddr show and ip maddr show dev enP20p96s0 show different data Status in The Ubuntu-power-systems project: Triaged Status in iproute2 package in Ubuntu: New Bug description: Attn. Canonical: Please make sure that the existing iproute2 package gets updated with the two referenced patches as the missing information is impacting our standard test suites. Thanks. == Comment: #0 - Alton L. Pundt - 2017-03-29 14:37:57 == ---Problem Description--- ip maddr show and ip maddr show dev enP20p96s0 show different data ---uname output--- Linux roselp1 4.10.0-14-generic #16-Ubuntu SMP Fri Mar 17 15:19:05 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux Machine Type = 8286-42A ---Steps to Reproduce--- run these at command line: root@roselp1:~# ip maddr show ... 10: enP20p96s0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 link 33:33:ff:6d:d0:d0 link 01:00:5e:00:00:fc link 33:33:00:01:00:03 inet 224.0.0.252 inet 224.0.0.1 inet6 ff02::1:3 inet6 ff02::1:ff6d:d0d0 users 3 inet6 ff02::1 inet6 ff01::1 ... root@roselp1:~# ip maddr show dev enP20p96s0 10: enP20p96s0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 link 33:33:ff:6d:d0:d0 link 01:00:5e:00:00:fc link 33:33:00:01:00:03 inet6 ff02::1:3 inet6 ff02::1:ff6d:d0d0 users 3 inet6 ff02::1 inet6 ff01::1 == Comment: #12 - David Z. Dai - 2017-11-13 15:07:32 == I found upstream already had patches that fix this problem: 1) https://www.spinics.net/lists/netdev/msg415009.html commit 530903dd9003492edb0714e937ad4a5d1219e376 Author: Petr Vorel Date: Tue Jan 17 00:25:50 2017 +0100 ip: fix igmp parsing when iface is long Entries with long vhost names in /proc/net/igmp have no whitespace between name and colon, so sscanf() adds it to vhost and 'ip maddr show iface' doesn't include inet result. Signed-off-by: Petr Vorel 2) https://www.spinics.net/lists/netdev/msg461479.html commit 21503ed2af233ffe795926f6641ac84ec1b15bf9 Author: Michal Kubecek Date: Thu Oct 19 10:21:08 2017 +0200 ip maddr: fix filtering by device Commit 530903dd9003 ("ip: fix igmp parsing when iface is long") uses variable len to keep trailing colon from interface name comparison. This variable is local to loop body but we set it in one pass and use it in following one(s) so that we are actually using (pseudo)random length for comparison. This became apparent since commit b48a1161f5f9 ("ipmaddr: Avoid accessing uninitialized data") always initializes len to zero so that the name comparison is always true. As a result, "ip maddr show dev eth0" shows IPv4 multicast addresses for all interfaces. Instead of keeping the length, let's simply replace the trailing colon with a null byte. The bonus is that we get correct interface name in ma.name. Fixes: 530903dd9003 ("ip: fix igmp parsing when iface is long") Signed-off-by: Michal Kubecek Acked-by: Phil Sutter Acked-by: Petr Vorel The fix is in the same place, but different way. This is the current implementation In ip/ipmaddr.c file: struct ma_info *ma; if (buf[0] != '\t') { size_t len; sscanf(buf, "%d%s", &m.index, m.name); len = strlen(m.name); if (m.name[len - 1] == ':') m.name[len - 1] = '\0'; continue; } The existing "ip" command that shows the problem: [root@coral-sriov-host1 ip]# /usr/sbin/ip maddr show dev enP1p12s0f0 /* <-- We do NOT see the IPv4 maddr */ 2: enP1p12s0f0 link 01:00:5e:00:00:01 inet6 ff02::1 inet6 ff01::1 I clone the latest "ip" utility from upstream to the same test box. [root@coral-sriov-host1 git_iproute2]# git clone https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git I build the "ip" utility on same test box, which has the above 2 patches included. [root@coral-sriov-host1 ip]# /root/git_iproute2/iproute2/ip/ip maddr show dev enP1p12s0f0 /* <--- shows correct IPv4 maddr */ 2: enP1p12s0f0 link 01:00:5e:00:00:01 inet 224.0.0.1/* <--- */ inet6 ff02::1 inet6 ff01::1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1732032/+subscriptions -- Mailing list: ht
[Touch-packages] [Bug 1732865] Re: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies
** Changed in: ubuntu-power-systems Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1732865 Title: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies Status in The Ubuntu-power-systems project: Triaged Status in util-linux package in Ubuntu: New Bug description: == Comment: #0 - Pridhiviraj Paidipeddi - 2017-01-03 05:34:32 == ---Problem Description--- After 3 CPU's are garded, lscpu failed to list CPU max and min frequencies Contact Information = ppaid...@in.ibm.com ---uname output--- Linux p8wookie 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux Machine Type = PowerNV 8284-22A ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Read lscpu output 2. Inject HMI Non recoverable error three times 3. Read lscpu output again compare the output cpu frequencies will list as NULL Stack trace output: no Oops output: no Userspace tool common name: lscpu Userspace rpm: util-linux The userspace tool has the following bit modes: 64-bit System Dump Info: The system is not configured to capture a system dump. Userspace tool obtained from project website: na *Additional Instructions for ppaid...@in.ibm.com: -Post a private note with access information to the machine that the bug is occuring on. -Attach sysctl -a output output to the bug. -Attach ltrace and strace of userspace application. Before CPU's are garded: root@p8wookie:~# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):112 On-line CPU(s) list: 0-71,80-103,112-127 Thread(s) per core:8 Core(s) per socket:3 Socket(s): 4 NUMA node(s): 4 Model: 2.1 (pvr 004b 0201) Model name:POWER8E (raw), altivec supported CPU max MHz: 4322. CPU min MHz: 2061. L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 0-31 NUMA node1 CPU(s): 32-63 NUMA node16 CPU(s):64-71,80-95 NUMA node17 CPU(s):96-103,112-127 After 4 cores are garded: root@p8wookie:~# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):96 On-line CPU(s) list: 8-55,64-71,80-103,112-127 Thread(s) per core:8 Core(s) per socket:3 Socket(s): 4 NUMA node(s): 4 Model: 2.1 (pvr 004b 0201) Model name:POWER8E (raw), altivec supported CPU max MHz: (null) CPU min MHz: (null) L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 8-31 NUMA node1 CPU(s): 32-55 NUMA node16 CPU(s):64-71,80-95 NUMA node17 CPU(s):96-103,112-127 == Comment: #1 - Pridhiviraj Paidipeddi - 2017-01-11 07:06:59 == root@p8wookie:~# dmesg |grep -i powernv [0.00] Using PowerNV machine description [0.331564] EEH: PowerNV platform initialized [0.907250] powernv-rng: Registering arch random hook. [1.504063] powernv-cpufreq: cpufreq pstate min -68 nominal -5 max 0 [1.507167] powernv_idle_driver registered [ 34.184048] powernv_rng: Registered powernv hwrng. [ 34.185619] ipmi-powernv ibm,opal:ipmi: Unable to map irq from device tree [ 34.210966] ipmi-powernv ibm,opal:ipmi: Found new BMC (man_id: 0x00, prod_id: 0x, dev_id: 0x00) root@p8wookie:~# cat /sys/firmware/opal/msglog | grep -i occ [ 42.297825315,7] OCC Common Area at 0x3b0 size 1MB [ 42.297854780,7] OCC Common Area at 0x200080 size 1MB [ 42.297884305,7] OCC Common Area at 0x200080 size 1MB [ 42.297914258,7] OCC Common Area at 0x200080 size 1MB [ 42.310897465,7] HBRT: OCC common base 00200080 : 0080 [ 42.317109440,7] HBRT: OCC common base 00200080 : 0080 [ 42.323969570,7] HBRT: OCC common base 00200080 : 0080 [ 42.330941943,7] HBRT: OCC common base 00200080 : 0080 [5.349544066,6] OCC: Got OCC Load message, scope=0x2 dbob=0x0 seq=0x29 [6.017413373,7] HBRT: OCC Load requested [6.017414365,7] HBRT: Calling loadOCC() homer 00200140, occ_common_area 00200080, chip [6.017553013,7] HBRT: Calling loadOCC() homer 3a00, occ_common_area 00200080, chip 0001 [6.017666150,7] HBRT: Calling loadOCC() homer 00280040, occ_common_area 00200080, chip 0010 [6.017790110,7] HBRT: Calling loadOCC() homer 00100040, occ_common_area 00200080, chip 0011 [
[Touch-packages] [Bug 1708409] Re: kdump service does not start after configure/reboot
** Tags added: ppc64el-kdump -- 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 1699759] Re: LXC Alpine template broken on ppc64le
** Changed in: ubuntu-power-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1699759 Title: LXC Alpine template broken on ppc64le Status in The Ubuntu-power-systems project: Fix Released Status in lxc package in Ubuntu: Fix Released Bug description: == Comment: #0 - Breno Leitao - 2017-06-14 07:36:33 == LXC Alpine template is broken on Ubuntu 17.10, since it does not support ppc64le. It shows the following message: # Unknown architecture. == Comment: #1 - Breno Leitao - 2017-06-14 07:37:50 == Patch sent to upstream and accepted already: https://github.com/lxc/lxc/pull/1621#issuecomment-307887344 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1699759/+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 1719579] Re: [Ubuntu 16.04.2] [libvirt] virsh restore fails from state file saved in /var/tmp folder using virsh save
** Changed in: ubuntu-power-systems Status: New => Incomplete -- 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/1719579 Title: [Ubuntu 16.04.2] [libvirt] virsh restore fails from state file saved in /var/tmp folder using virsh save Status in The Ubuntu-power-systems project: Incomplete Status in apparmor package in Ubuntu: Incomplete Bug description: == Comment: #1 - SEETEENA THOUFEEK - 2017-01-17 00:09:16 == Bala, Please mail me the machine information. == Comment: #3 - SEETEENA THOUFEEK - 2017-01-17 02:14:06 == 2017-01-16 12:09:37.707+: 7024: info : virSecurityDACRestoreFileLabelInternal:388 : Restoring DAC user and group on '/var/tmp/bala' 2017-01-16 12:09:37.707+: 7024: info : virSecurityDACSetOwnershipInternal:290 : Setting DAC user and group on '/var/tmp/bala' to '0:0' 2017-01-16 12:09:37.707+: 7024: warning : qemuDomainSaveImageStartVM:6750 : failed to restore save state label on /var/tmp/bala 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff4ca62b00 2017-01-16 12:09:37.707+: 7024: debug : qemuDomainObjEndAsyncJob:1848 : Stopping async job: start (vm=0x3fff4ca535c0 name=virt-tests-vm1-bala) 2017-01-16 12:09:37.707+: 7024: info : virObjectRef:296 : OBJECT_REF: obj=0x3fff4ca62b00 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff4ca62b00 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff4ca535c0 2017-01-16 12:09:37.707+: 7024: debug : virThreadJobClear:121 : Thread 7024 (virNetServerHandleJob) finished job remoteDispatchDomainRestore with ret=-1 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff7c002c10 2017-01-16 12:09:37.707+: 7024: debug : virNetServerProgramSendError:153 : prog=536903814 ver=1 proc=54 type=1 serial=4 msg=0x100133d2590 rerr=0x3fffa59be3c0 2017-01-16 12:09:37.707+: 7024: debug : virNetMessageEncodePayload:376 : Encode length as 172 2017-01-16 12:09:37.707+: 7024: debug : virNetServerClientSendMessageLocked:1399 : msg=0x100133d2590 proc=54 len=172 offset=0 2017-01-16 12:09:37.707+: 7024: info : virNetServerClientSendMessageLocked:1407 : RPC_SERVER_CLIENT_MSG_TX_QUEUE: client=0x100133d23c0 len=172 prog=536903814 vers=1 proc=54 type=1 status=1 serial=4 2017-01-16 12:09:37.707+: 7024: debug : virNetServerClientCalculateHandleMode:157 : tls=(nil) hs=-1, rx=0x100133d0670 tx=0x100133d2590 2017-01-16 12:09:37.707+: 7024: debug : virNetServerClientCalculateHandleMode:192 : mode=3 2017-01-16 12:09:37.707+: 7024: info : virEventPollUpdateHandle:152 : EVENT_POLL_UPDATE_HANDLE: watch=417 events=3 2017-01-16 12:09:37.707+: 7024: debug : virEventPollInterruptLocked:727 : Interrupting 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x3fff7c002c10 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x100133caea0 2017-01-16 12:09:37.707+: 7024: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x100133d23c0 . 2017-01-16 12:14:28.445+: 7019: info : qemuMonitorJSONIOProcessLine:201 : QEMU_MONITOR_RECV_EVENT: mon=0x3fff94004d90 event={"timestamp": {"seconds": 1484568868, "microseconds": 444620}, "event": "MIGRATION", "data": {"status": "failed"}} 2017-01-16 12:14:28.445+: 7019: debug : qemuMonitorJSONIOProcessEvent:147 : mon=0x3fff94004d90 obj=0x100133b5670 2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToString:1762 : object=0x100133a8000 2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToStringOne:1691 : object=0x100133a8000 type=0 gen=0x100133d1160 2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToStringOne:1691 : object=0x100133d2a80 type=2 gen=0x100133d1160 2017-01-16 12:14:28.445+: 7019: debug : virJSONValueToString:1795 : result={"status":"failed"} 2017-01-16 12:14:28.445+: 7019: debug : qemuMonitorEmitEvent:1218 : mon=0x3fff94004d90 event=MIGRATION 2017-01-16 12:14:28.445+: 7019: info : virObjectRef:296 : OBJECT_REF: obj=0x3fff94004d90 2017-01-16 12:14:28.445+: 7019: debug : qemuProcessHandleEvent:629 : vm=0x3fff4ca535c0 2017-01-16 12:14:28.445+: 7019: info : virObjectNew:202 : OBJECT_NEW: obj=0x100133d2870 classname=virDomainQemuMonitorEvent 2017-01-16 12:14:28.445+: 7019: debug : virObjectEventNew:645 : obj=0x100133d2870 2017-01-16 12:14:28.445+: 7019: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x100133d2870 2017-01-16 12:14:28.445+: 7019: info : virObjectUnref:261 : OBJECT_DISPOSE: obj=0x100133d2870 2017-01-16 12:14:28.445+: 7019: debug : virDomainQemuMonitorEventDispose:477 : obj=0x100133d2870 2017-01-16 12:14:28.445+: 7019: debug : virObjectEventDispose:121 : obj=0x100133d2870 201
[Touch-packages] [Bug 1719720] Re: [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with exit code 127
** Tags added: triage-g -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1719720 Title: [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with exit code 127 Status in The Ubuntu-power-systems project: Triaged Status in coreutils package in Ubuntu: Triaged Bug description: ---Problem Description--- Currently syslog is getting flooded with below log messages .. Sep 25 03:16:41 ubuntu1710 systemd-udevd[2654]: Process '/bin/touch /run/run.vpdd update' failed with exit code 127. This is on UBuntu 17.10 latest build.. ---uname output--- Linux ubuntu1710 4.12.0-11-generic #12-Ubuntu SMP Fri Aug 11 12:23:06 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux Machine Type = ZZ-L ---Steps to Reproduce--- I have seen these messages logged more often when we do any hotplug operations.. ex. cpu hotplug.. Ok. .this is the continuation of LTC #144627 / Launchpad #1682774. As suggested in that bug, we did change udev script to create temporary file under /run and that patch is available in ubuntu 17.10. Looks like this is udev script issue. If I modify systemd-udevd like below it works fine. I've limited udev knowledge. I don't know if you have any other better solution to this issue. root@ltc-boston123:/lib/systemd/system# diff -Naurp systemd-udevd.service.org systemd-udevd.service --- systemd-udevd.service.org 2017-09-26 04:37:47.090057318 -0500 +++ systemd-udevd.service 2017-09-26 04:37:55.381739372 -0500 @@ -25,7 +25,7 @@ KillMode=mixed WatchdogSec=3min TasksMax=infinity MountFlags=slave -MemoryDenyWriteExecute=yes +#MemoryDenyWriteExecute=yes RestrictRealtime=yes RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 SystemCallArchitectures=native -Vasant To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1719720/+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 1732865] Re: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies
Apologies, initially misdirected to kernel team. We believe util-linux is owned by server team. Please advise if that is not correct. ** Changed in: ubuntu-power-systems Assignee: Canonical Kernel Team (canonical-kernel-team) => David Britton (davidpbritton) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1732865 Title: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies Status in The Ubuntu-power-systems project: New Status in util-linux package in Ubuntu: New Bug description: == Comment: #0 - Pridhiviraj Paidipeddi - 2017-01-03 05:34:32 == ---Problem Description--- After 3 CPU's are garded, lscpu failed to list CPU max and min frequencies Contact Information = ppaid...@in.ibm.com ---uname output--- Linux p8wookie 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux Machine Type = PowerNV 8284-22A ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Read lscpu output 2. Inject HMI Non recoverable error three times 3. Read lscpu output again compare the output cpu frequencies will list as NULL Stack trace output: no Oops output: no Userspace tool common name: lscpu Userspace rpm: util-linux The userspace tool has the following bit modes: 64-bit System Dump Info: The system is not configured to capture a system dump. Userspace tool obtained from project website: na *Additional Instructions for ppaid...@in.ibm.com: -Post a private note with access information to the machine that the bug is occuring on. -Attach sysctl -a output output to the bug. -Attach ltrace and strace of userspace application. Before CPU's are garded: root@p8wookie:~# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):112 On-line CPU(s) list: 0-71,80-103,112-127 Thread(s) per core:8 Core(s) per socket:3 Socket(s): 4 NUMA node(s): 4 Model: 2.1 (pvr 004b 0201) Model name:POWER8E (raw), altivec supported CPU max MHz: 4322. CPU min MHz: 2061. L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 0-31 NUMA node1 CPU(s): 32-63 NUMA node16 CPU(s):64-71,80-95 NUMA node17 CPU(s):96-103,112-127 After 4 cores are garded: root@p8wookie:~# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):96 On-line CPU(s) list: 8-55,64-71,80-103,112-127 Thread(s) per core:8 Core(s) per socket:3 Socket(s): 4 NUMA node(s): 4 Model: 2.1 (pvr 004b 0201) Model name:POWER8E (raw), altivec supported CPU max MHz: (null) CPU min MHz: (null) L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 8-31 NUMA node1 CPU(s): 32-55 NUMA node16 CPU(s):64-71,80-95 NUMA node17 CPU(s):96-103,112-127 == Comment: #1 - Pridhiviraj Paidipeddi - 2017-01-11 07:06:59 == root@p8wookie:~# dmesg |grep -i powernv [0.00] Using PowerNV machine description [0.331564] EEH: PowerNV platform initialized [0.907250] powernv-rng: Registering arch random hook. [1.504063] powernv-cpufreq: cpufreq pstate min -68 nominal -5 max 0 [1.507167] powernv_idle_driver registered [ 34.184048] powernv_rng: Registered powernv hwrng. [ 34.185619] ipmi-powernv ibm,opal:ipmi: Unable to map irq from device tree [ 34.210966] ipmi-powernv ibm,opal:ipmi: Found new BMC (man_id: 0x00, prod_id: 0x, dev_id: 0x00) root@p8wookie:~# cat /sys/firmware/opal/msglog | grep -i occ [ 42.297825315,7] OCC Common Area at 0x3b0 size 1MB [ 42.297854780,7] OCC Common Area at 0x200080 size 1MB [ 42.297884305,7] OCC Common Area at 0x200080 size 1MB [ 42.297914258,7] OCC Common Area at 0x200080 size 1MB [ 42.310897465,7] HBRT: OCC common base 00200080 : 0080 [ 42.317109440,7] HBRT: OCC common base 00200080 : 0080 [ 42.323969570,7] HBRT: OCC common base 00200080 : 0080 [ 42.330941943,7] HBRT: OCC common base 00200080 : 0080 [5.349544066,6] OCC: Got OCC Load message, scope=0x2 dbob=0x0 seq=0x29 [6.017413373,7] HBRT: OCC Load requested [6.017414365,7] HBRT: Calling loadOCC() homer 00200140, occ_common_area 00200080, chip [6.017553013,7] HBRT: Calling loadOCC() homer 3a00, occ_common_area 00200080, chip 0001 [6.017666150,7] HBRT: Calling lo
[Touch-packages] [Bug 1732032] Re: ip maddr show and ip maddr show dev enP20p96s0 show different data
** Changed in: ubuntu-power-systems Assignee: Canonical Server Team (canonical-server) => David Britton (davidpbritton) -- 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/1732032 Title: ip maddr show and ip maddr show dev enP20p96s0 show different data Status in The Ubuntu-power-systems project: New Status in iproute2 package in Ubuntu: New Bug description: Attn. Canonical: Please make sure that the existing iproute2 package gets updated with the two referenced patches as the missing information is impacting our standard test suites. Thanks. == Comment: #0 - Alton L. Pundt - 2017-03-29 14:37:57 == ---Problem Description--- ip maddr show and ip maddr show dev enP20p96s0 show different data ---uname output--- Linux roselp1 4.10.0-14-generic #16-Ubuntu SMP Fri Mar 17 15:19:05 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux Machine Type = 8286-42A ---Steps to Reproduce--- run these at command line: root@roselp1:~# ip maddr show ... 10: enP20p96s0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 link 33:33:ff:6d:d0:d0 link 01:00:5e:00:00:fc link 33:33:00:01:00:03 inet 224.0.0.252 inet 224.0.0.1 inet6 ff02::1:3 inet6 ff02::1:ff6d:d0d0 users 3 inet6 ff02::1 inet6 ff01::1 ... root@roselp1:~# ip maddr show dev enP20p96s0 10: enP20p96s0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 link 33:33:ff:6d:d0:d0 link 01:00:5e:00:00:fc link 33:33:00:01:00:03 inet6 ff02::1:3 inet6 ff02::1:ff6d:d0d0 users 3 inet6 ff02::1 inet6 ff01::1 == Comment: #12 - David Z. Dai - 2017-11-13 15:07:32 == I found upstream already had patches that fix this problem: 1) https://www.spinics.net/lists/netdev/msg415009.html commit 530903dd9003492edb0714e937ad4a5d1219e376 Author: Petr Vorel Date: Tue Jan 17 00:25:50 2017 +0100 ip: fix igmp parsing when iface is long Entries with long vhost names in /proc/net/igmp have no whitespace between name and colon, so sscanf() adds it to vhost and 'ip maddr show iface' doesn't include inet result. Signed-off-by: Petr Vorel 2) https://www.spinics.net/lists/netdev/msg461479.html commit 21503ed2af233ffe795926f6641ac84ec1b15bf9 Author: Michal Kubecek Date: Thu Oct 19 10:21:08 2017 +0200 ip maddr: fix filtering by device Commit 530903dd9003 ("ip: fix igmp parsing when iface is long") uses variable len to keep trailing colon from interface name comparison. This variable is local to loop body but we set it in one pass and use it in following one(s) so that we are actually using (pseudo)random length for comparison. This became apparent since commit b48a1161f5f9 ("ipmaddr: Avoid accessing uninitialized data") always initializes len to zero so that the name comparison is always true. As a result, "ip maddr show dev eth0" shows IPv4 multicast addresses for all interfaces. Instead of keeping the length, let's simply replace the trailing colon with a null byte. The bonus is that we get correct interface name in ma.name. Fixes: 530903dd9003 ("ip: fix igmp parsing when iface is long") Signed-off-by: Michal Kubecek Acked-by: Phil Sutter Acked-by: Petr Vorel The fix is in the same place, but different way. This is the current implementation In ip/ipmaddr.c file: struct ma_info *ma; if (buf[0] != '\t') { size_t len; sscanf(buf, "%d%s", &m.index, m.name); len = strlen(m.name); if (m.name[len - 1] == ':') m.name[len - 1] = '\0'; continue; } The existing "ip" command that shows the problem: [root@coral-sriov-host1 ip]# /usr/sbin/ip maddr show dev enP1p12s0f0 /* <-- We do NOT see the IPv4 maddr */ 2: enP1p12s0f0 link 01:00:5e:00:00:01 inet6 ff02::1 inet6 ff01::1 I clone the latest "ip" utility from upstream to the same test box. [root@coral-sriov-host1 git_iproute2]# git clone https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git I build the "ip" utility on same test box, which has the above 2 patches included. [root@coral-sriov-host1 ip]# /root/git_iproute2/iproute2/ip/ip maddr show dev enP1p12s0f0 /* <--- shows correct IPv4 maddr */ 2: enP1p12s0f0 link 01:00:5e:00:00:01 inet 224.0.0.1/* <--- */ inet6 ff02::1 inet6 ff01::1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-s
[Touch-packages] [Bug 1732865] Re: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Importance: Undecided => High ** Changed in: ubuntu-power-systems Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team) ** Tags added: triage-g -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1732865 Title: [LTCTest][OPAL][FW860.20] lscpu failed to list cpu max and min frequencies Status in The Ubuntu-power-systems project: New Status in util-linux package in Ubuntu: New Bug description: == Comment: #0 - Pridhiviraj Paidipeddi - 2017-01-03 05:34:32 == ---Problem Description--- After 3 CPU's are garded, lscpu failed to list CPU max and min frequencies Contact Information = ppaid...@in.ibm.com ---uname output--- Linux p8wookie 4.8.0-32-generic #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux Machine Type = PowerNV 8284-22A ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Read lscpu output 2. Inject HMI Non recoverable error three times 3. Read lscpu output again compare the output cpu frequencies will list as NULL Stack trace output: no Oops output: no Userspace tool common name: lscpu Userspace rpm: util-linux The userspace tool has the following bit modes: 64-bit System Dump Info: The system is not configured to capture a system dump. Userspace tool obtained from project website: na *Additional Instructions for ppaid...@in.ibm.com: -Post a private note with access information to the machine that the bug is occuring on. -Attach sysctl -a output output to the bug. -Attach ltrace and strace of userspace application. Before CPU's are garded: root@p8wookie:~# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):112 On-line CPU(s) list: 0-71,80-103,112-127 Thread(s) per core:8 Core(s) per socket:3 Socket(s): 4 NUMA node(s): 4 Model: 2.1 (pvr 004b 0201) Model name:POWER8E (raw), altivec supported CPU max MHz: 4322. CPU min MHz: 2061. L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 0-31 NUMA node1 CPU(s): 32-63 NUMA node16 CPU(s):64-71,80-95 NUMA node17 CPU(s):96-103,112-127 After 4 cores are garded: root@p8wookie:~# lscpu Architecture: ppc64le Byte Order:Little Endian CPU(s):96 On-line CPU(s) list: 8-55,64-71,80-103,112-127 Thread(s) per core:8 Core(s) per socket:3 Socket(s): 4 NUMA node(s): 4 Model: 2.1 (pvr 004b 0201) Model name:POWER8E (raw), altivec supported CPU max MHz: (null) CPU min MHz: (null) L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 8-31 NUMA node1 CPU(s): 32-55 NUMA node16 CPU(s):64-71,80-95 NUMA node17 CPU(s):96-103,112-127 == Comment: #1 - Pridhiviraj Paidipeddi - 2017-01-11 07:06:59 == root@p8wookie:~# dmesg |grep -i powernv [0.00] Using PowerNV machine description [0.331564] EEH: PowerNV platform initialized [0.907250] powernv-rng: Registering arch random hook. [1.504063] powernv-cpufreq: cpufreq pstate min -68 nominal -5 max 0 [1.507167] powernv_idle_driver registered [ 34.184048] powernv_rng: Registered powernv hwrng. [ 34.185619] ipmi-powernv ibm,opal:ipmi: Unable to map irq from device tree [ 34.210966] ipmi-powernv ibm,opal:ipmi: Found new BMC (man_id: 0x00, prod_id: 0x, dev_id: 0x00) root@p8wookie:~# cat /sys/firmware/opal/msglog | grep -i occ [ 42.297825315,7] OCC Common Area at 0x3b0 size 1MB [ 42.297854780,7] OCC Common Area at 0x200080 size 1MB [ 42.297884305,7] OCC Common Area at 0x200080 size 1MB [ 42.297914258,7] OCC Common Area at 0x200080 size 1MB [ 42.310897465,7] HBRT: OCC common base 00200080 : 0080 [ 42.317109440,7] HBRT: OCC common base 00200080 : 0080 [ 42.323969570,7] HBRT: OCC common base 00200080 : 0080 [ 42.330941943,7] HBRT: OCC common base 00200080 : 0080 [5.349544066,6] OCC: Got OCC Load message, scope=0x2 dbob=0x0 seq=0x29 [6.017413373,7] HBRT: OCC Load requested [6.017414365,7] HBRT: Calling loadOCC() homer 00200140, occ_common_area 00200080, chip [6.017553013,7] HBRT: Calling loadOCC() homer 3a00, occ_common_area 00200080, chip 0001 [6.0176
[Touch-packages] [Bug 1724152] Re: ISST-LTE: pVM: aureport couldn't get the right auid from the audit log on ubuntu16.04
** Changed in: ubuntu-power-systems Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to audit in Ubuntu. https://bugs.launchpad.net/bugs/1724152 Title: ISST-LTE: pVM: aureport couldn't get the right auid from the audit log on ubuntu16.04 Status in The Ubuntu-power-systems project: In Progress Status in audit package in Ubuntu: Invalid Status in audit source package in Xenial: In Progress Status in audit source package in Zesty: In Progress Bug description: [Impact] The aureport command, part of the audit userspace utilities, incorrectly reports the user id of successful logins. "-1" is printed instead of the expected user id. [Test Case] As root, run `login`. Proceed as follows: 1. Login with a blank username and any password 2. Login with an invalid username and any password 3. Login with a valid username and an invalid password 4. Login with a valid username and a valid password 5. Exit from the login shell 6. Run `aureport -l` and examine the last for login records An unpatched aureport will print the following: # date time auid host term exe success event ... 2. 10/17/2017 23:45:32 UNKNOWN ? /dev/pts/8 /bin/login no 97 3. 10/17/2017 23:45:39 UNKNOWN ? /dev/pts/8 /bin/login no 99 4. 10/17/2017 23:45:45 tyhicks ? /dev/pts/8 /bin/login no 101 5. 10/17/2017 23:45:49 -1 ? /dev/pts/8 /bin/login yes 107 A patch aureport will print the correct output: Login Report # date time auid host term exe success event ... 2. 10/17/2017 23:52:44 UNKNOWN ? /dev/pts/8 /bin/login no 165 3. 10/17/2017 23:52:52 UNKNOWN ? /dev/pts/8 /bin/login no 167 4. 10/17/2017 23:52:58 tyhicks ? /dev/pts/8 /bin/login no 169 5. 10/17/2017 23:53:02 1000 ? /dev/pts/8 /bin/login yes 175 Note the "1000" in the auid column on the #5 row. It should *not* be "-1". [Regression Potential] The regression potential is limited due to the change only affecting a single line of code, the fix comes from upstream, and that the aureport utility is not critical. [Original Report] == Comment: #0 - Miao Tao Feng - 2016-11-23 02:46:25 == When we develop new testcase for audit, we found that command "aureport -l" print out wrong auid "-1" on ubuntu16.04 and it should be 1000 according to the audit.log. The following are details: root@roselp2:~# aureport -l Login Report # date time auid host term exe success event 1. 11/23/2016 02:20:12 -1 10.33.24.118 /dev/pts/0 /usr/sbin/sshd yes 18 The auid "-1" on the above line should be "1000? according to the audit.log. root@roselp2:~# grep ":18" /var/log/audit/audit.log type=USER_LOGIN msg=audit(1479889212.292:18): pid=4177 uid=0 auid=1000 ses=4 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.33.24.118 addr=10.33.24.118 terminal=/dev/pts/0 res=success' root@roselp2:~# dpkg -s auditd Package: auditd Status: install ok installed Priority: extra Section: admin Installed-Size: 1051 Maintainer: Ubuntu Developers Architecture: ppc64el Source: audit Version: 1:2.4.5-1ubuntu2 Depends: lsb-base (>= 3.0-6), mawk | gawk, init-system-helpers (>= 1.18~), libaudit1 (>= 1:2.4.2), libauparse0 (>= 1:2.3.1), libc6 (>= 2.17) Suggests: audispd-plugins root@roselp2:~# uname -a Linux roselp2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:38:24 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux root@roselp2:~# service auditd status ? auditd.service - Security Auditing Service Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor preset: e Active: active (running) since Wed 2016-11-23 02:19:21 CST; 19s ago Main PID: 4085 (auditd) CGroup: /system.slice/auditd.service ??4085 /sbin/auditd -n Nov 23 02:19:21 roselp2 auditctl[4086]: enabled 0 Nov 23 02:19:21 roselp2 auditctl[4086]: failure 1 Nov 23 02:19:21 roselp2 auditctl[4086]: pid 0 Nov 23 02:19:21 roselp2 auditctl[4086]: rate_limit 0 Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_limit 320 Nov 23 02:19:21 roselp2 auditctl[4086]: lost 0 Nov 23 02:19:21 roselp2 auditctl[4086]: backlog 0 Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_wait_time 15000 Nov 23 02:19:21 roselp2 systemd[1]: Started Security Auditing Service. Nov 23 02:19:21 roselp2 auditd[4085]: Init complete, auditd 2.4.5 listening for Please cherry pick https://github.com/linux-audit/audit- userspace/commit/25097d64344828a80acf681da5c1dacc4ea3c069 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1724152/+subscriptions -- Mailing list: https://launchpad.net/~touch-packag
[Touch-packages] [Bug 1719720] Re: [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with exit code 127
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) ** Changed in: ubuntu-power-systems Importance: Undecided => Medium -- 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/1719720 Title: [LTCTest][libvpd] Process '/bin/touch /run/run.vpdupdate' failed with exit code 127 Status in The Ubuntu-power-systems project: New Status in systemd package in Ubuntu: New Bug description: ---Problem Description--- Currently syslog is getting flooded with below log messages .. Sep 25 03:16:41 ubuntu1710 systemd-udevd[2654]: Process '/bin/touch /run/run.vpdd update' failed with exit code 127. This is on UBuntu 17.10 latest build.. ---uname output--- Linux ubuntu1710 4.12.0-11-generic #12-Ubuntu SMP Fri Aug 11 12:23:06 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux Machine Type = ZZ-L ---Steps to Reproduce--- I have seen these messages logged more often when we do any hotplug operations.. ex. cpu hotplug.. Ok. .this is the continuation of LTC #144627 / Launchpad #1682774. As suggested in that bug, we did change udev script to create temporary file under /run and that patch is available in ubuntu 17.10. Looks like this is udev script issue. If I modify systemd-udevd like below it works fine. I've limited udev knowledge. I don't know if you have any other better solution to this issue. root@ltc-boston123:/lib/systemd/system# diff -Naurp systemd-udevd.service.org systemd-udevd.service --- systemd-udevd.service.org 2017-09-26 04:37:47.090057318 -0500 +++ systemd-udevd.service 2017-09-26 04:37:55.381739372 -0500 @@ -25,7 +25,7 @@ KillMode=mixed WatchdogSec=3min TasksMax=infinity MountFlags=slave -MemoryDenyWriteExecute=yes +#MemoryDenyWriteExecute=yes RestrictRealtime=yes RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 SystemCallArchitectures=native -Vasant To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1719720/+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 1706948] Re: [Ubuntu 1710] [Feature] Inconsistent report of pm CanSuspend state by systemd and pm-utils
** Changed in: ubuntu-power-systems Status: New => Incomplete ** Changed in: pm-utils (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pm-utils in Ubuntu. https://bugs.launchpad.net/bugs/1706948 Title: [Ubuntu 1710] [Feature] Inconsistent report of pm CanSuspend state by systemd and pm-utils Status in The Ubuntu-power-systems project: Incomplete Status in pm-utils package in Ubuntu: Incomplete Bug description: == Comment: #0 - Balamuruhan S <> - 2017-06-28 03:39:15 == systemd and pm-utils interprets CanSuspend states differently and reports it as supported or not in a conflicting way. # gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanSuspend ('yes',) # pm-is-supported --suspend # echo $? 1 Both systemd and pm-is-supported looks into /sys/power/state file to check if suspend is supported. pm-is-supported --suspend returns true if either "standby" or "mem" is present in the file. ( /usr/lib/pm-utils/pm-functions ) systemd(Manager.CanSuspend) returns true if "standby", "freeze" or "mem" is present in the file. ( https://github.com/systemd/systemd/blob/dd8352659c9428b196706d04399eec106a8917ed/src/shared/sleep-config.c ) # cat /sys/power/state freeze So here, pm-is-supported --suspend returns false and gdbus returns true. Both these utilities interpret /sys/power/state differently. Secondly, systemd should split CanSuspend to Cansuspend+CanFreeze Or don't report freeze as CanSuspend. Impact of this inconsistency can be felt from Libvirt supported pm states: To reduce ABI dependency, libvirt queries the available states via dbus, if not falls to pm-utils. Libvirt won't check for strings in sys/power/state and interpret directly. so due to this, libvirt will list that suspend_to_mem is supported from virsh capabilities but ideally it might not. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1706948/+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 1651518] Re: systemd/logind parsing problem: HTX exercisers stopped on error: rc 11, errno 11 from main(): pthread_create
** Changed in: ubuntu-power-systems Status: Fix Committed => Fix Released -- 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/1651518 Title: systemd/logind parsing problem: HTX exercisers stopped on error: rc 11, errno 11 from main(): pthread_create Status in The Ubuntu-power-systems project: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Released Status in systemd source package in Yakkety: Fix Released Bug description: [SRU justification] Before systemd 232, UserTasksMax=infinity is not respected in logind.conf, despite the documentation referring to systemd.resource-control(5) for the definition of this field. This limits the use of Ubuntu 16.04 and later in contexts where a user session should be permitted to allocate large numbers of processes. [Test case] 1. Set UserTasksMax=infinity in /etc/systemd/logind.conf. 2. Create a new login session. 3. Check the ulimit for user processes with 'ulimit -u'. 4. Verify that the limit has a numeric value. 5. Upgrade to systemd from -proposed. 6. Create a new login session. 7. Check the ulimit for user processes with 'ulimit -u'. 8. Verify that the limit is now set to 'unlimited'. [Regression potential] This is an upstream patch which is part of 232 and later without issues and clearly addresses the bug in question. While the upstream commit includes code changes that are not strictly required in order to fix this bug, these are mostly cosmetic and should not carry significant additional risk. == Comment: #1 - Application Cdeadmin - 2016-12-19 04:15:10 == Configuration: IBM 8001-22C (S822LC), LSI SAS adapters, SMC 4U90 disk drawers, HDD (180) 7.3TB Problem: HTX exercisers stopped on error, with HTX log showing "rc 11, errno 11 from main(): pthread_create" htxubuntu-425 lpar: busybee.aus.stglabs.ibm.com (root/ lab passwd) root@busybee:~# uname -a Linux busybee 4.4.0-51-generic #72-Ubuntu SMP Thu Nov 24 18:27:59 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux root@busybee:~# cat /tmp/htxerr /dev/sdh Dec 12 23:52:42 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sdh Dec 12 23:52:42 2016 err=000b sev=1 hxestorage Hardware Exerciser stopped on an error /dev/sdao Dec 12 23:52:42 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sdao Dec 12 23:52:42 2016 err=000b sev=1 hxestorage Hardware Exerciser stopped on an error /dev/sddx Dec 12 23:52:42 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sddx Dec 12 23:52:42 2016 err=000b sev=1 hxestorage Hardware Exerciser stopped on an error /dev/sdcz Dec 12 23:52:42 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sdcz Dec 12 23:52:42 2016 err=000b sev=1 hxestorage Hardware Exerciser stopped on an error /dev/sddp Dec 12 23:52:42 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sddp Dec 12 23:52:42 2016 err=000b sev=1 hxestorage Hardware Exerciser stopped on an error No errors logged in syslog after starting HTX: State: Open by: asperez on 16 December 2016 10:28:02 This error recreated on the smaller 1U Open Power system with the same smaller 1-adapter/1-4U90 drawer/90 HDD. There are 2 cables connected to the drawer (one to each ESM) that requires multipath enabled. lpar: yellowbee root@yellowbee:~# cat /tmp/htxerr /dev/sdao Dec 16 01:14:44 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sdak Dec 16 01:14:44 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sdt Dec 16 01:14:44 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sdaz Dec 16 01:14:44 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sdn Dec 16 01:14:44 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sdv Dec 16 01:14:44 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sdaj Dec 16 01:14:44 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create /dev/sdal Dec 16 01:14:44 2016 err=000b sev=1 hxestorage rc 11, errno 11 from main(): pthread_create State: Open by: cde00 on 19 December 2016 02:48:46 This defect will go to Linux as even after making the below 2 changes in systemd resource limit, errors are seen: root@yellowbee:/etc/systemd/logind.conf.d# cat htxlogindcustom.conf [Login] UserTasksMax=infin
[Touch-packages] [Bug 1713536] Re: udev: boot script does not trigger subsystem coldplug
** Also affects: ubuntu-power-systems Importance: Undecided Status: New ** Changed in: ubuntu-power-systems Importance: Undecided => Medium ** Changed in: ubuntu-power-systems Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) -- 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/1713536 Title: udev: boot script does not trigger subsystem coldplug Status in The Ubuntu-power-systems project: New Status in systemd package in Ubuntu: New Bug description: The udev initramfs-tools boot script does not trigger subsystem "add" uevents. As a result, udev rules that listen to subsystem "add" events are never activated. This problem exists on at least Ubuntu 16.04 and 17.10. On s390, this results in a boot failure if the kernel is configured to start with an active device black list (kernel parameter cio_ignore=all,!condev). An example for an affected udev rule looks like this: ACTION=="add", SUBSYSTEM=="subsystem", KERNEL=="ccw", RUN{program}+="/bin/sh -c 'echo free 0009,ec30,ec32,f5f0-f5f2 > /proc/cio_ignore'" A proposed fix would be: Modify /usr/share/initramfs-tools/scripts/init-top/udev: Replace line udevadm trigger --action=add with udevadm trigger --type=subsystems --action=add udevadm trigger --type=devices --action=add This would also be consistent with the steps that the systemd udev coldplug unit file performs (see /lib/systemd/system/systemd-udev- trigger.service). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1713536/+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 1623383] Re: Some restarts fail due to missing base devices
Hi, we’re trying to explore different approaches to investigate, resolve and/or work around this issue, but regrettably there do not appear to be any simple solutions. Would it be possible to record the failure rate during the testing for the next SRU cycle? Perhaps something simple like “5 failures in 50 redeployments over a 2 week period”? Many thanks. -- 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/1623383 Title: Some restarts fail due to missing base devices Status in systemd package in Ubuntu: Confirmed Bug description: Arch: s390x Release: Yakkety / 16.10 This happens on some (but not all) system starts with Yakkety. In Xenial (which is using the same 4.4 kernel version the Yakkety systems were using when the problem was first observed) this did not happen. The system (LPAR) this was seen first was an upgrade from Xenial but since then has been freshly installed with Yakkety. The same behaviour is seen on a zVM guest running Yakkety. The attached syslog shows a failed boot, followed by one that did work. Note the "Found device .*(sclp|encc00).*" messages in the good boot. Those are missing in the bad attempt and as a result networking and console fail to be usable. Also note, those boots were 4.8 kernels but we saw this with 4.4 kernels, too. This might be a systemd problem / race, I just filed it into udev for now as that better matches the not finding basic devices symptom. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1623383/+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 1625319] Re: [LTCTest] SR-IOV VF hotplug failing: cannot limit locked memory of process
As per comment #5, marking as "Fix Released". ** Changed in: apparmor (Ubuntu) Status: Incomplete => Fix Released ** Changed in: apparmor (Ubuntu) Assignee: Taco Screen team (taco-screen-team) => (unassigned) -- 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/1625319 Title: [LTCTest] SR-IOV VF hotplug failing: cannot limit locked memory of process Status in apparmor package in Ubuntu: Fix Released Bug description: ---Problem Description--- Unable to hotplug SRIOV CX4 VF to Ubuntu 16.10 or 16.04.1 guests. ---uname output--- Linux c158f2u09os 4.7.0unofficial #5 SMP Mon Sep 5 08:53:38 EDT 2016 ppc64le ppc64le ppc64le GNU/Linux ---Additional Hardware Info--- Mellanox CX4 Machine Type = 8247-22L ---Steps to Reproduce--- Unable to hotplug SRIOV CX4 VF to Ubuntu 16.10 guest. 1. Boot the guests with/without VFs 2. Try hotplugging of VF to guests, you will notice error as shown below: root@c158f2u09os:/var/lib/libvirt/images/srikanth# cat hot_vf.xml root@c158f2u09os:/var/lib/libvirt/images/srikanth# virsh attach-device ubuntu1610_srik ./hot_vf.xml --live error: Failed to attach device from ./hot_vf.xml error: cannot limit locked memory of process 80265 to 9663676416: Permission denied root@c158f2u09os:/var/lib/libvirt/images/srikanth# virsh attach-device ubuntu160401_srik ./hot_vf.xml --live error: Failed to attach device from ./hot_vf.xml error: cannot limit locked memory of process 80960 to 9663676416: Permission denied = Environment details: = Host : 9.47.68.198, root/sriov4321 Ubuntu 16.10 kernel version: Linux c158f2u09os 4.7.0unofficial #5 SMP Mon Sep 5 08:53:38 EDT 2016 ppc64le ppc64le ppc64le GNU/Linux Guest: 1. ubuntu1610_srik kernel version: 4.7.0unofficial creds: root/123456 2. ubuntu160401_srik kernel version: 4.4.0-38-generic creds: root/123456 MOFED versions: MOFED version in Host as well Guest: 3.4-OFED.3.4.0.1.0.1 CX4 Firmware version: 12.17.0222 Development took a look at this an believes this is an apparmor related issue and requested the defect be mirrored to Canonical for their assistance. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1625319/+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 1653489] Re: [LTCTest][OPAL][FW860.20] Upgrade to Ubuntu 16.04.2 Alpha from Ubuntu 16.04.1 is dropping to (initramfs)
** Changed in: initramfs-tools (Ubuntu) Assignee: Taco Screen team (taco-screen-team) => (unassigned) -- 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/1653489 Title: [LTCTest][OPAL][FW860.20] Upgrade to Ubuntu 16.04.2 Alpha from Ubuntu 16.04.1 is dropping to (initramfs) Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: @kernel-team Please move ipr module from image-extra to image package. ---Problem Description--- Upgrade to Ubuntu 16.04.2 Alpha from Ubuntu 16.04.1 is dropping to (initramfs) Contact Information = pavsu...@in.ibm.com ---uname output--- Linux (none) 4.8.0-27-generic #29~16.04.1-Ubuntu SMP Fri Nov 4 17:24:37 UTC 2016 ppc64le GNU/Linux ---Additional Hardware Info--- root@powerkvm3-lp1:~# lspci :00:00.0 PCI bridge: IBM Device 03dc :01:00.0 RAID bus controller: IBM Obsidian-E PCI-E SCSI controller (rev 01) 0001:00:00.0 PCI bridge: IBM Device 03dc 0001:01:00.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI Express Gen 3 (8.0 GT/s) Switch (rev ca) 0001:02:01.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI Express Gen 3 (8.0 GT/s) Switch (rev ca) 0001:02:08.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI Express Gen 3 (8.0 GT/s) Switch (rev ca) 0001:02:09.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI Express Gen 3 (8.0 GT/s) Switch (rev ca) 0001:03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 0001:03:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 0001:03:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 0001:03:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 0001:04:00.0 RAID bus controller: IBM PCI-E IPR SAS Adapter (ASIC) (rev 01) 0001:05:00.0 RAID bus controller: IBM PCI-E IPR SAS Adapter (ASIC) (rev 01) 0004:00:00.0 PCI bridge: IBM Device 03dc 0004:01:00.0 Fibre Channel: Emulex Corporation Lancer-X: LightPulse Fibre Channel Host Adapter (rev 10) 0004:01:00.1 Fibre Channel: Emulex Corporation Lancer-X: LightPulse Fibre Channel Host Adapter (rev 10) 0005:00:00.0 PCI bridge: IBM Device 03dc 0005:01:00.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca) 0005:02:01.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca) 0005:02:08.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca) 0005:02:09.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca) 0005:02:10.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca) 0005:02:11.0 PCI bridge: PLX Technology, Inc. Device 8748 (rev ca) 0005:03:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller (rev 02) 0005:09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 0005:09:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 0005:09:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 0005:09:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 0005:0f:00.0 Fibre Channel: Emulex Corporation Saturn-X: LightPulse Fibre Channel Host Adapter (rev 03) 0005:0f:00.1 Fibre Channel: Emulex Corporation Saturn-X: LightPulse Fibre Channel Host Adapter (rev 03) 0040:00:00.0 PCI bridge: IBM Device 03dc 0044:00:00.0 PCI bridge: IBM Device 03dc 0044:01:00.0 Ethernet controller: Emulex Corporation OneConnect NIC (Lancer) (rev 10) 0044:01:00.1 Ethernet controller: Emulex Corporation OneConnect NIC (Lancer) (rev 10) 0044:01:00.2 Ethernet controller: Emulex Corporation OneConnect NIC (Lancer) (rev 10) 0044:01:00.3 Ethernet controller: Emulex Corporation OneConnect NIC (Lancer) (rev 10) 0044:01:00.4 Fibre Channel: Emulex Corporation OneConnect FCoE Initiator (Lancer) (rev 10) 0044:01:00.5 Fibre Channel: Emulex Corporation OneConnect FCoE Initiator (Lancer) (rev 10) 0045:00:00.0 PCI bridge: IBM Device 03dc 0045:01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 0045:01:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 0045:01:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) 0045:01:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01) Machine Type = P8 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Install Ubuntu 16.04.1 OS using netboot images. Then upgrade the kernel by Installing the kernel 4.8 on the same. After upgrading the kernel, we are bo
[Touch-packages] [Bug 1584602] Re: internal compiler error: in fixup_reorder_chain, , at cfgrtl.c:3336
I've raised https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1585174 to highlight the issue and suggest using the "-fno-if-conversion" option that Matthias has identifed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gcc-4.8 in Ubuntu. https://bugs.launchpad.net/bugs/1584602 Title: internal compiler error: in fixup_reorder_chain,, at cfgrtl.c:3336 Status in gcc-4.8 package in Ubuntu: Confirmed Bug description: When building samba package on trusty/arm64 with gcc-4.8, the following build crash can be observed, and it can be triggered with gcc-4.7 too. 01:07:10 runner /usr/bin/gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -- DSTATIC_LOCKING_MODULES=NULL -DSTATIC_LOCKING_MODULES_PROTO=extern void __LOCKINN G_dummy_module_proto(void) -MD -D_FORTIFY_SOURCE=2 -Idefault/source3 -I../sourcee 3 -Idefault/source3/include -I../source3/include -Idefault/source3/lib -I../sourr ce3/lib -Idefault/source4/heimdal/lib/com_err -I../source4/heimdal/lib/com_err -- Idefault/source4/heimdal/lib/krb5 -I../source4/heimdal/lib/krb5 -Idefault/sourcee 4/heimdal/lib/gssapi -I../source4/heimdal/lib/gssapi -Idefault/source4/heimdal_bb uild -I../source4/heimdal_build -Idefault/bin/default/source4/heimdal/lib/asn1 -- Idefault/source4/heimdal/lib/asn1 -Idefault/include/public -I../include/public -- Idefault/source4 -I../source4 -Idefault/lib -I../lib -Idefault/source4/lib -I..// source4/lib -Idefault/source4/include -I../source4/include -Idefault/include -I.. ./include -Idefault/lib/replace -I../lib/replace -Idefault -I.. -Idefault/librpcc -I../librpc -Idefault/libcli/security -I../libcli/security -Idefault/source3/lii brpc -I../source3/librpc -Idefault/libcli/util -I../libcli/util -Idefault/lib/utt il/charset -I../lib/util/charset -Idefault/dynconfig -I../dynconfig -Idefault/lii b/compression -I../lib/compression -Idefault/libcli/nbt -I../libcli/nbt -Idefaull t/lib/crypto -I../lib/crypto -I/usr/local/include -D_SAMBA_BUILD_=4 -DHAVE_CONFII G_H=1 -D_GNU_SOURCE=1 -D_XOPEN_SOURCE_EXTENDED=1 ../source3/locking/brlock.c -c -o default/source3/locking/brlock_92.o ../source3/smbd/notify.c: In function ‘change_notify_create’: ../source3/smbd/notify.c:297:1: internal compiler error: in fixup_reorder_chain,, at cfgrtl.c:3336 ../source3/smbd/notify.c: In function ‘change_notify_create’: ../source3/smbd/notify.c:297:1: internal compiler error: in fixup_reorder_chain,, at cfgrtl.c:3336 } ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1584602/+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 1464442] Re: installing or upgrading libc6 in Trusty removes all content from /tmp directory
This bug is also effecting the MAAS 1.7.1 deployment of Ubuntu 14.04 onto a diskless server with access to iSCSI LUN, as described in https://bugs.launchpad.net/curtin/+bug/1425264/. I've marked LP#1425264 as a dup of this bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to eglibc in Ubuntu. https://bugs.launchpad.net/bugs/1464442 Title: installing or upgrading libc6 in Trusty removes all content from /tmp directory Status in eglibc package in Ubuntu: Confirmed Bug description: We are seeing an issue with installation of dkms package during a curtin installation which ends up with /tmp directory being wiped clean. This is very bad for curtin as it saves critical installation files in /tmp. It turns out that it's the of upgrading libc6, which is triggered as a result of installing dependencies, that removes content of /tmp. For example, installation of gcc results in the same result since it ends up with libc6 being upgraded. The only way that this won't be recreated is if the latest libc6 is already installed. This problem does not exist in precise. It can also be recreated by installing the .deb file for any version in trusty including 2.17. ubuntu@host:~$ ls /tmp tmpHHbRkP ubuntu@sirrush:~$ sudo apt-get install libc6 sudo: unable to resolve host sirrush Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libc-dev-bin libc6-dev Suggested packages: glibc-doc Recommended packages: manpages-dev The following packages will be upgraded: libc-dev-bin libc6 libc6-dev 3 upgraded, 0 newly installed, 0 to remove and 148 not upgraded. Need to get 6,714 kB of archives. After this operation, 6,144 B disk space will be freed. Do you want to continue? [Y/n] y Get:1 http://archive.ubuntu.com/ubuntu/ trusty-updates/main libc6-dev amd64 2.19-0ubuntu6.6 [1,910 kB] Get:2 http://archive.ubuntu.com/ubuntu/ trusty-updates/main libc-dev-bin amd64 2.19-0ubuntu6.6 [68.9 kB] Get:3 http://archive.ubuntu.com/ubuntu/ trusty-updates/main libc6 amd64 2.19-0ubuntu6.6 [4,735 kB] Fetched 6,714 kB in 0s (18.5 MB/s) Preconfiguring packages ... (Reading database ... 57798 files and directories currently installed.) Preparing to unpack .../libc6-dev_2.19-0ubuntu6.6_amd64.deb ... Unpacking libc6-dev:amd64 (2.19-0ubuntu6.6) over (2.19-0ubuntu6.3) ... Preparing to unpack .../libc-dev-bin_2.19-0ubuntu6.6_amd64.deb ... Unpacking libc-dev-bin (2.19-0ubuntu6.6) over (2.19-0ubuntu6.3) ... Preparing to unpack .../libc6_2.19-0ubuntu6.6_amd64.deb ... Unpacking libc6:amd64 (2.19-0ubuntu6.6) over (2.19-0ubuntu6.3) ... Processing triggers for man-db (2.6.7.1-1) ... Setting up libc6:amd64 (2.19-0ubuntu6.6) ... Setting up libc-dev-bin (2.19-0ubuntu6.6) ... Setting up libc6-dev:amd64 (2.19-0ubuntu6.6) ... Processing triggers for libc-bin (2.19-0ubuntu6.3) ... ubuntu@host:~$ ls /tmp ubuntu@host:~$ This is very recreatable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1464442/+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