Lost Electricity - Now openSUSE Sometimes Does Not Boot?

Hi,

Been running openSUSE Tumbleweed KDE 64Bit
for 6+ months with zero issues.

The other day I lost electricity.
Now sometimes when I try to boot computer into openSUSE
it gets stuck after entering encrypted hard drive passphrase?

Any ideas?
Thanks in advance!

Jesse

Things I would try:

  • a forced filesystem(s) check
  • a BIOS reset
smartctl -t long /dev/<name>

<name> would be sda or nvme0n1 or whatever the device name for the installed TW is.

Your misfortune is highly unlikely to happen here, as I don’t use a PC that isn’t getting power from a UPS.

Hi,

I tried setting the BIOS to defaults, but no difference.

I then tried the command in konsole(KDE).
It exits immediately with below output:

My OS drive is an SSD if that makes any difference.

Any ideas?
Thanks.

Jesse

jlp@SortaFastDesktop:~> smartctl -t long /dev/sda 

Absolute path to 'smartctl' is '/usr/sbin/smartctl', so running it may require superuser privileges (eg. root). 
jlp@SortaFastDesktop:~> sudo smartctl -t long /dev/sda 
[sudo] password for root:  
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.8.15-1-default] (SUSE RPM) 
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org 

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === 
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode". 
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful. 
Testing has begun. 
Please wait 2 minutes for test to complete. 
Test will complete after Fri Oct 30 20:19:09 2020 EDT 
Use smartctl -X to abort test. 
jlp@SortaFastDesktop:~>

Just a note:

When the openSUSE Tumbleweed KDE 64Bit operating system does successfully boot,
I don’t see any problems with anything - OS, apps, games - no weird issues or crashes, etc.

Also: I don’t use UPS systems - If I have to I can swap out the 1TB SSD drive with another one(a monthly backup)

Jesse

After Fri Oct 30 20:19:09 2020 EDT do:

smartctl -x /dev/<name> > somefile.txt

and examine somefile.txt for failures and warnings using a text file viewer, or substitute “| less” for “> somefile.txt” for same purpose.

Note my posts here are suggestions, as losing electricity without a UPS thus resulting in hardware trouble hasn’t happened to me or mine to my recollection or knowledge since the first and only time it happened over 27 years ago.

A UPS protects hardware as well as data. When hardware failure occurs, it can deny access to data, sometimes permanently, as it did to me 27+ years ago.

Can you look at this post:
https://forums.opensuse.org/showthread.php/546604-How-Do-I-Run-A-Disk-Check-On-Main-OS-System-SSD-HDD

thanks!

Jesse

I can add nothing to its post #3. I don’t use BTRFS, or encryption.

You may want to check this page: SDB:BTRFS - openSUSE Wiki and come back if unsure.

BTW: I tried to break btrfs by resetting the machine or turning off the power supply during heavy disk activity to no avail. I presume your symptoms might be caused by shaky hardware.

Anyone who encrypts their disks should be doing daily backups because if the problem is serious enough that you can’t boot, you probably wouldn’t be able to recover.
If your disks weren’t damaged by your incident,
You can try using Snapper to rollback to before your incident, this will undo any changes since the rollback. Note that rollbacks are safe, when you do a rollback you always have to option to roll forward to any snapshot including your current status.

If the filesystem istself is damaged, I doubt this would halp.
If in the end you are unable to fix your problem properly, you should take steps to recover and preserve your latest data, and then re-install… and not encrypting your disks or partitions unless you have reason to do so.

I don’t know if you encrypted your disk(s) with any objective.
Encrypting your filesystem won’t protect you against malware or hacking when your system is running.
Encrypting your disk(s) is to protect your data if your machine is powered off and physically stolen.
Should someone successfully boot your system and provide the password or hack your system while you’re logged in, your encryption won’t protect you.

TSU