On Sunday, 14 April 2024 19:41:41 BST Dr Rainer Woitok wrote: > Greetings, > > On Friday, 2024-01-05 18:46:09 +0100, I myself wrote: > > ... > > since a few month or so off and on my laptop fails to resume from hiber- > > nation due to the "dirty bit" being set on the ext4 "/home" partition. > > I was reading this flickering by on the screen, and it wasn't quite cor- > rect. Meanwhile I found this in my "openrc.log": > > fsck.fat 4.2 (2021-01-31) > There are differences between boot sector and its backup. > This is mostly harmless. Differences: (offset:original/backup) > 65:01/00 > Not automatically fixing this. > Dirty bit is set. Fs was not properly unmounted and some data may be > corrupt. Automatically removing dirty bit. > *** Filesystem was changed *** > Writing changes. > /dev/sda1: 368 files, 116600/258078 clusters
Why have you set your /boot to be mounted at boot?
You can run 'fsck.fat -v /dev/sda1' after you unmount it to remove the dirty
bit (if not already removed) and then change your fstab to 'noauto'. Just
remember to remount /boot before you make any changes to your boot manager/
kernels.
> /dev/sdb1: recovering journal
> /dev/sdb1: Clearing orphaned inode 54789026 (uid=1000, gid=1000,
> mode=0100600, size=32768) /dev/sdb1: Clearing orphaned inode 54788311
> (uid=1000, gid=1000, mode=0100600, size=553900) /dev/sdb1: clean,
> 172662/61054976 files, 36598898/244190385 blocks * Filesystems repaired
>
> So one cause always is some problem on disk "/dev/sda1/" ("/boot/") and
> another cause are one or more orphaned inodes on disk "/dev/sdb1/"
> ("/home/"). But while the values of offset, original and backup for
> "/dev/sda1/" are always the same when this happens, the number of or-
> phaned inodes on "/dev/sdb1/" and the inodes itself change from occur-
> rence to occurrence. Besides it only happens sporadically when resuming
> from hibernation, not every time. More precisely, the problem surfaces
> when resuming from hibernation but could as well be caused during the
> hibernation process itself.
>
> Does this ring some bell somewhere what could cause this?
>
> Sincerely,
> Rainer
Unlike the /boot partition, the /home partition has data written to it
regularly. The ext4 fs does not perform atomic writes - it is not a CoW fs.
Therefore a sudden unsync'ed shutdown could leave it in a state of corruption
- IF for some reason data in memory is not either fully written to disk or
retained in memory. The way ACPI interacts with firmware *should* ensure the
S3 system state does not suspend I/O operations halfway through an inline
write operation ... but ... MoBo firmware can be notoriously buggy and is
typically frozen/abandoned within a couple of years by the OEMs. In addition,
kernel code changes and any previous symbiosis with the firmware can fall
apart with a later kernel release.
On one PC of mine, with the same MoBo/CPU and the same version firmware, I
have over the years experienced a whole repertoire of random problems resuming
from suspend. At this point in time I avoid placing this PC in sleep, because
it always crashes with a Firefox related segfault, some time after waking up.
Check if the situation with /dev/sdb1 improves when you leave your /boot
unmounted. This may make more process time available for the system to finish
I/O operations, which may then allow /dev/sdb1 to suspend cleanly.
signature.asc
Description: This is a digitally signed message part.
