Hi,
I believe that I have been hit by this bug too.
What has happened for me is that the machine in question 'almost' locks
up, with a read-only /, and such that most commands to debug further never
complete due to waiting for filesystem action. It then requires a reboot.
'dmesg' has worked, and then shows ext4-related issues. However, they
were not recorded to /var/log. I generally do not find any corruption on
the filesystem itself when running fsck afterwards.
On the machine I have a number of chroot debian installations of different
releases. By pure chance I found that 'update-initramfs' was the trigger
for the system hangs. I could then repeatably trigger the issue again.
(Before this, it would happen as part of system maintenance (unattended
upgrades in the chroots), so just spuriously hang the machine.)
In my case, the chroot installations live on a ZFS filesystem. But the
host system itself is on (multiple; /, /usr/, /var/ ) MD raid1.
I have had /proc mounted in the chroots. But had forgotten /dev . After
mounting /dev (and /dev/pts) in the chroots, the issue has not happened
again.
The issue was when the host system ran Buster, I then upgraded to Bullseye
~2 weeks ago, hoping it would be resolved, but the issue was still present
after the upgrade. Only after that upgrade I found the update-initramfs
trigger.
I am running with sysvinit, both on host and chroots.
Currently, I do not have hands-on access to the system, so cannot inspect
or reboot it reliably. Should be able to do some further tests in a few
weeks.
Best regards,
Håkan
