Re: Disk problems

Michael <[email protected]> Fri, 27 Mar 2026 16:32:14 +0000
Newsgroups	gmane.linux.gentoo.user
Message-ID	<1927531.atdPhlSkOF@rogueboard>
On Friday, 27 March 2026 15:30:08 Greenwich Mean Time Dr Rainer Woitok 
wrote:
> Gretings,
> 
> on my almost  ten years old laptop  device "/dev/sdb1" refers  to a
> disk `SATAIII 1 TB HDD HGST/WD / 7.200 rpm / 2,5"´ to be mounted at
> "/home/". I wasn't aware  of any problems,  but now it sometimes
> happens that waking-up the system after hibernation turns into a
> normal boot because the file system check  for this device fails, 
> causing file  "openrc.log" to contain:
> 
>     * Checking local filesystems  ...
>    /dev/sda3: clean, 806263/6275072 files, 8962535/25077622 blocks
>    /dev/sdb1: recovering journal
>    /dev/sdb1: clean, 173412/61054976 files, 35603500/244190385 blocks
> 
> Any advice where to look for what in order to hunt this down?
> 
> Sincerely,
>   Rainer

The message saying "... recovering journal" indicates the metadata on 
the disk does not match the files eventually written on it.  Otherwise 
you'd see a message similar to /dev/sda3.

It seems the last time your system wrote data on the /dev/sdb1 
filesystem the data was not fully committed and the write command did 
not complete.  When you (re)boot the fsck discovered this inconsistency 
and rolled back to the last completed journal entry.

Here's some assumptions as to what could be happening:

When hibernation happens normally, this problem should not occur.  All 
data should be committed to disk fully, caches flushed and the system 
will then shut down normally.

If hibernation happens because/while the laptop is running out of 
battery power, then the battery could run out and the PC come to a halt 
before the hibernation has completed successfully.  This will leave your 
fs in an inconsistent state.  This is what I suspect is happening.  The 
log should reveal if the hibernation process completed or not and what 
took place when the system restarted.  You should be able to work around 
a weak battery by changing the desktop power settings to commence 
hibernation before the battery level is too low.

Either way, it is worth running 'smartctl -t long /dev/sdb' to see if 
the disk is healthy, or there is an underlying hardware fault causing 
the inconsistency in data commits.
signature.asc (application/pgp-signature, 870 B)