I'd like to follow up because the issue seems to have cleared up for us
after installing linux 5.0.1 about 40 days ago. It's hard to say whether
everyone is experiencing the same bugs, but give 5.x a shot and let us
know how it goes!
Just to recap. Every week or so we were seeing R/O file
** Tags added: cscc
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-lts-utopic in Ubuntu.
https://bugs.launchpad.net/bugs/1423672
Title:
ext4_mb_generate_buddy:756: group N, block bitmap and bg descriptor
inconsistent: X vs Y
Launchpad has imported 7 comments from the remote bug at
https://bugzilla.kernel.org/show_bug.cgi?id=104571.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
Unfortunately the symptom still persists on bionic (Ubuntu 18.04.1 LTS)
with kernel 4.15.0-43-generic. This issue may be a symptom that's caused
by lice and fleas. I updated
https://bugzilla.kernel.org/show_bug.cgi?id=104571 by adding a comment
with additional information.
--
You received this
Chenyuchai, yes,
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?h=7dec5603b6b8dc4c3e1c65d318bd2a5a8c62a424
is the fix. It was integrated in the Trusty kernel 3.13.0-87.133
--
You received this bug notification because you are a member of Kernel
Packages, which is
Hi，all:
I need your confirmation.Is the Fix:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?h=7dec5603b6b8dc4c3e1c65d318bd2a5a8c62a424
to solve this issue?If not,pls show the patch,thank you very much!
--
You received this bug notification because you are a member of
** Tags removed: verification-needed-trusty
** Tags added: verification-done-trusty
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-lts-utopic in Ubuntu.
https://bugs.launchpad.net/bugs/1423672
Title:
ext4_mb_generate_buddy:756:
** Changed in: linux (Debian)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-lts-utopic in Ubuntu.
https://bugs.launchpad.net/bugs/1423672
Title:
ext4_mb_generate_buddy:756: group N,
This bug was fixed in the package linux-lts-utopic -
3.16.0-73.95~14.04.1
---
linux-lts-utopic (3.16.0-73.95~14.04.1) trusty; urgency=low
[ Kamal Mostafa ]
* CVE-2016-1583 (LP: #1588871)
- ecryptfs: fix handling of directory opening
- SAUCE: proc: prevent stacking
This bug was fixed in the package linux - 3.13.0-87.133
---
linux (3.13.0-87.133) trusty; urgency=low
[ Kamal Mostafa ]
* Release Tracking Bug
- LP: #1585315
[ Upstream Kernel Changes ]
* Revert "usb: hub: do not clear BOS field during reset device"
- LP: #1582864
This bug was fixed in the package linux - 3.13.0-87.133
---
linux (3.13.0-87.133) trusty; urgency=low
[ Kamal Mostafa ]
* Release Tracking Bug
- LP: #1585315
[ Upstream Kernel Changes ]
* Revert "usb: hub: do not clear BOS field during reset device"
- LP: #1582864
Louie, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818502#22
provides a simple way to reproduce. If you could give it a try that
would be appreciated.
FYI, when my hypervisor was running Trusty (3.13), the problem was
reproducible on fresh VMs with brand new ext4 FSes, so hopefully that
I have a "PE 2950III Intel(R) Xeon(R) CPU X5460 @ 3.16GHz" server here
and I've been trying to test this out. I'm using an "rsync" copy of an
original server exhibiting the problem. So far though I've been unable
to reproduce the original error at all.
It would seem that using the exact same
Anyone affected by this issue: We're looking for a positive
verification that the Trusty kernel version currently available in
-proposed (3.13.0-87.132) fixes this problem. If you can provide that
confirmation, please do!
--
You received this bug notification because you are a member of Kernel
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
trusty' to 'verification-done-trusty'.
If verification is not done by 5 working days from
I recently reinstalled the affected host to run Xenial so I can no
longer test the proposed fix for the 3.13 kernel.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-lts-utopic in Ubuntu.
https://bugs.launchpad.net/bugs/1423672
** Changed in: linux (Ubuntu Trusty)
Status: Confirmed => Fix Committed
** Changed in: linux-lts-utopic (Ubuntu Trusty)
Status: New => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-lts-utopic in
Additional positive test result notes:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818502#27
https://bugzilla.kernel.org/show_bug.cgi?id=102731#c43
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-lts-utopic in Ubuntu.
** Description changed:
+ SRU Justification:
+
+ Impact: Users of VMs running 3.13/3.16 and ext4 can experience data
corruption in the guest.
+ Fix:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?h=7dec5603b6b8dc4c3e1c65d318bd2a5a8c62a424
+ Testcase:
** Changed in: linux (Ubuntu Trusty)
Assignee: (unassigned) => Chris J Arges (arges)
** Changed in: linux-lts-utopic (Ubuntu Trusty)
Assignee: (unassigned) => Chris J Arges (arges)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed
Thanks Chris. So far, no regression with the Trusty kernel:
$ uname -a
Linux xeon 3.13.0-86-generic #130~lp1423672v201604200743 SMP Wed Apr 20
12:44:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Since the issue only happens rarely, more people testing it would be
welcome.
--
You received this
Leo,
Also uploaded a lts-utopic build here:
http://people.canonical.com/~arges/lp1423672/
It will all debs with '3.16' in the name.
** Also affects: linux-lts-utopic (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux-lts-utopic (Ubuntu)
Status: New => Invalid
--
Hi Chris,
This is also seen on kernel 3.16.0-51-generic. Could you get us a kernel
build test for 3.16 as well ?
Thank you
Leo
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1423672
Here's a test build for trusty 3.13 with
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?h=7dec5603b6b8dc4c3e1c65d318bd2a5a8c62a424
applied:
http://people.canonical.com/~arges/lp1423672/
Can someone verify this does fix the issue so this can be SRU'ed into
3.13?
--
You
Good work.
We also have PE2950III systems running "Intel(R) Xeon(R) CPU X5460 @
3.16GHz".
If this is indeed the fix, I'm confused why it would only affect certain cpus?
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?h=7dec5603b6b8dc4c3e1c65d318bd2a5a8c62a424
I'll have
Here we have this problem on two servers runnning "Intel(R) Xeon(R) CPU
X5460 @ 3.16GHz" (and debian 7.0 backport kernel 3.16 on host, 4.x on
VM). We doesn't seems to have this problem on others nodes runnning:
Intel(R) Xeon(R) CPU E5345 @ 2.33GHz
Intel(R) Xeon(R) CPU5160
Thanks Václav, your conclusion about older Intel CPU seems to match my
setup since this only happens on a Xeon E3110 (which is in fact a re-
branded Core2 Duo E8400).
Thanks for bisecting this and figure the fix was:
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1423672
Title:
ext4_mb_generate_buddy:756: group N, block bitmap and
This bug is probably what I describe in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818502
Bug in Debian 3.16 kernel (kernel from current stable Jessie) used as
KVM hypervisor on older Intel CPU.
** Bug watch added: Debian Bug tracker #818502
I am able to reproduce this bug every single time I suspend and then
resume one of my laptops. Which is running xubun tu 15.10 with
4.2.0-16-generic kernel on a lenovo R400. I suspect possible a hardware
problem as this only happens on 1 out of 3 R400 that I have. I'll report
back if I remember.
FYI, the same errors happened to me on real hardware (a Raspberry Pi 2
B), based on a custom Debian Jessie image.
The image uses a ext2 filesystem created on a x86 Boot2docker host
(Kernel "Linux fbd0c1340061 4.1.12-boot2docker #1 SMP Tue Nov 3 06:03:36
UTC 2015 x86_64 GNU/Linux").
While
chris,
Here is what you asked for, sorry for not getting it earlier.
I don't use virsh. This is how I started KVM to trigger the problem
interactively (curses interface):
kvm -drive
file=/dev/raid/shared,media=disk,if=none,cache=none,aio=native,format=raw,id=hd0
-device virtio-blk-pci,drive=hd0
Oops...the above kvm command line is correct but it did not crash with -m 1000,
that's what production is using now.
It was crashing consistently with -m 512 about a minute into the synthetic FS
load.
--
You received this bug notification because you are a member of Kernel
Packages, which is
** Changed in: linux (Debian)
Status: Unknown => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1423672
Title:
ext4_mb_generate_buddy:756: group N, block bitmap and bg
** Bug watch added: Debian Bug tracker #772848
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772848
** Changed in: linux (Debian)
Importance: Undecided => Unknown
** Changed in: linux (Debian)
Status: New => Unknown
** Changed in: linux (Debian)
Remote watch: None => Debian Bug
Looks like there are some more LKBT issues for this one:
https://bugzilla.kernel.org/show_bug.cgi?id=102731
https://bugzilla.kernel.org/show_bug.cgi?id=89621
** Bug watch added: Linux Kernel Bug Tracker #102731
http://bugzilla.kernel.org/show_bug.cgi?id=102731
** Bug watch added: Linux
I'm running LoCo mirror for my country and this affects our file server for
over a week already.
All our official file services got offline now.
We're also providing free VM/Hosting for OpenSource projects, I can't image how
the disaster will become.
Any suggestion?
All VMs are VMware guest.
Am 29.10.15 um 03:29 schrieb LouieGosselin:
> I'm posting again to add that I conducted some more tests and ext3 does
> not encounter corruption under the same conditions. I hope this
> information is helpful to others, if anyone needs more information let
> me know and I'll see what I can do.
Louie,
Can you post some additional information that may help in debugging this issue.
1) Can you post the output of 'virsh dumpxml ' of the affected VM?
2) Can you post the /boot/config-`uname -r` of the affected VM's kernel?
3) What type of partitioning layout does your VM have?
It seems that
It's happened again. I've spent several hours on this and I've been able
to recreate the failure under some synthetic conditions with a
sacrificial VM.
The filebench defaults do not cause an ext4 crash for me, but the
following do:
load workloads/fileserver
set $dir=/tmp/
set $nfiles=20
set
I'm posting again to add that I conducted some more tests and ext3 does
not encounter corruption under the same conditions. I hope this
information is helpful to others, if anyone needs more information let
me know and I'll see what I can do. I'll probably switch my own VMs to
ext3 so I don't have
On 10/13/2015 06:00 PW, Simon Déziel wrote:
> On 10/13/2015 11:50 AM, Jan Wagner wrote:
>> I'm trying now '"cache=none"' for this VM and see how that turns out.
>
> FYI, all my VMs use cache=none and have small HDDs (lv of 2-4G) yet the
> regularly trip on this bug.
looks like this didn't fixed
It happened here again.
8/24 ext4 corruption
9/14 ext4 corruption
9/29 update/reboot
10/16 ext4 corruption
This time the corruption was severe. 1743 files from multiple directories got
moved into lost+found.
It took me almost 2 hours this morning to verify & fix everything. Fortunately
every
I got also hit with the problem on Debian Jessie VM [virtio] (KVM host
is Jessie as well).
The following bug might be related:
https://bugzilla.kernel.org/show_bug.cgi?id=104571
I'm trying now '"cache=none"' for this VM and see how that turns out.
** Bug watch added: Linux Kernel Bug Tracker
On 10/13/2015 11:50 AM, Jan Wagner wrote:
> I got also hit with the problem on Debian Jessie VM [virtio] (KVM host
> is Jessie as well).
>
> The following bug might be related:
> https://bugzilla.kernel.org/show_bug.cgi?id=104571
>
> I'm trying now '"cache=none"' for this VM and see how that
Adding memory did not helps, but it seems to have fixed the issue by
just removing the fstab option errors=remount-ro on the mountpoints
having problems. It's usually only set on root fs and we have no problem
on root fs, but by mistake this option was added to other mountpoints
and triggered the
I'm getting this same issue every day
3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u4 x86_64 GNU/Linux
Guest is running under proxmox 3.4 virtio
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
** Also affects: linux (Debian)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1423672
Title:
ext4_mb_generate_buddy:756: group N, block
Same problem here on 2 VMs, appeared 4 times in one week.
VMs are running Debian Jessie, on Debian wheezy hypervisors running ceph
giant, libvirt 1.2.9-9~bpo70+1, qemu 1:2.1+dfsg-12~bpo70+1.
FS is ext4, using virtio and rbd with writeback.
After first crash we upgraded kernel to 4.1.6-1~bpo8+1.
We have the same error on a 14.04 VM running on a XenServer 6.2
(paravirtualized).
EXT4-fs error (device dm-1): ext4_mb_generate_buddy:756: group 36, block
bitmap and bg descriptor inconsistent: 30504 vs 30149 free clusters
Linux xxx 3.13.0-63-generic #103-Ubuntu SMP Fri Aug 14 21:42:59 UTC 2015
Same error, on a single VM, virtio driver, ext4:
EXT4-fs (vda1): pa 880010c3daf8: logic 512, pyhs. 6750208, len 512
EXT4-fs error (device vda1): ext4_mb_release_inode_pa:3773: group 206, free
143, pa_free 142
Aborting journal on device vda1-8
Disk quota active
No memory error (checked)
No
I'm on Debian, but it's happening to me as well.
KVM with virtual disks backed by LVM volumes on the host.
Both the VM and the host are running
Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)
Same error, virtual machine 14.04 running on kvm, server 14.04.
No hardware issue, the entire server was replaced after the second stop.
No hard disk issue, the server is on raid hardware disk.
The server is running more than one virtual server, only one affected.
--
You received this bug
I'm having this exact issue with Debian Jessie. Virtual machines running
with LVM storage unpredictably failing after cron.daily.
[680406.357587] EXT4-fs error (device vda1): ext4_mb_generate_buddy:757: group
49, block bitmap and bg descriptor inconsistent: 18356 vs 18355 free clusters
Seems we are also confronted with this error in one of our VMWare guests:
[45780.021968] EXT4-fs error (device dm-9): ext4_mb_generate_buddy:756: group
1411, block bitmap and bg descriptor inconsistent: 32757 vs 32768 free clusters
[45780.022029] Aborting journal on device dm-9-8.
[45780.055657]
And yet again:
root@rproxy:~# dmesg -T | tail
[Thu Jun 11 15:28:56 2015] type=1400 audit(1434050938.364:24):
apparmor=STATUS operation=profile_replace profile=unconfined name=nc
pid=658 comm=apparmor_parser
[Thu Jun 11 15:28:59 2015] init: plymouth-upstart-bridge main process ended,
respawning
56 matches
Mail list logo
