Public bug reported:
A customer reported on all of their ext3 and none of their ext4 systems
that the file system was in read-only mode, I believe after rebooting
into 3.13.0-157.207 from 3.13.0-156.206. Here is the output of tune2fs
-l for one of the file systems:
tune2fs 1.42.12 (29-Aug-2014)
L
I noticed the unusual thing here is:
RAID stride: 128
RAID stripe width: 512
I'm going to do some testing around this to see if it's related. It
could be this is the issue and not anything EXT3 vs. EXT4.
--
You received this bug notification because you are a member of Kernel
Packages, which is
I confirmed that adding "-E stride=128,stripe_width=512" to the call to
mkfs results gets the following errors almost immediately at boot with
3.13.0-157.207:
[5.680480] EXT4-fs error (device xvda1): ext4_validate_block_bitmap:376:
comm mountall: bg 213: block 7007360: invalid block bitmap
[
I believe a command sequence like this can be used to reliably reproduce
the issue:
umount /mnt
truncate -s128m /tmp/test.img
cmd="/sbin/mkfs.ext3 -E stride=128,stripe_width=512 -F /tmp/test.img"
echo $cmd > /dev/kmsg
$cmd
mount -o loop /tmp/test.img /mnt/
while dd if=/dev/zero of=/mnt/$RANDOM bs=
As for running
apport-collect 1789131
This doesn't appear to work well in a headless system with a minimal
install. I believe I've given all the necessary details for reproducing
the issue.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notificati
This problem doesn't show up in 4.4.0-134-generic.
--
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/1789131
Title:
Probable regression with EXT3 file systems and CVE-2018-1093 patches
Sta
On 08/27/2018 11:16 AM, Joseph Salisbury wrote:
> The specific version to test is 3.13.0-158.
>
No, that doesn't fix it.
root@scratch2:~# uname -a
Linux scratch2 3.13.0-158-generic #208-Ubuntu SMP Fri Aug 24 17:07:38 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux
root@scratch2:~# dmesg | grep mount
[
On 08/27/2018 01:21 PM, Joseph Salisbury wrote:
> Does 3.13.0-157.207 exhibit the bug and 3.13.0-156.206 does not? If
> that is the case, we can perform a bisect to identify the offending
> commit.
That is correct.
--
You received this bug notification because you are a member of Kernel
Package
On 08/28/2018 09:49 AM, Joseph Salisbury wrote:
> This is probably the fix:
> 22be37acce25 ext4: fix bitmap position validation
>
> I built a test kernel with commit 22be37acce25. The test kernel can be
> downloaded from:
> http://kernel.ubuntu.com/~jsalisbury/lp1789131
>
> Can you test this ke
Are you sure SLAB vs. SLUB fixed this?
I have images built from October 13 and today (October 22) with
4.8.0-22-generic and 4.8.0-26-generic respectively. On a
4.8.0-22-generic boot there are 37 kworker threads, on 4.8.0-26-generic
there are 524 kworker threads. It could be that with enough reboot
Also: the 524 threads was with Xen PVM and two VCPUS. With one VCPU the
problem goes away. The run on 4.8.0-22-generic also had two VCPUs.
There is no problem with Xen HVM and 4.8.0-26-generic with either one or
two VCPUS.
--
You received this bug notification because you are a member of Kernel
Hi,
I am using 12.04 and that particular sequence appears to be expected
behavior due to duplicate address detection in ipv6 leading to the ipv6
address being tentative. I see similar behavior on an ethernet port
which has never physically been connected to anything.
Before attaching anything to
12 matches
Mail list logo
