Welcome!
Important information
-- Spectre and Meltdown vulnerabilities
-- Change in MX sources

News
-- MX Linux on social media: here
-- Mepis support still here

Current releases
-- MX-17.1 Final release info here
-- antiX-17 release info here

New users
-- Please read this first, and don't forget to add system and hardware information to posts!
-- Here are the Forum Rules

Corrupted main partition saved by MX Live

Help for Current Versions of MX
Post Reply
Message
Author
agrendel
Forum Novice
Forum  Novice
Posts: 10
Joined: Fri May 18, 2018 3:23 pm

Corrupted main partition saved by MX Live

#1 Post by agrendel » Tue Nov 06, 2018 9:18 am

Just a word of thanks to all who contribute to making MX-Linux such a an easy system to work with for relative amateurs like myself. Thanks to a live USB thumb drive created by mx-live-usb-maker using an installation I performed for a non-savvy friend needing a reliable PC, I was easy to repair his hard drive which had stopped at an initramfs console with the message that there was an inconsistency in inode count. Apparently the friend had pulled the plug one time too many when he couldn't get a clean shutdown and I imagine this was the cause of the inconsistency. In any case a few passes of fsck started from a restart using the live USB fixed the problem. I checked with testdisk to make sure the partition geometry was correct and there were no other problems.
I gave my friend stern advice not to pull the plug on his computer if it got stuck. My guess is that it was too many windows open in Firefox and he'd run out of memory and couldn't close it. So I showed him the good old Ctrl-Alt-Backspace to kill his user session if things were really stuck and tried the long-press on the power button of his cpu tower to see if the problem might re-occur, but much to my surprise MX-Linux went straight into a normal shutdown procedure. I don't know if this is a feature of the uefi bios as most older CPUs I've dealt with before just switch off immediately.
One useful tip I discovered when refreshing my knowledge of how fsck worked was the use of the -A and -M parameters. In my case I didn't need to know the source of the corruption since the last message of initramfs pointed me to the right partition and I was using the live USB, but using fsck -AM apparently avoids the risk of trying to correct an already mounted partition. Might be of use perhaps to other amateur users who try to repair a corrupt partition?
MX 17.1_x64 Horizon: Thinkpad X220, Core i5-2540M, 8GB RAM Kernel 4.15.0-1-amd64

User avatar
fehlix
Forum Guide
Forum Guide
Posts: 2064
Joined: Wed Apr 11, 2018 5:09 pm

Re: Corrupted main partition saved by MX Live

#2 Post by fehlix » Tue Nov 06, 2018 9:58 am

Very good advices.
In additon to Ctrl-Alt-Backspace, and if the system is not responding
you shall try to turn down the system using the R-E-I-S-U-O method,
which make sure, filesystem get properly closed and cache synced to the disk.
Only in case if that doesnt help pressing the power button as a last resort.

REISUO - emergency shutdown:
Press and hold : left Alt-key and SysRq-key (which is the "Print Screen" key)
and type pres slowly R E I S U O ( i.e. press each key once: R-key, E-key, I-key etc.)

REISUB - emergency reboot:
Press and hold : left Alt-key and SysRq-key (which is the "Print Screen" key)
and type/press slowly R E I S U B ( i.e. press each key once: R-key, E-key, I-key etc.)

In addition to a manualy filesystem check in an emergency cases it advisable to make sure regularly fs-check's are enabled on the device at boot time.
You would verify regularly fs-check's at boot time are enabled by running this (using my boot device /dev/sda1 as an example here).

Code: Select all

sudo LANG=C tune2fs -l /dev/sda1 | grep -iE "mount count|Check interval|Last|Next"
Last mounted on:          /
Last mount time:          Tue Oct 30 10:53:46 2018
Last write time:          Tue Oct 30 10:53:46 2018
Mount count:              4
Maximum mount count:      60
Last checked:             Mon Oct 29 16:40:34 2018
Check interval:           2592000 (1 month)
Next check after:         Wed Nov 28 16:40:34 2018
Installing MX shall already cater for setting regularly fs-checks on the installed partitions.
If not already set, you would enable it like this:

