Control: reassign -1 src:linux
Control: tag -1 moreinfo
On Tue, 2020-07-07 at 17:30 -0700, Sarah Newman wrote:
> Package: linux-signed-amd64
> Version: 4.19.0-9-amd64
>
> We've had two separate reports now of debian buster users running
> 4.19.0-9-amd64 who experienced serious file system corruption.
Which version? (I.e. what does "uname -v" or
"dpkg -s linux-image-4.19.0-9-amd64" say?)
> - Both were using ext3
> - Both are running Xen HVM, but I do not have reason to believe this to be related
I have no reason to assume that this is unrelated to the hypervisor, so
please report the version of Xen and whatever provides the back-end
block driver.
> - Both are on distinct physical hosts
> - Both had upgraded from an older non 4.19 kernel within the last two or three weeks
From which older versions?
> One user had the error:
>
> ext4-fs error (device xvda1): ext4_validate_block_bitmap:393: comm cat: bg 812: block 26607617: invalid block bitmap
> aborting journal on device xvda1-8
> ext4-fs error (device xvda1): ext4_journal_check_start:61: Detected abnormal journal
> ext4-fs (xvda1): Remounting filesystem read-only
> ext4-fs (xvda1): Remounting filesystem read-only
> ext4-fs error (device xvda1) in ext4_orphan_add:2863: Journal has aborted
And were there any other error messages, e.g. relating to I/O errors,
around the same time? How about in the back-end domain?
> The other gave us the output of tune2fs -l:
[...]
Looks like a fairly ordinary ext3 filesystem. It doesn't tell us
anything about what went wrong.
In general I would advise against continued use of the ext3 format. It
should continue to be supported by the ext4 code, but it is inevitably
going to be less well-tested than the ext4 format. So far as I can
remember, it is easy to upgrade in-place.
Ben.
--
Ben Hutchings
The most exhausting thing in life is being insincere.
- Anne Morrow Lindberg
Attachment:
signature.asc
Description: This is a digitally signed message part