Re: Disk problems

Michael <[email protected]> Mon, 30 Mar 2026 11:15:23 +0100
Newsgroups	gmane.linux.gentoo.user
Message-ID	<2270781.Mh6RI2rZIc@rogueboard>
On Sunday, 29 March 2026 11:56:50 British Summer Time Dr Rainer Woitok 
wrote:
> Michael,
> 
> On Friday, 2026-03-27 16:32:14 +0000, you wrote:
> > ...
> > 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.
> Yes, the battery  is meanwhile ailing,  but that's why the laptop is
> al- ways connected to 240V AC while I'm using it.

OK, then my battery power collapse assumption doesn't stand.


> > The log should reveal if the hibernation process completed or not 
> > and what took place when the system restarted.
> 
> What log are you refering to?   "rc.log"?   I did not explicitly
> mention it in my first mail, but the whole story in file "rc.log" is
> this

/var/log/syslog, /var/log/messages, /var/log/kern.log

or, whichever your system has capturing kernel messages.  Or dmesg, if 
the error occurred in the current boot sequence.


>    ...
>     * Unmounting filesystems
>    ...
>     *   Unmounting /home ...
>     [ ok ]
>    ...
>    rc shutdown logging stopped at Fri Mar 20 19:06:47 2026

At least as far as openrc is concerned the system recorded a normal 
shutdown.


>    rc boot logging started at Sun Mar 22 09:23:36 2026
>    ...
>     * Checking local filesystems  ...
>    /dev/sda3: clean, 806257/6275072 files, 8962397/25077622 blocks
>    /dev/sdb1: recovering journal
>    /dev/sdb1: clean, 172745/61054976 files, 35513542/244190385 blocks
>     [ ok ]
>    ...

Hmm ... then we have the above fsck journal recovery exercise.  :-/


> > 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.
> 
>    # smartctl -t long /dev/sdb
[snip ...]

The above [snipped] SMART report looks healthier than most/all of my 
HDDs! Ha!


>    SATA Phy Event Counters (GP Log 0x11)
>    ID      Size     Value  Description
>    0x0009  2            4  Transition from drive PhyRdy to
> drive PhyNRdy 

A SATA command sent to the device returned 'device not ready'.

>    0x000a  2            2  Device-to-host register FISes sent due to a 
> COMRESET

And the registered FIS (Frame Information Structure) record is telling 
us a reset command was sent to the device by the host, following which 
the device ought to initialise, calibrate, wakeup, align and get read to 
exchange data.  I think the above record plus the rc.log sequence is 
pointing to a power supply glitch experienced during start up.


> Seen through my layman's eyes this seems ok, but I don't know what
> these data are telling somebody really familiar with SMART.  Comments
> welcome.
> 
> Sincerely,
>   Rainer

I am not an expert on storage devices, but if this were a desktop the 
fist thing I would do is to change or reseat the SATA cable.  Given this 
is a laptop I would still consider reseating its SATA connector and any 
ribbon cable if present.  If this is not an electrical conductivity 
problem at the connector, then the SATA controller chip on the MoBo has 
a problem supplying the correct voltage to start up the device.  It 
could happen because the 5V/12V rail VRM or some capacitor on its 
circuit has a fault and in this case I would expect for it to get 
progressively worse.  It ought to be repairable by a specialist shop 
with the necessary equipment and a steady hand, but a malfunctioning 
component which has not failed completely can be difficult to identify.  
Also, the repair cost may be higher than buying a used laptop off ebay.

BTW, I don't think  this is a PSU issue.  Whenever I had a laptop PSU 
dying, it went suddenly and irreversibly.  However, if you have a spare 
PSU you can try this too to eliminate it as a possibility.

Either way the next thing to do must be the oft recommended data backup!
signature.asc (application/pgp-signature, 870 B)