Pi3: /etc/default/rcS --> FSCKFIX=yes?

[Rive]

Pros and cons to leaving this file checker uncommented and enabled on an overclocked pi3?

Code: Select all

# automatically repair filesystems with inconsistencies during boot
FSCKFIX=yes

[Rive]

Anyone familiar with FSCKFIX?

[Rive]

Anyone?

[jojopi]

If you do not know what FSCKFIX means, then it is best not to change it.

I suspect you do have some idea what it means, and some theory why you might want to change it. It would be good to outline your thoughts and understandings and then ask for advice. People are unlikely to write a detailed response to a vague question, and even if they did it might not address your particular concerns.

[Rive]

If you do not know what FSCKFIX means, then it is best not to change it.

I suspect you do have some idea what it means, and some theory why you might want to change it. It would be good to outline your thoughts and understandings and then ask for advice. People are unlikely to write a detailed response to a vague question, and even if they did it might not address your particular concerns.

It is simple. I am heavily overclocked (both SoC and HC-1 Sdcard). I want the file system scanned for inconsistencies, fixed/repaired as necessary at boot to prevent potential issues/corruption that could result in a non-bootable event (requiring restoral of backup image to sdcard).

My question is thus:

This is by default, commented out and set to"no" (which I assume means (if uncommented) run at boot, but do not auto fix).

I just want to know is it advantageous in any way to run this automatically at boot, or is it commented out/disabled for a reason? and not worth enabling or setting to "yes"?

In otherwords, simply put, and in a nutshell:

Pros and cons to leaving this file checker uncommented and enabled on an overclocked pi3?

[DirkS]

Isn't this overridden in current RPF Raspbian images using the kernel command line?
/boot/cmdline.txt:

Code: Select all

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

[Rive]

Isn't this overridden in current RPF Raspbian images using the kernel command line?
/boot/cmdline.txt:

Code: Select all

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Are you saying that uncommenting this is useless?

sudo nano /etc/default/rcS

Code: Select all

# automatically repair filesystems with inconsistencies during boot
#FSCKFIX=no

[jojopi]

Nothing can repair data corruption if it has happened. fsck simply makes filesystem metadata consistent. (So, directories cannot be their own parent, no two files have the same name, all space either belongs to exactly one file or is free; things like that.) You may still lose data, including stuff that is needed for boot.

FSCKFIX does not control whether fsck runs, but whether it "fixes" everything without user interaction. With "no", it will abort and give you a root shell if the errors are too serious. If your goal is to manually recover as much data as possible, you might want that. If you have backups, you might prefer to let fsck try its best.

In the Foundation's spindle-era images, FSCKFIX=yes was actually the default. In recent images, /boot/cmdline.txt has "fsck.repair=yes". I believe that takes precedence and is basically equivalent. If you want "no", remove the stanza from /boot/cmdline.txt as well.

[Rive]

Nothing can repair data corruption if it has happened. fsck simply makes filesystem metadata consistent. (So, directories cannot be their own parent, no two files have the same name, all space either belongs to exactly one file or is free; things like that.) You may still lose data, including stuff that is needed for boot.

FSCKFIX does not control whether fsck runs, but whether it "fixes" everything without user interaction. With "no", it will abort and give you a root shell if the errors are too serious. If your goal is to manually recover as much data as possible, you might want that. If you have backups, you might prefer to let fsck try its best.

In the Foundation's spindle-era images, FSCKFIX=yes was actually the default. In recent images, /boot/cmdline.txt has "fsck.repair=yes". I believe that takes precedence and is basically equivalent. If you want "no", remove the stanza from /boot/cmdline.txt as well.

Thanks.