[Touch-packages] [Bug 1679674] Re: s390x: Interface order in kvm guest image not predictable
** Package changed: ubuntu => systemd (Ubuntu) -- 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/1679674 Title: s390x: Interface order in kvm guest image not predictable Status in systemd package in Ubuntu: New Bug description: ---Problem Description--- Running the Ubuntu16 cloud image on an ubuntu 16.04 KVM host. The KVM guest is launched with 2 network interfaces connected to 2 different open vswitch bridges. The problem is 2-fold: #1 In the guest it seems like that the interface order is not predicitve. Device names used are eth0, eth1. The device that is listed first in libvirts domain.xml is not necessarily eth0. #2 The device names are not persistet. On the next boot eth0 might be eth1 and vice verca. Contact Information = andreas.scheur...@de.ibm.com ---uname output--- Linux Ubuntu16 4.4.0-70-generic #91-Ubuntu SMP Wed Mar 22 12:48:02 UTC 2017 s390x s390x s390x GNU/Linux Machine Type = KVM guest ---Debugger--- A debugger is not configured ---Steps to Reproduce--- guest Domain xml: Ubuntu16VM 455e6998-cec1-4010-99a6-d033ee6d3385 524288 524288 2 /machine hvm destroy restart preserve /usr/bin/qemu-system-s390x libvirt-455e6998-cec1-4010-99a6-d033ee6d3385 libvirt-455e6998-cec1-4010-99a6-d033ee6d3385 in the guest check interfaces and remember the mac address # ip a Do a reboot (or multiple) and check again if the interface-mac combination is still the same The interface order should change from time to time Userspace tool common name: udev? Userspace rpm: ? The userspace tool has the following bit modes: 64 Userspace tool obtained from project website: na To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1679674/+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
** Package changed: ubuntu => systemd (Ubuntu) -- 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 systemd package in Ubuntu: New Bug description: == Comment: #1 - Application Cdeadmin <cdead...@us.ibm.com> - 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=infinity root@yellowbee:/etc/systemd/logind.conf.d# cat ../system.conf.d/htxsystemdcustom.conf [Manager] DefaultTasksAccounting=yes DefaultTasksMax=infinity root@yellowbee:/etc/systemd/logind.conf.d# logind limit for MaxUserTask as well as systemd limit was made infinite. Please look defect SW363655 for more details and the suggestion given earlier by Linux team. errors are still seen. So, would ask Linux team to take a look and see if anything else is causing these errors. == Comment: #3 - Kevin W. Rudd <ru...@us.ibm.com> - 2016-12-19 17:34:27 == It appears that the version of logind on this system does not support the value of "infinity", and is reverting to the default of 12288: # cat /sys/fs/cgroup/pids/user.slice/user-0.slice/pids.max 12288 As a workaround until this can be resolved, specify an exact value. You can try using the current system thread-max value: # cat /proc/sys/kernel/threads-max 3974272 /etc/systemd/logind.conf.d/htxlogindcustom.conf: [Login] UserTasksMax=3974272 == Comment: #4 - Kevin W. Rudd - 2016-12-20 10:25:09 == Canonical, This issue appears to map to the following systemd bug and patch: https://github.com/systemd/systemd/issues/
[Touch-packages] [Bug 1574832] Re: iptraf-ng display issue
** Package changed: ubuntu => ncurses (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ncurses in Ubuntu. https://bugs.launchpad.net/bugs/1574832 Title: iptraf-ng display issue Status in ncurses package in Ubuntu: New Bug description: == Comment: #0 - Aziz Rozyev - 2016-04-20 07:47:21 == ---Problem Description--- iptraf-ng ncurses environment does not display information correctly ---uname output--- Linux s35lp26 4.4.0-15-generic #31-Ubuntu SMP Fri Mar 18 19:07:12 UTC 2016 s390x s390x s390x GNU/Linux Machine Type = z13 lpar type: 2964 model: 703 N96 ---Steps to Reproduce--- iptraf-ng ncurses interface does not display windows, and information. Tested on linux and on Widnows Putty clients. Userspace tool common name: iptraf-ng == Comment: #1 - Kevin W. Rudd <ru...@us.ibm.com> - 2016-04-25 15:41:31 == I have been able to replicate this behavior with other architectures (ppc64le and x86_64). Even the latest build of iptraf-ng (from the upstream source) shows this behavior. This is not seen on a similar 14.04.4 system. I experimented with copying over the libncurses.so.5.9 and libncursesw.so.5.9 from a Trusty install, and found that this appears to be related to the Xenial version of libncursesw5. When run with the Trusty version of libncursesw.so.5.9, iptraf-ng behaved as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ncurses/+bug/1574832/+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 1569454] Re: Provide daemon support via systemd for mon_fsstatd, mon_procd, mon_statd
** Package changed: ubuntu => systemd (Ubuntu) -- 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/1569454 Title: Provide daemon support via systemd for mon_fsstatd, mon_procd, mon_statd Status in systemd package in Ubuntu: New Bug description: == Comment: #1 - Heinz-Werner Seeck - 2016-04-12 11:14:09 == With s390-tools (1.34.0-0ubuntu3) mon_statd daemons are able to start manually, using binaries for mon_fsstatd and mon_procd. But there are no services for these binaries available. In addition also the main service mon_statd is missing also. Please integrate these services via systemd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1569454/+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 1561096] Re: STC850:Brazos:Br16:Br16p05: Network ethernet port name changed under Ubuntu 16.04 with added adapters
** Package changed: ubuntu => systemd (Ubuntu) -- 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/1561096 Title: STC850:Brazos:Br16:Br16p05: Network ethernet port name changed under Ubuntu 16.04 with added adapters Status in systemd package in Ubuntu: New Bug description: Problem Description : I had installed a fresh install of Ubuntu 16.04 from an ISO image and had set up the partition as directed in the Wiki. I had set up the networking as directed in the WIKI and was able to ping "iofnim" and was able to perform updates and upgrades to the Ubuntu installation without issue. I had checked to make sure (by adding them to an existing AIX partition) that the Mason and Travis_EN adapters to be added were at the latest microcode levels. I assigned them to the partition to be used (br16p05) and then shut down the partition and restarted it to allow the partition to activate the adapters. After the partition restarted, I attempted to build the network using build_net and during its run noticed that the output for the adapters was returning "Network is unreachable". After it completed, I attempted to mount iofnim using the command: "mount iofnim.aus.stglabs.ibm.com:/nim/build_net /root/test -o nolock" which returned a "Failed" error message. I then ran "ifconfig -a" to check on the state of the network which had been working until I rebooted the partition after adding the adapters. I found the unconventional names for both the Mason and the Travis_EN adapters contained in the output from "ifconfig -a" but also found that "eth0", with which I had originally set up the network access for the partition during setupp, was no longer listed but instead "eth1" was now listed and none of the networking data including IP's reported from "ifconfig -a" were set. I consulted with Thiru and he asked I write it up and include a tar file created from /var/log which I have attached to the defect. As an additional note, I was able to go back into /etc/network/interfaces and modify the settings for "eth0" to now be set to "eth1" and after bringing the port down and back up, was able to again ping out and access the network. Please advise. == Comment: #7 - Kevin W. Rudd - 2016-02-11 12:32:49 == Thank you for the additional info. This is not quite the same as the bug I referenced earlier. It is actually a match for bug 122308 . Canonical: This is the same basic issue as originally worked in LP Bug 1437375 The ibmveth based devices are not associated with PCI bus locations, and still rely on the legacy eth? naming. The problem here is that the 75-persistent-net-generator.rules file that used to set up the 70 -persistent-net.rules file for these devices has been removed in 16.04 This creates a name-slip problem for these ibmveth devices depending on the timing of other devices (where another NIC will temporarily be assigned a name like eth0 before it is renamed by udev). Please add back persistent-net-generator support for non-PCI-based devices like this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1561096/+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