Code: Select all

sudo tune2fs -c 60 -C 61 -i 30d  /dev/sda1
# -c 60 =  max-mount-counts 60 
# -C 61 =  set the number of times the filesystem has been mounted.
#        61 > 60 : check the filesystem at the next reboot
# -i 30d = interval-between-checks : 30 days
# or
# -i 1m  = interval-between-checks : 1 month
:puppy:
Gigabyte Z77M-D3H, Intel Xeon E3-1240 V2 (Quad core), 32GB RAM,
GeForce GTX 770, Samsung SSD 850 EVO 500GB, Seagate Barracuda 4TB

User avatar
Jerry3904
Forum Veteran
Forum Veteran
Posts: 22697
Joined: Wed Jul 19, 2006 6:13 am

Re: Corrupted main partition saved by MX Live

#3 Post by Jerry3904 » Tue Nov 06, 2018 10:15 am

We have a section that goes through steps of increasing force: Users Manual 4.7.5 "Kill runaway programs."

Any suggestions to that would be welcome.
Production: 4.15.0-1-amd64, MX-17.1, AMD FX-4130 Quad-Core, GeForce GT 630/PCIe/SSE2, 8 GB, Kingston SSD 120 GB and WesternDigital 1TB
Testing: AAO 722: 4.15.0-1-386. MX-17.1, AMD C-60 APU, 4 GB

User avatar
fehlix
Forum Guide
Forum Guide
Posts: 2064
Joined: Wed Apr 11, 2018 5:09 pm

Re: Corrupted main partition saved by MX Live

#4 Post by fehlix » Tue Nov 06, 2018 10:35 am

Yes. see above.
Gigabyte Z77M-D3H, Intel Xeon E3-1240 V2 (Quad core), 32GB RAM,
GeForce GTX 770, Samsung SSD 850 EVO 500GB, Seagate Barracuda 4TB

agrendel
Forum Novice
Forum  Novice
Posts: 10
Joined: Fri May 18, 2018 3:23 pm

Re: Corrupted main partition saved by MX Live

#5 Post by agrendel » Fri Nov 09, 2018 10:39 am

Many thanks to fehlix for his advice on using tune2fs, which I have taken as there seems to be no regular check setup after a standard MX-Linux installation.

Replying to Jerry3904 and further to suggestions concerning how to kill runaway programs, I have used variants of the following steps to get back control when an X-window is frozen:
Ctrl-Alt-F1 : drops out of X-windows to 1st console. Log back in to a terminal.

Then to find the culprit and "kill" the runaway processes started by this program use either:
top : lists all active processes with memory & cpu usage that can help identify programs that hog memory and perhaps lead to frozen window. But like the Task Manager it is a moving target. So "ps" is a more stable view, as follows ...
ps -aux | less : lists running processes using "less" for ease of scrolling; i.e. spacebar to scroll down and "b" to scroll back.
Check user in first column (as with top) to see which programs you - as user - can "kill".
pgrep -l <progname> : gives all the process numbers to kill of the program you suspect is causing the freeze-up.
Some programs, particularly browsers have numerous processes running which can hog memory.
pkill <progname> : kills all active processes of program.

Finally,
Ctrl-Alt-F7 : returns you to your desktop, hopefully "unfrozen".

No doubt both of you know all about these tools, but as a beginner curious to learn how things work and get a better grip on a Linux system (which is my case) I thought it may be useful to add to the Mx-Linux Wiki - perhaps it's unnecessary for the User Manual which is already very complete. I also found this URL link very clear on how "killing" programs work. Just my two cents worth ;)
MX 17.1_x64 Horizon: Thinkpad X220, Core i5-2540M, 8GB RAM Kernel 4.15.0-1-amd64

Post Reply

Return to “MX Help”