[Bug 1761379] Re: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu
Thanks Brad, I just saw that this has been in -proposed for a bit on bionic, missed that originally when looking for the file https://packages.ubuntu.com/search?searchon=contents=libperf-jvmti.so=exactfilename=bionic-updates=any We'll keep our eyes peeled for the release. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1761379 Title: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1761379/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1761379] Re: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu
** Also affects: linux-aws (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1761379 Title: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1761379/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1761379] Re: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu
Can anyone comment as to whether or not this will be considered for kernels beyond -generic and -hwe? Specifically for aws, aws-hwe, and aws-edge kernels? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1761379 Title: [18.04/18.10] File libperf-jvmti.so is missing in linux-tools-common deb on Ubuntu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1761379/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1803600] Re: Elantech - Touchpad not working after upgrading to 18.10 from 18.04
I'm using a Thinkpad T480s and while my Elantech touchpad was mostly functional upon moving to 18.10 two-finger right-click and three-finger middle-click stopped working. `libinput list-devices` showed 'none' for a couple of features like 'Click methods.' The same fixes above worked for me (both the kernel command line as well as the sysfs protocol tweak). Currently running 4.18.0-15-generic # cat /sys/bus/serio/devices/serio1/firmware_id PNP: LEN008f PNP0f13 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1803600 Title: Elantech - Touchpad not working after upgrading to 18.10 from 18.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1788035] Re: nvme: avoid cqe corruption
We encountered an instance that had a nvme failure very early on in boot today. I've updated our internal Canonical case as well as our Amazon case on this, but posting relevant details here as well for consistency: # uname -a Linux XXX 4.4.0-1069-aws #79-Ubuntu SMP Mon Sep 24 15:01:41 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.5 LTS" # echo type $EC2_INSTANCE_TYPE type m5.xlarge # lsblk NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:00 10G 0 disk / # ls -al /dev/nvme* /dev/xvd* /dev/sd* ls: cannot access '/dev/xvd*': No such file or directory crw--- 1 root root 248, 0 Oct 31 15:02 /dev/nvme0 brw-rw 1 root disk 259, 0 Oct 31 15:02 /dev/nvme0n1 lrwxrwxrwx 1 root root 7 Oct 31 15:02 /dev/sda1 -> nvme0n1 # dmesg | grep '63\.' [ 63.401466] nvme :00:1f.0: I/O 0 QID 0 timeout, disable controller [ 63.505790] nvme :00:1f.0: Cancelling I/O 0 QID 0 [ 63.505812] nvme :00:1f.0: Identify Controller failed (-4) [ 63.507536] nvme :00:1f.0: Removing after probe failure [ 63.507604] iounmap: bad address c90001b4 [ 63.508941] CPU: 1 PID: 351 Comm: kworker/1:3 Tainted: P O 4.4.0-1069-aws #79-Ubuntu [ 63.508943] Hardware name: Amazon EC2 m5.xlarge/, BIOS 1.0 10/16/2017 [ 63.508948] Workqueue: events nvme_remove_dead_ctrl_work [nvme] [ 63.508950] 0286 3501e2639044a4d2 8800372bfce0 923ffe03 [ 63.508952] 88040dd878f0 c90001b4 8800372bfd00 9206d3af [ 63.508954] 88040dd878f0 88040dd87a58 8800372bfd10 9206d3ec [ 63.508956] Call Trace: [ 63.508961] [] dump_stack+0x63/0x90 [ 63.508965] [] iounmap.part.1+0x7f/0x90 [ 63.508967] [] iounmap+0x2c/0x30 [ 63.508969] [] nvme_dev_unmap.isra.35+0x1a/0x30 [nvme] [ 63.508972] [] nvme_remove+0xce/0xe0 [nvme] [ 63.508976] [] pci_device_remove+0x3e/0xc0 [ 63.508980] [] __device_release_driver+0xa4/0x150 [ 63.508982] [] device_release_driver+0x23/0x30 [ 63.508986] [] pci_stop_bus_device+0x7a/0xa0 [ 63.508988] [] pci_stop_and_remove_bus_device_locked+0x1a/0x30 [ 63.508990] [] nvme_remove_dead_ctrl_work+0x3c/0x50 [nvme] [ 63.508994] [] process_one_work+0x16b/0x490 [ 63.508996] [] worker_thread+0x4b/0x4d0 [ 63.508998] [] ? process_one_work+0x490/0x490 [ 63.509001] [] kthread+0xe7/0x100 [ 63.509005] [] ? __schedule+0x301/0x7f0 [ 63.509007] [] ? kthread_create_on_node+0x1e0/0x1e0 [ 63.509009] [] ret_from_fork+0x55/0x80 [ 63.509011] [] ? kthread_create_on_node+0x1e0/0x1e0 [ 63.509013] Trying to free nonexistent resource# modinfo nvme filename: /lib/modules/4.4.0-1069-aws/kernel/drivers/nvme/host/nvme.ko version:1.0 license:GPL author: Matthew Wilcox srcversion: 5CF522443B009A8675C497B alias: pci:v106Bd2001sv*sd*bc*sc*i* alias: pci:v*d*sv*sd*bc01sc08i02* alias: pci:v144DdA822sv*sd*bc*sc*i* alias: pci:v144DdA821sv*sd*bc*sc*i* alias: pci:v1C58d0003sv*sd*bc*sc*i* alias: pci:v8086d5845sv*sd*bc*sc*i* alias: pci:v8086dF1A5sv*sd*bc*sc*i* alias: pci:v8086d0953sv*sd*bc*sc*i* depends: retpoline: Y intree: Y vermagic: 4.4.0-1069-aws SMP mod_unload modversions retpoline parm: admin_timeout:timeout in seconds for admin commands (uint) parm: io_timeout:timeout in seconds for I/O (uint) parm: shutdown_timeout:timeout in seconds for controller shutdown (byte) parm: use_threaded_interrupts:int parm: use_cmb_sqes:use controller's memory buffer for I/O SQes (bool) parm: nvme_major:int parm: nvme_char_major:int parm: default_ps_max_latency_us:max power saving latency for new devices; use PM QOS to change per device (ulong) # systool -m nvme -va Module = "nvme" Attributes: coresize= "65536" initsize= "0" initstate = "live" refcnt = "1" srcversion = "5CF522443B009A8675C497B" taint = "" uevent = version = "1.0" Parameters: admin_timeout = "60" default_ps_max_latency_us= "10" io_timeout = "4294967295" shutdown_timeout= "5" use_cmb_sqes= "Y" Sections: .bss= "0xc03a3780" .data = "0xc03a3000" .data.unlikely = "0xc03a33d8" .exit.text = "0xc03a0cea" .gnu.linkonce.this_module= "0xc03a3400" .init.text = "0xc03a8000" .note.gnu.build-id = "0xc03a1000" .parainstructions = "0xc03a1b88" .rodata = "0xc03a1060" .rodata.str1.1 =
[Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/kernel/sysctl.c#n2433 and https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/kernel/sysctl.c#n2446 are the source(s) of the noise Looking at nearby functions like proc_dointvec_ibrs_ctrl and proc_dointvec_ipbp_ctrl, I suspect the intention was to use pr_debug instead of printk... Introduced in this commit: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/commit/kernel/sysctl.c?id=5e7fa0233bdfe2906216606d0d4d156be8f86950 I haven't done any digging on 3.13 but expect it will be similar. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1755627 Title: ibrs/ibpb fixes result in excessive kernel logging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging
Also, to call it out again, this appears to affect Trusty's LTS kernel, too (it's not clear how one marks a bug as such from the Launchpad UI) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1755627 Title: ibrs/ibpb fixes result in excessive kernel logging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging
For the sake of completeness on this one, I installed the following mainline packages on an AWS m5.large instance running 16.04.3 w/ 4.4.0-112-generic - linux-headers-4.16.0-041600rc4_4.16.0-041600rc4.201803041930_all.deb - linux-headers-4.16.0-041600rc4-generic_4.16.0-041600rc4.201803041930_amd64.deb - linux-image-4.16.0-041600rc4-generic_4.16.0-041600rc4.201803041930_amd64.deb This does NOT trigger the bug, either via `sysctl -a` or `sysctl kernel.ibrs_dump` as `/proc/sys/kernel/ibrs_dump` does not exist. This is the same behavior on Bionic w/ 4.15. ** Tags added: kernel-fixed-upstream -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1755627 Title: ibrs/ibpb fixes result in excessive kernel logging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging
It's worth noting, too, that this does not happen on Bionic @ 4.15 (using Ubuntu 4.15.0-1001.1-aws 4.15.3) but it does happen on Trusty (using Ubuntu 3.13.0-143.192-generic 3.13.11-ckt39) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1755627 Title: ibrs/ibpb fixes result in excessive kernel logging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1755627] Re: ibrs/ibpb fixes result in excessive kernel logging
We do not use apport and this is easily reproducible. If there is any pointed information I can provide beyond what I've already submitted, please let me know. ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1755627 Title: ibrs/ibpb fixes result in excessive kernel logging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1755627] [NEW] ibrs/ibpb fixes result in excessive kernel logging
Public bug reported:
Since at least kernel 4.4.0-116, every invocation of `sysctl -a` results
in kernel logs similar to the following:
% sysctl -a &>/dev/null; dmesg -T | tail -8
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:06:36 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:06:36 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:06:36 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:06:36 2018] read cpu 1 ibrs val 0
The output varies with the number of CPUs.
After digging a bit, it turns out this is triggered upon every read of
`kernel.ibrs_dump`:
% for i in {1..3}; do sysctl kernel.ibrs_dump; dmesg -T | tail -8; echo; sleep
1; done
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:48 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:48 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:48 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:48 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:49 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:49 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:49 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:49 2018] read cpu 1 ibrs val 0
kernel.ibrs_dump = 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
[Wed Mar 14 00:08:50 2018] sysctl_ibrs_enabled = 0, sysctl_ibpb_enabled = 0
[Wed Mar 14 00:08:50 2018] use_ibrs = 4, use_ibpb = 4
[Wed Mar 14 00:08:50 2018] read cpu 0 ibrs val 0
[Wed Mar 14 00:08:50 2018] read cpu 1 ibrs val 0
Those tests were against an EC2 instance running Ubuntu 4.4.0-116.140-generic
4.4.98 per /proc/version_signature
Normally this would not be the biggest concern but we have tooling that
gathers instance info on a schedule, including sysctl output, thus
resulting in the kernel ring buffer being full of nothing but said
output in most cases and hindering live troubleshooting as a result.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Incomplete
** Tags: xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1755627
Title:
ibrs/ibpb fixes result in excessive kernel logging
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1755627/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1752722] Re: systemd 237 reports incorrect state when drop-in present
It looks like this was fixed upstream and it would be fantastic if this could make it into Bionic before anything is frozen. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1752722 Title: systemd 237 reports incorrect state when drop-in present To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1752722/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1752722] Re: systemd 237 reports incorrect state when drop-in present
This does not appear to affect Artful and systemd 234. Example session: ~# cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=17.10 DISTRIB_CODENAME=artful DISTRIB_DESCRIPTION="Ubuntu 17.10" ~# uname -a Linux ip-100-65-137-86 4.13.0-36-generic #40-Ubuntu SMP Fri Feb 16 20:07:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux ~# systemctl --version systemd 234 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN default-hierarchy=hybrid ~# systemctl daemon-reload ~# systemctl list-unit-files test-mask.service 0 unit files listed. ~# cat < /lib/systemd/system/test-mask.service > [Unit] > Description=dummy service > > [Service] > Type=oneshot > ExecStart=/bin/true > > [Install] > WantedBy=multi-user.target > > EOF ~# systemctl daemon-reload ~# systemctl list-unit-files test-mask.service; echo '**'; systemctl is-enabled test-mask.service; echo '**'; systemctl status test-mask.service UNIT FILE STATE test-mask.service disabled 1 unit files listed. ** disabled ** ● test-mask.service - dummy service Loaded: loaded (/lib/systemd/system/test-mask.service; disabled; vendor preset: enabled) Active: inactive (dead) ~# systemctl enable test-mask.service Created symlink /etc/systemd/system/multi-user.target.wants/test-mask.service → /lib/systemd/system/test-mask.service. ~# systemctl list-unit-files test-mask.service; echo '**'; systemctl is-enabled test-mask.service; echo '**'; systemctl status test-mask.service UNIT FILE STATE test-mask.service enabled 1 unit files listed. ** enabled ** ● test-mask.service - dummy service Loaded: loaded (/lib/systemd/system/test-mask.service; enabled; vendor preset: enabled) Active: inactive (dead) ~# systemctl list-unit-files test-mask.service; echo '**'; systemctl is-enabled test-mask.service; echo '**'; systemctl status test-mask.service UNIT FILE STATE test-mask.service masked 1 unit files listed. ** masked ** ● test-mask.service Loaded: masked (/dev/null; bad) Active: inactive (dead) ~# systemctl unmask test-mask.service Removed /etc/systemd/system/test-mask.service. ~# mkdir -p /etc/systemd/system/test-mask.service.d ~# cat < /etc/systemd/system/test-mask.service.d/override.conf > # Arbitrary override for the sake of demonstration > [Unit] > After=ssh.service > > EOF ~# systemctl daemon-reload ~# systemctl cat test-mask.service # /lib/systemd/system/test-mask.service [Unit] Description=dummy service [Service] Type=oneshot ExecStart=/bin/true [Install] WantedBy=multi-user.target # /etc/systemd/system/test-mask.service.d/override.conf # Arbitrary override for the sake of demonstration [Unit] After=ssh.service ~# systemctl list-unit-files test-mask.service; echo '**'; systemctl is-enabled test-mask.service; echo '**'; systemctl status test-mask.service UNIT FILE STATE test-mask.service enabled 1 unit files listed. ** enabled ** ● test-mask.service - dummy service Loaded: loaded (/lib/systemd/system/test-mask.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/test-mask.service.d └─override.conf Active: inactive (dead) ~# systemctl mask test-mask.service Created symlink /etc/systemd/system/test-mask.service → /dev/null. ~# systemctl list-unit-files test-mask.service; echo '**'; systemctl is-enabled test-mask.service; echo '**'; systemctl status test-mask.service UNIT FILE STATE test-mask.service masked 1 unit files listed. ** masked ** Warning: test-mask.service changed on disk. Run 'systemctl daemon-reload' to reload units. ● test-mask.service Loaded: masked (/dev/null; bad) Active: inactive (dead) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1752722 Title: systemd 237 reports incorrect state when drop-in present To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1752722/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1752722] [NEW] systemd 237 reports incorrect state when drop-in present
Public bug reported: Raised this upstream: https://github.com/systemd/systemd/issues/8328 In short, in systemd 237 as it ships with Bionic, if a unit has a drop- in present but has been masked, systemctl is-enabled and systemctl list- unit-files report incorrect state, showing the units as enabled rather than masked. This works as-expected in systemd 229 under Xenial. I have not tested under systemd 234 in artful so I cannot say for sure exactly when this was introduced, but will spin up a quick test to see if this also exists under systemd 234. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1752722 Title: systemd 237 reports incorrect state when drop-in present To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1752722/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1679768] Re: Docker build hangs on XFS with kernel 4.10
Seeing the same on Xenial when using linux-hwe-edge ** Also affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1679768 Title: Docker build hangs on XFS with kernel 4.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1679768/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1651278] Re: systemd-sysv-generator does not fully translate facilities to targets
If at all possible, I'd love to see this fix backported to Xenial. Given that the bug appears to have existed as long as the sysv-generator has, the biggest risk is to those who may be erroneously depending on the incorrect behavior (whether explicitly or otherwise). I've attached a very basic systemd target and sysv init script that can be used to test and verify. With the test `bar.target` in /lib/systemd/system and enabled, and the `foo` init script (which, for the sake of demonstration, only contains LSB headers) in /etc/init.d and having been enabled by update-rc.d, the generated systemd wrapper is: ### # Automatically generated by systemd-sysv-generator [Unit] Documentation=man:systemd-sysv-generator(8) SourcePath=/etc/init.d/foo Description=LSB: Start service foo Before=multi-user.target Before=multi-user.target Before=multi-user.target Before=graphical.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes ExecStart=/etc/init.d/foo start ExecStop=/etc/init.d/foo stop ### and is missing dependency info for bar.target (expecting to see After=bar.target) ** Attachment added: "Simple sysv init stub and systemd target for testing" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1651278/+attachment/4794167/+files/systemd-generator-init-target-test.tar.gz -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1651278 Title: systemd-sysv-generator does not fully translate facilities to targets To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1651278/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1651278] [NEW] systemd-sysv-generator does not fully translate facilities to targets
Public bug reported: See the bug raised here: https://github.com/systemd/systemd/issues/4762 and fixed upstream here: https://github.com/systemd/systemd/commit/e932f5407ef5ad05d25d7dfefa4cda0fe81cc346 In short, given a sysv-init script with valid LSB headers, one of which defines Required-Start: $foo and given that a foo.target target exists and is enabled, I would expect to see After=foo.target in the generated unit. In practice (on all versions of systemd prior to the unreleased v233) no other facilities beyond the pre-defined facilities ($network, $local_fs, etc) will be used in generating the systemd wrapper for the old sysv init script. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1651278 Title: systemd-sysv-generator does not fully translate facilities to targets To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1651278/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1503382] Re: unable to install python3.4 dev on fresh ubuntu cloud image
We encountered the same and were able to overcome it by force-downgrading python3.4, python3.4-minimal, libpython3.4-stdlib, and libpython3.4-minimal to the current version available in the repositories with apt-get install -y \ python3.4=3.4.0-2ubuntu1.1 \ python3.4-minimal=3.4.0-2ubuntu1.1 \ libpython3.4-stdlib=3.4.0-2ubuntu1.1 \ libpython3.4-minimal=3.4.0-2ubuntu1.1 At-a-glance, it looks like the cloud image was (accidentally?) built with a newer version of python 3.4 than what is available for the LTS (3.4.3 doesn't look like it hit Ubuntu until Vivid?) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1503382 Title: unable to install python3.4 dev on fresh ubuntu cloud image To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1503382/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1308796] Re: Bad page map in openjdk-7
@Viktor, I believe that patch was later reverted and a new one was issued to fix https://lkml.org/lkml/2014/4/10/174 https://lkml.org/lkml/2014/4/8/173 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1308796 Title: Bad page map in openjdk-7 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1308796/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1195474] Re: xennet driver reports skb rides the rocket under moderate load
FWIW, we ran into the same messages and in researching, I came across this page https://silenteh.com/sysadmin/2013/08/08/amazon-ec2-xennet-skb-rides-the-rocket.html which suggests disabling TCP offload functionality using ethtool -K eth0 rx off tx off sg off tso off ufo off gso off gro off lro off to work around the problem. Disabling offload does in fact silence the messages (but also has the unfortunate side effect of dropping the MTU on boxes using jumbo frames) Given that that happens to quiet things down, figured it might help narrow down what patch or patches are responsible for a fix... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1195474 Title: xennet driver reports skb rides the rocket under moderate load To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-lts-raring/+bug/1195474/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1213247] [NEW] httpie requires requests 1.0, raring ships with 1.1.0
Public bug reported: httpie has a dependency on requests 0.10.1 but 1.0. Raring ships with requests 1.1.0. The httpie deb doesn't declare a dependency on any specific version of requests, so everything installs clean. # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=13.04 DISTRIB_CODENAME=raring DISTRIB_DESCRIPTION=Ubuntu 13.04 # apt-get install httpie Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: python-pygments Suggested packages: ttf-bitstream-vera The following NEW packages will be installed: httpie python-pygments 0 upgraded, 2 newly installed, 0 to remove and 15 not upgraded. Need to get 579 kB of archives. After this operation, 3,096 kB of additional disk space will be used. Do you want to continue [Y/n]? yes Get:1 http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ raring/main python-pygments all 1.6+dfsg-1 [529 kB] Get:2 http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ raring/universe httpie amd64 0.3.1-1 [49.2 kB] Fetched 579 kB in 0s (2,856 kB/s) Selecting previously unselected package python-pygments. (Reading database ... 77295 files and directories currently installed.) Unpacking python-pygments (from .../python-pygments_1.6+dfsg-1_all.deb) ... Selecting previously unselected package httpie. Unpacking httpie (from .../httpie_0.3.1-1_amd64.deb) ... Processing triggers for man-db ... Setting up python-pygments (1.6+dfsg-1) ... Setting up httpie (0.3.1-1) ... # http Traceback (most recent call last): File /usr/bin/http, line 5, in module from pkg_resources import load_entry_point File /usr/lib/python2.7/dist-packages/pkg_resources.py, line 2807, in module parse_requirements(__requires__), Environment() File /usr/lib/python2.7/dist-packages/pkg_resources.py, line 594, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: requests=0.10.1,1.0 ** Affects: httpie (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1213247 Title: httpie requires requests 1.0, raring ships with 1.1.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/httpie/+bug/1213247/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
