I have run sudo touch /forcefsck but what else I have to do?
That's stuff that applies more to wheezy; jessie may (or may not) be backward compatible with it, but you might as well do it the new way:
Add the following to /boot/cmdline.txt:
Make sure that file remains all one line. Parameters should be separated with spaces.
What happens is that fsck gets run after so many reboots or when it suspects the disk is in trouble. The number of reboots can be changed with tune2fs, but that won't fix your problem. Working backwards to the solution, here's the correct option for fsck:
-y For some filesystem-specific checkers, the -y option will cause the fs-specific fsck to
I was able to fix the issue using these steps:
#/dev/mmcblk0p2 / ext4 errors=remount-ro 0 1
/dev/mmcblk0p2 / ext4 ro 0 1
This should mount the rootfs as read-only on the next reboot.
Reboot system using: shutdown -rF now
Run fsck -fy if the system hasn't already
Remount the rootfs as read-write using:
mount -o remount,rw /dev/...
you might think about separating your system to the read-only partition and your data files somewhere else. read-only system is unlikely to get corrupted and after you have it up and running, you may start recovery scripts and/or login over SSH to fix the possible problems.
Raspbian is a derivate of Debian and this isn't designed to work without a clean shutdown by default. May work with journaling on the root partition with ext4 file system but it is only designed for disaster recovery one time. The boot partition has a simple vfat file system and do not have disaster recovery so it may be easy corrupted. Using it for years is ...
If you do not want to take the risk of corrupting your SD Card by disabling fsck on startup you can use your first suggestion: "lengthening the timeout" on starting services. With systemd you can easily change DefaultTimeoutStartSec in
In man systemd.service you will find:
TimeoutStartSec= Configures the time to wait for start-...
After trying out the approach of creating a forcefsck file in /, fsck actually complained with the message:
Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system.
So instead of creating this file on every boot, I added fsck.mode=force to /boot/cmdline.txt.
This forces a fsck check on every ...
If you feel like file corruption is one of your major problems, consider moving the entire OS away from the SD-card. On a Raspberry Pi 1 / 2 / Zero (W) you need at least some boot files on the SD-card but you can run the rest from a USB device. With a freshly downloaded image:
Copy the entire Raspbian image to a USB-device.
Copy (only!) the /boot/ partition ...
Typical usage of a Raspberry Pi is that it often gets rebooted. Every Linux filesystem has a mount counter and after X reboots, it will get checked with fsck. Unless you tell Linux not to do that, by way of fstab.
fsck is also rather slow on an SD card, and the Raspberry Pi isn't exactly the fastest horse on the race track. If they didn't do this, you would ...
You can run a live Debian CD on a normal computer + USB SD card reader or a laptop with an SD card slow.
Boot into the live CD.
Plug in the SD card
It should mount
Copy what you need.
Run a low level format ...
For Windows specifically HDD LLF is a really great piece of software
Windows and Macintosh the SD Formatter is also good.
In Linux dd if=/dev/zero ...
You haven't expanded your filesystem. Execute the command shown below when signed into the user 'pi':
When shown with a screen, choose Option 1, to expand your filesystem. Press the enter key when highlighting over the option. This should make you be able to use more space on your Pi.
I don't know what to do about your distance situation ...
I had this error temporarily (after fixing SD card in a host PC). Fixed it by writing correct time into /etc/fake-hwclock.data.
It may work for you purpose to fix-up this file to some date beyond when the image was created, so the superblock timestamp is never seen to be in the future.
This is somewhat common if your Pi shuts down unexpectedly (perhaps from low voltage) or crashes, or even if you shut it down without stopping Apache gracefully - if this is going to be a common occurrence, you may want to set it up such that the SD card is in read-only mode
alternatively, different file systems have different anti-corruption ...
This what I am using on a Jessie old-stable release, at the end of the line in cmdline.txt:
I also have the following in fstab:
/dev/mmcblk0p1 /boot vfat defaults,noatime 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
Note the 1 and 2 at the end of the line
It checks and repairs the root partition (/...
You should also be able to do the following which should work for any Linux not just the Pi (obviously the device will change for different platforms, sda2 should be right for a default Pi SD card):
sudo tune2fs -c 1 /dev/sda2
That should set a check every reboot. You can change the number to whatever you like. Use -i instead of -c if you want time-based ...
Like many other activities, booting is now controlled by systemd processes. I suspect that there is a way to give fsck additional time to complete, but I don't know enough about that to advise. However, systemd still depends on /etc/fstab for its instructions. And so, without rendering any opinion on the wisdom of this (see note), following is a "recipe for [...
To repair the filesystem you need the programs fsck.*. These are located on the root partition. Do you already see the problem?
You have repaired the filesystem on the first SD Card by using the fsck.* programs from the Ubuntu system. On boot of your second SD Card it tries to use fsck.* from the root partition that cannot be mounted. The only way to repair ...
I was under the impression that the root was fsck'ed during the boot process, if deemed necessary. You could verify that by checking the /etc/fstab file. Look for your root partition entry (line with a / in the second column) and verify that the sixth column is 1 and not 0. It should look like the following line:
/dev/mmcblk0p2 / ext4 ...
You can place a file named forcefsck in /boot. So you can plug the SD card into any computer that is able to mount the FAT file system and create the file there.
But I don't know in wich stage of booting your panic happens and if you will reach the fsck stage before it. So it might or might not work.
A quick search on the raspberry pi forum suggests ...
Start up your system as normal then unmount the boot partition, check it, optionally correct it, and remount.
sudo umount /boot # unmount
sudo fsck /dev/mmcblk0p1 # see what it says
sudo fsck -a /dev/mmcblk0p1 # if happy with suggested corrections
sudo mount /boot # remount
EDITED TO ADD
If the above does not solve ...
You can VERY likely solve this. :-)
In Mac's Disk Utility, click on the disk (this is the out-dented line naming the drive) and run repair. It should come out ok, but I always feel like it can't hurt.
Now for each drive below that (these are your partitions) do the same. Click on it and click "Repair Disk" YES, I know you got (and will likely get) "...can'...
I've found that if I dd a typical RPi image to the SD card and then go straight to the RPi, I typically don't see this issue. But, if I decide to mount the card and manipulate it before moving it to the RPi, this happens every time.
After a bunch of investigation, I found that the problem is that when you mount your SD card on your Linux computer, the ...
You can do that. I have this in /etc/rc.local:
echo "-y" > /forcefsck
So that it happens every reboot (unless I rm /forcefsck first). I think -a and -y are probably redundant if -a means don't ask questions and -y means answer yes to any questions. man fsck refers to -a as supported "for backward compatibility only" (i.e., it's depreciated).
use another linux box to read and backup your favourite files from SD card, then reimage fresh Raspbian build and put files back again, this might be the easiest and fastest way to recover from broken file system.
additional points if you use another, preferably new, SD card for the new image.
Power-related crashes are better handled with some sort of UPS solution like juice4halt.
For cases where unexpected shutdown cannot be prevented, I suggest you try data=journal option for your root partition. It will make writes slower (but as you said in comments your root is virtually rea-only so there will be little impact), and fsck will be able to fix ...