Hi, As some of you may recognize, I have been calling on the fine gurus that lurk on this newsgroup for help with issues that come up with my attempts to upgrade/install OpenSuSE15.4 on one of my systems. I was in the middle of doing some detective work on a problem I am having, when the computer I was working on, froze up and forced me to reboot the system. Upon rebooting, the system decided to run a file system check on one of my drives. Unfortunately, this file system check has now been running for over 3 days and the message on the screen only shows 2 bits of information, one the UUID of the disk drive being checked, and second, the amount of time that has passed since the file system check started. Both of these tidbits of information are rather useless IMHO. Without stopping the check I have no idea which drive corresponds to that UUID and would need something like the YaST partitioner on a Live USB stick to identify which drive it is (by comparing disk labels, names of partitions, disk sizes, with UUIDs). But that is not my main concern, the other really important bit of info needed is an estimate of how long it will take to complete the file system check! I have 6 drives on this system (mostly used for backing up other systems on my SOHO network) and these drives range in size from 500Gb to 8Tb. My conundrum is this - do I continue to wait for the file system check to complete, not knowing how much longer it will take, or do I bag it, put in a new drive and install a new OpenSuSE 15.4 system? If I install a new OS on a new drive, I could get my backup services and other services I need running on this system, back up and running in 2 to 5 days (based on my previous experiences with installing a new system). I could then also run the file system check on the drive, which apparently has a problem, as a background task. Any suggestions on how to proceed or make a choice? Since this missed/needed user requirement, that of providing an estimated time till completion for doing file system checks, is a new feature request now, would it be worth it to submit a bug report (knowing from past experience that bug fixes and feature updates often take years to resolve) or is this simply some unmaintained old low-priority software that no one really supports anymore? As always, an educated guess will be much appreciated, I don't have the kind of experience with the file system checking software, or understand what it does exactly, to make a good guess myself. Is it safe to abort, by reboot or power cycle, a file system check that is in process? Marc... -- *"The Truth is out there" - Spooky* *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed and the OpenPGP electronic signature is added as an attachment. If you know how, you can use my public key to prove this email indeed came from me and has not been modified in transit. My public key, which can be used for sending encrypted email to me also, can be found at - https://keys.openpgp.org/search?q=marc@marcchamberlin.com or just ask me for it and I will send it to you as an attachment. If you don't understand all this geek speak, no worries, just ignore this explanation and ignore the OpenPGP signature key attached to this email (it will look like gibberish if you open it) and/or ask me to explain it further if you like./)
On 2022-08-09 07:40, Marc Chamberlin wrote:
Hi, As some of you may recognize, I have been calling on the fine gurus that lurk on this newsgroup for help with issues that come up with my attempts to upgrade/install OpenSuSE15.4 on one of my systems. I was in the middle of doing some detective work on a problem I am having, when the computer I was working on, froze up and forced me to reboot the system. Upon rebooting, the system decided to run a file system check on one of my drives. Unfortunately, this file system check has now been running for over 3 days and the message on the screen only shows 2 bits of information, one the UUID of the disk drive being checked, and second, the amount of time that has passed since the file system check started. Both of these tidbits of information are rather useless IMHO. Without stopping the check I have no idea which drive corresponds to that UUID and would need something like the YaST partitioner on a Live USB stick to identify which drive it is (by comparing disk labels, names of partitions, disk sizes, with UUIDs).
You might get access to the error console, tty10. When a filesystem check takes that long, it usually means that the hard disk has hardware errors. Each bad sector is tried something like 5 or 10 times, an operation that can take a minute. If there are thousands of errors, then it takes days, and there is no purpose in that check. The only remedy is buy a new disk and try to salvage the contents with rsync (if disk is mountable) or ddrescue or dd_rescue. Running the smartctl short test should confirm this diagnosis. The long test would take too long. Yes, you should reboot the machine to a live rescue media instead, and run the testing from there. Do not wait. Waiting on a bad disk makes it worse, reducing the chances of recovering the data. It can get worse by the hour. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
participants (2)
-
Carlos E. R.
-
Marc Chamberlin