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.