Public bug reported:
There was a long and complicated sequence of activities involving mdadm,
lvm, and specifically pvmove leading up to the point where the
corruption was discovered, but I suspect most were irrelevant. AFAICT,
the bug was triggered by the following simple operations:
* the FS
On 19/07/13 18:34, Joseph Salisbury wrote:
The commit(b0dd6b7) you mention in the upstrem bug report is in the 3.2
stable tree as commit 76f4fa4:
* 76f4fa4 - ext4: fix the free blocks calculation for ext3 file systems w/
uninit_bg (1 year, 1 month ago) Theodore Ts'o
It was available as of
Public bug reported:
Disks earlier prepared using mdadm(8) and lvm2; /boot is an md(4)
mirror, while /, /home and /var are lvm2 logical volumes. In the live
environment, I installed mdadm and lvm2 using apt-get, and started the
arrays (which also configured the volume group).
Then I started the
Public bug reported:
This appears to be the same as a bug reported on Debian
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697139 (same line of
code) but this report may provide extra information as the stack trace
is somewhat different and this is on a 64-bit architecture, whereas that
was on
My network was showing this (multiple) 5-second timeout problem. To test it, I
turned off DNS caching
# /etc/init.d/nscd stop
and then
# time curl -I www.google.co.uk
which consistently took more than 5 seconds.
I tried several of the approaches described above, and eventually determined
that
*** This bug is a duplicate of bug 733055 ***
https://bugs.launchpad.net/bugs/733055
Probably down to a change in Python 2.7. Up until 2.6, if you passed a
float to a function that was defined as taking an int, the float would
automatically be converted, though possibly with a
Probably down to a change in Python 2.7. Up until 2.6, if you passed a
float to a function that was defined as taking an int, the float would
automatically be converted, though possibly with a DeprecationWarnng. In
2.7 (and Python 3000) it's now a TypeError. So, you have to put in an
explicit
