Feedback
Jamirais Bin Ismail
If it helps people, this is what I did on systems that automatically had
rebooted into the problematic kernel.
First, I uninstalled the 6.1.0-14 kernel and rebooted back into 6.1.0-13.
Then I used `last` to identify the time between the problematic reboot into
6.1.0-14 and the deliberate reboot
Would an fsck even be able to recognize corruption, if metadata were
unaffected? Without file checksumming, can it discern?
Online check of ext4:
If your filesystem is located on a logical volume (LVM) then I assume you
can make a snapshot and do a check of that.
Make SS:
lvcreate --snapshot --size 1G --name lv_root_SS --chunksize 4k
/dev/VG1/lv_root
EXT4 check:
e2fsck -f /dev/dm-3
Remove SS:
lvremove --yes VG1/lv_r
Will a file system check detect the corruptions?
Can it be done online?
Thank you.
As there were some questions along in this thread let me summarize
some points:
The issue affects fs/ext4 code, so no other filesystems are affected
(e.g. btrfs).
The issue affects all kernels which have the commit 91562895f803
("ext4: properly sync file size update after O_SYNC direct IO") from
Hi
Any new information, when will this be patched?
There are packages that can not be installed like nvidia-driver because
while installing it updates the system and the process fails.
Isn't possible to remove from the repo the corrupted kernel so that people
can install other packages?
Regards
On Mon, 11 Dec 2023 10:38:40 +0100 helios.sola...@gmx.ch wrote:
> I have been running debian 12.3 with kernel 6.1.64-1 for a few hours,
> how can I find out whether the file system has been corrupted?
yes, I would also appreciate an explanation who could be affected,
how to diagnose the problem, a
I have been running debian 12.3 with kernel 6.1.64-1 for a few hours,
how can I find out whether the file system has been corrupted?
Package: src:linux
Followup-For: Bug #1057843
FYI: there is a nice workaround to avoid upgrading to the affected kernel:
https://octodon.social/@alienghic/111554146479489358
===[ snip ]
This should block just the buggy kernel. Which might
Meanwhile, can the ftp admins pull this faulty version?
I just managed to download and install this, but fortunately didn't reboot
on all of my systems before coming across this bug via LWN via reddit.
If you're in such a pickle as myself, you're able to get around it for now
by:
apt install lin
Are there any guidelines for affected users who already updated before
they got the warning?
For example, is it fine to start with the previous kernel
6.1.0-13-amd64 (version 6.1.55-1) ?
Thanks
UmbertoZ.
On Sun, 10 Dec 2023 07:56:36 + Stephan =?ISO-8859-
1?Q?Verb=FCcheln?= wrote:
>
> - Is it safe to assume that other filesystems (like BTRFS) are not
> affected?
> - Does this cause filesystem corruption or only file corruption?
> - Does this affect metadata or only file contents?
> - Is there a
Are there any guidelines for affected users who already updated before
they got the warning?
Interesting questions for affected users:
- Is it safe to assume that other filesystems (like BTRFS) are not
affected?
- Does this cause filesystem corruption or only file corruption?
- Does this affect me
Your message dated Sat, 09 Dec 2023 17:56:32 +
with message-id
and subject line Bug#1057843: fixed in linux 6.1.66-1
has caused the Debian Bug report #1057843,
regarding linux: ext4 data corruption in 6.1.64-1
to be marked as done.
This means that you claim that the problem has been dealt
Hi,
On Sat, Dec 09, 2023 at 03:07:37PM +0100, Salvatore Bonaccorso wrote:
> Source: linux
> Version: 6.1.64-1
> Severity: grave
> Tags: upstream
> Justification: causes non-serious data loss
> X-Debbugs-Cc: debian-rele...@lists.debian.org, car...@debian.org,
> a...@debian.org
>
> Hi
>
> I'm fil
Running the single test with ext4:
# LTP_SINGLE_FS_TYPE=ext4 LTP_DEV_FS_TYPE=ext4 ./preadv03_64
tst_device.c:96: TINFO: Found free device 0 '/dev/loop0'
tst_test.c:1690: TINFO: LTP version: 20230929-194-g5c096b2cf
tst_test.c:1574: TINFO: Timeout per run is 0h 00m 30s
tst_supported_fs_types.c:149:
Processing commands for cont...@bugs.debian.org:
> forwarded 1057843
> https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuhc3@quack3/
Bug #1057843 [src:linux] linux: ext4 data corruption in 6.1.64-1
Set Bug forwarded-to-address to
'https://lore.kernel.org/stable/202
Source: linux
Version: 6.1.64-1
Severity: grave
Tags: upstream
Justification: causes non-serious data loss
X-Debbugs-Cc: debian-rele...@lists.debian.org, car...@debian.org,
a...@debian.org
Hi
I'm filling this for visibility.
There might be a ext4 data corruption issue with the kernel released
i
19 matches
Mail list logo