@xavpaice Is anyone else with the problem also using isdct (Intel® SSD
Data Center Tool for NVMe)? I have not had the problem since disabling
it from running regularly. I was using it to check the wear level on
regular intervals before.
And the reason I thought of that was that finally one time I
@jsalisbury I have tested some vanilla kernels 4.13.x that have the same
problem. See my paste here which seems like the exact same problem,
which I pasted in reply to someone else's with similar/same problem
https://gist.github.com/anonymous/d1cfe9ef5ebef0f96bb8d9ac451140f0
But since 4.13.11 (als
tested again with a better serial console setup, and here's the text
version like that screenshot:
[ 744.779536] Kernel panic - not syncing: stack-protector: Kernel stack is
corrupted in: c00d3ccc
[ 744.779536]
[ 744.780013] CPU: 0 PID: 5087 Comm: grep Not tainted 4.4.0-97-generic
#1
Problem still exists on 4.4.0-97-generic. And in my attempt to reproduce
it on a VM, I got a corrupt kernel instead, which sounds worse (could
create some persistent damage, not just a hang).
Attached are the 3 scripts to reproduce the corrupt kernel, and an extra
one to attach if the first failed
** Attachment added: "2017-11-13 bcachecrash kernel panic
Screenshot_20171113_093118.png"
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1724173/+attachment/5008127/+files/2017-11-13%20bcachecrash%20kernel%20panic%20Screenshot_20171113_093118.png
--
You received this bug not
** Description changed:
I am using Ubuntu 14.04 (trusty) with the 4.4.x xenial kernel (the
trusty kernel is way easier to make bcache crash). I have mdadm raid1 on
/boot and /, backed by 2 SSDs.
I have XFS on 12 ceph directories (/var/lib/ceph/osd/ceph-*), which is
backed by bcache, w
** Attachment added: "the latest crash, with the bcache on NVMe not shared by
mdadm or the OS"
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1724173/+attachment/4973409/+files/2017-10-17-ceph4.kmsg.gz
--
You received this bug notification because you are a member of Ubuntu
Public bug reported:
I am using Ubuntu 14.04 (trusty) with the 4.4.x xenial kernel (the
trusty kernel is way easier to make bcache crash). I have mdadm raid1 on
/boot and /, backed by 2 SSDs.
I have XFS on 12 ceph directories (/var/lib/ceph/osd/ceph-*), which is
backed by bcache, which is backed
** Attachment added: "2017-07-08-ceph5.kmsg.gz"
https://bugs.launchpad.net/ubuntu/+source/linux-lts-xenial/+bug/1724173/+attachment/4973408/+files/2017-07-08-ceph5.kmsg.gz
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bug
You probably shouldn't be using bcache on kernels without this patch
set: https://lkml.org/lkml/2015/12/22/154
That patch set is in the Ubuntu xenial kernel 4.4, and also vanilla 4.9.
You can install it on 14.04 with: `apt-get install linux-image-generic-
lts-xenial`
--
You received this bug not
seems to work so I'll just close this
# mkpasswd
The program 'mkpasswd' is currently not installed. You can install it by typing:
apt install whois
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.2 LTS
Release:16.04
Codename: xenia
oh and it seems if I "unregister" instead of "stop" on the 3rd line in
my script, the problem is gone for kernel 4.4.0-51-generic. But kernel
3.13.0-103-generic still dies the same.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
I get the same problem with kernel 3.13.0-103-generic on Ubuntu 14.04.5
I can reproduce it easily with this script (ssd1 is a volume group, and
sdb is a whole disk that already has bcache with writeback enabled).
(
csetuuid=$(bcache-super-show /dev/ssd1/bcache_sdb | awk '$1 == "cset.uuid"
{prin
btw, not sure why I was using 3.13.0-32 before... I also tested it with
the latest, with same result
# uname -a
Linux apparmortest 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
# tail -f /var/log/audit.log
[...]
type=AVC msg=audit(1455628235.420:56
# apport-collect 1545776
ERROR: You need to use apport-collect for updating an existing bug
Seems highly broken.
And apport-bug refused to work too, except running on the other kernel.
And it collects too much info. So I deleted lots of it; see it attached.
** Attachment added: "apport-bug outp
Public bug reported:
Ubuntu 14.04's kernel (tested 3.13.0-32-generic) does not log exec
properly in audit.log when in complain mode, so aa-logprof will not
work.
Here is test.bash
-
#!/bin/bash
echo "hi"
ls /tmp
find /tmp
-
Here is /etc/apparmor.d/root.tmp.test.bash (whi
@cboltz, I believe it was only running /bin/dash which was running
/usr/bin/rrdtool, in addition to what is already in the profile. The
following addition to the usr.sbin.apache2 profile made it work fine:
profile /bin/dash {
#include
#include
#include
/bin/dash mr,
/tmp/
And here's another fun result. I don't know why it did this. It created
43,000 lines of /usr/sbin/apache2//null-... stuff in the aa-status.
** Attachment added: "aa-status-4M.txt.gz"
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1394612/+attachment/4264398/+files/aa-status-4M.txt.gz
Public bug reported:
The version of apparmor-utils in Ubuntu 14.04 are completely unusable.
(2.8.95~2430-0ubuntu5)
jjohansen on IRC has provided me with this repo instead, which works far
better (2.8.98-0ubuntu2+utopic.backport). So I suggest you review this
or whatever process is normally used,
Public bug reported:
Here's the log:
Jun 12 15:42:42 node73 kernel: [17196.908781] [ cut
here]
Jun 12 15:42:42 node73 kernel: [17196.909789] kernel BUG
at/build/buildd/linux-3.13.0/mm/memory.c:3756!
Jun 12 15:42:42 node73 kernel: [17196.911210] invalid opcode: [#1]
*** This bug is a duplicate of bug 1324558 ***
https://bugs.launchpad.net/bugs/1324558
FYI: for working udev rules...
An example from above:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="ac:16:2d:9b:07:4f", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="p3p4"
Public bug reported:
I don't really care which package it is in, but you should probably make
the package suggestions include it.
# mkpasswd
or
# /usr/lib/command-not-found mkpasswd
No command 'mkpasswd' found, did you mean:
Command 'kpasswd' from package 'heimdal-clients' (universe)
Command 'k
Minor note about point 3 above:
Unlike what I used for the above message, yesterday I used a netboot to
install, and it would warn with a dialog if there was no bios_grub
partition (because that option is apparently not supported in kickstart;
but it works with preseed). Both were Ubuntu 12.04. My
Public bug reported:
I have many onboard dual port servers. In the BIOS, in netboot settings,
and OS I boot on these machines clearly shows the left port as the first
port (eg eth0 in Linux, igb0 in FreeBSD).
The root cause of my problem:
However, when using the PXE netboot Ubuntu installer, the
** Description changed:
https://help.ubuntu.com/12.04/serverguide/advanced-installation.html
The above page is missing three very important details.
1. /boot must be raid1, since it is apparently the only way to successfully
boot degraded. I tested raid10, which boots until you pull
Public bug reported:
https://help.ubuntu.com/12.04/serverguide/advanced-installation.html
The above page is missing three very important details.
1. /boot must be raid1, since it is apparently the only way to successfully
boot degraded. I tested raid10, which boots until you pull any disk, and
Update: It works 100% in openSUSE 12.1, but spews these messages
constantly:
Apr 5 14:51:32 linux-z66y kernel: [ 5399.002383] xhci_hcd :0a:00.0: WARN:
Stalled endpoint
Apr 5 14:51:34 linux-z66y kernel: [ 5400.537743] xhci_hcd :0a:00.0: WARN:
Stalled endpoint
Apr 5 14:51:34 linux-z66y
This still happens in kubuntu 11.10, which I just dist upgraded today.
(and kubuntu 10.something that I had before today)
It does not happen when I plug my USB 2.0 mouse in the USB 3.0 port. It
does not happen when I plug in a small port-powered USB 3.0 hard disk
into the USB 3.0 port (which I the
I had this problem today. For me, Dolphin was also taking 100% CPU. I
killed the 3 processes, and the problem is gone (without having to log
out and back in).
Last week I had a similar problem, when I put a USB stick in the
computer and it started going unusably slow. I had to kill many kde
proces
I confirm that it is very fast downloading files (less than a second each), but
when a file does not exist on the remote server, it takes at least one second
per file. This results in about 1-2 minutes wasted. Certainly that is not huge
in absolute terms, but in relative terms that is 96% overhe
30 matches
Mail list logo
