Checking sdcard for errors, unmount problem

Question

I've tried running running a disk check, then I got a complain

pi@raspberrypi ~ $ /sbin/fsck
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
/dev/mmcblk0p2 is mounted.

WARNING!!!  The filesystem is mounted.   If you continue you ***WILL***
cause ***SEVERE*** filesystem damage.

Do you really want to continue<n>? no
check aborted.
pi@raspberrypi ~ $ umount -l /dev/mmcblk0p2
umount: it seems /dev/mmcblk0p2 is mounted multiple times

Do I have to umount, what are the steps for a safe umount?

Update:

pi@raspberrypi ~ $ mount
/dev/root on / type ext4 (rw,noatime,nodiratime,user_xattr,barrier=1,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=118872k,nr_inodes=29718,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=23788k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=47560k)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii,shortname=mixed,errors=remount-ro)

pi@raspberrypi ~ $ cat /etc/mtab
rootfs / rootfs rw 0 0
/dev/root / ext4 rw,noatime,nodiratime,user_xattr,barrier=1,data=ordered 0 0
devtmpfs /dev devtmpfs rw,relatime,size=118872k,nr_inodes=29718,mode=755 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=23788k,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=47560k 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0
/dev/mmcblk0p1 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0

pi@raspberrypi ~ $ cat /etc/fstab
proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime,nodiratime,nodiratime  0       1
# a swapfile is not a swap partition, so no using swapon|off from here on, use  dphys-swapfile swap[on|off]  for that

I also see this in dmesg:

[    3.054577] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:3a:ff:c1
[    4.592609] EXT4-fs (mmcblk0p2): ext4_orphan_cleanup: deleting unreferenced inode 47900
[    4.611794] EXT4-fs (mmcblk0p2): ext4_orphan_cleanup: deleting unreferenced inode 31567
[    4.630805] EXT4-fs (mmcblk0p2): ext4_orphan_cleanup: deleting unreferenced inode 23732
[    4.647041] EXT4-fs (mmcblk0p2): ext4_orphan_cleanup: deleting unreferenced inode 4871
[    4.662074] EXT4-fs (mmcblk0p2): ext4_orphan_cleanup: deleting unreferenced inode 4653
[    4.662256] EXT4-fs (mmcblk0p2): ext4_orphan_cleanup: deleting unreferenced inode 4514
[    4.662344] EXT4-fs (mmcblk0p2): ext4_orphan_cleanup: deleting unreferenced inode 4465
[    4.677977] EXT4-fs (mmcblk0p2): ext4_orphan_cleanup: deleting unreferenced inode 3989
[    4.678142] EXT4-fs (mmcblk0p2): 8 orphan inodes deleted
[    4.685881] EXT4-fs (mmcblk0p2): recovery complete
[    8.631347] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    8.644244] VFS: Mounted root (ext4 filesystem) on device 179:2.
[    8.654677] devtmpfs: mounted
[    8.661103] Freeing init memory: 124K
[   10.414514] udevd[139]: starting version 175
[   21.263308] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[   21.967590] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[   22.849536] bcm2835 ALSA card created!
[   22.855703] bcm2835 ALSA chip created!
[   22.875121] bcm2835 ALSA chip created!
[   22.885884] bcm2835 ALSA chip created!
[   22.894074] bcm2835 ALSA chip created!
[   22.902271] bcm2835 ALSA chip created!
[   22.910319] bcm2835 ALSA chip created!
[   22.918129] bcm2835 ALSA chip created!

@AlexChamberlain See my updated with the contents of the mounts. — Pentium10, Oct 22 '12 at 19:41

score 27 · Accepted Answer · edited Mar 20 '17 at 10:18

/dev/mmcblk0p2 is the root file system, so it is not easily unmounted. It could probably be re-mounted as read-only, but a simpler way is to schedule a fsck at the next reboot.

sudo touch /forcefsck

then reboot. Or reboot with

shutdown -rF now

which does the same. (from https://superuser.com/questions/401217/how-to-check-root-partition-with-fsck)

Another option of course is to do the fsck on another linux computer with a card reader.

score 2 · Answer 2 · answered Jan 03 '21 at 22:52

The bottom line with fsck is this:

You should not run fsck on a mounted filesystem

If you need to run fsck on your RPi's root filesystem/SD card, there are two choices:

1. Remove the SD card media from the RPi

This approach will be most useful for SD cards (or other media in general) that are suspected of being bad/faulty. It may even prove useful in salvaging boot media with the repair (-p) option.

Note: You'll need the following items to use this procedure:

USB-to-SD adapter - Something like this:

A Linux PC - or another RPi - something running a fairly current version of the OS
As an alternative to a 2nd RPi or Linux PC, you can simply boot your RPi from a spare SD card!

Step 1:

After removing power from the RPi, remove the SD card to be checked & repaired from its slot, and insert it into the USB-to-SD adapter

Step 2:

Insert the USB-to-SD adapter into an available USB port on a laptop or RPi.

Step 3:

From a terminal window on the Linux PC/RPi, use lsblk to get the necessary file system "handles" for the SD card:

$ lsblk --fs

You should see something like this:

NAME        FSTYPE LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda
└─sda1      ext4   PASSPORT2TB 86645948-d127-4991-888c-a466b7722f05    1.5T    11% /mnt/Passport2TB
sdc
├─sdc1      vfat   boot        592B-C92C
└─sdc2      ext4   rootfs      706944a6-7d0f-4a45-9f8c-7fb07375e9f7
mmcblk0
├─mmcblk0p1 vfat               6969-16D1                             200.4M    22% /boot
└─mmcblk0p2 ext4               f6ea6ef9-68be-479d-b447-5f76391cc02f     23G    16% /

sda is a mounted USB drive I have named Passport2TB

mmcblk0 is my RPi's SD card - the one it is currently running - not the suspect SD card

And finally,

sdc is the USB-to-SD adapter with the suspect SD card

Note that there are two partitions in sdc: one vfat, one ext4 as sdc1 and sdc2 respectively. Also note that the MOUNTPOINT column shows both partitions are unmounted, and therefore safe to be fsck'd :)

And so, we are now ready to fsck...

Step 4:

As it turns out, the fsck command falls into a rather large class of Linux commands that have been extended and upgraded to support the relentless advance of technology. That is, fsck is now a wrapper or a front-end for a host of underling commands that do the actual work. Without wandering too far afield with the details of this evolution of fsck, let me just say that man fsck lists the underlings we need:

e2fsck: check a Linux ext2/ext3/ext4 file system; ref man e2fsck
fsck.vfat: check and repair MS-DOS filesystems; ref man fsck.vfat

Tools in hand, we may finally get to the task. Using the filesystem handles from above:

$  $ sudo e2fsck -p /dev/sdc2
rootfs: clean, 45989/1899328 files, 524782/7725184 blocks

Unfortunately (for purposes of this example), the ext4 partition on my SD card was clean - no errors. The response would have been different of course had there been issues, and of course dependent upon what those issues are. Next up, the vfat partition - which contains the boot files:

$ sudo fsck.vfat -p /dev/sdc1
fsck.fat 4.1 (2017-01-24)
/dev/sdc1: 321 files, 111913/516190 clusters

Not as affirmative as e2fsck, but the message is the same: it found no problems with the vfat partition.

Step 5:

fsck found no errors... what does this mean?

It probably means that whatever errors you experienced were not in the filesystem. It probably means that your SD card is still viable, and can be used again. You should probably re-flash it to remove any corrupted files & ensure all required files are present.

2. Run it during the `boot` process - which happens before it's mounted

This is covered under another answer, so I'll not repeat it here.

anNA · Answer 3 · 2013-01-18T11:53:50.563

2

sudo touch /forcesck didn't work for me...

but I did the following and it checked errors:

force a manual fsck and reboot:

 fsck -fy /dev/mmcblk0p2

 reboot

edited Jan 18 '13 at 11:53

answered Jan 18 '13 at 10:49

anNA

121
2

1

where did you get `/dev/mmcblk0p2 ` How can I figure out myself? – Pentium10 Jan 19 '13 at 21:39
@Pentium10 `df` – ohho Jul 12 '13 at 08:56
The `df` command did not work for me to detect the root partition on Kali Linux v2.0. I solved it by issuing `mount` and checking for the `/` mount, or `mount | grep " / "` (note the existing ` ` spaces). – Sopalajo de Arrierez Feb 20 '16 at 13:19
1

I don't think forcing `fsck` on a mounted root partition would be a good idea. – Sopalajo de Arrierez Feb 29 '16 at 14:17
2

you have a typo. it's "forcefsck" and not "forcesck" – sufinawaz Sep 30 '17 at 15:45
@Pentium10 `lsblk` will do that – Binar Web Sep 28 '20 at 12:02

score 0 · Answer 4 · edited Jun 07 '15 at 15:06

0

I have the same issue when using putty to connect to my pi. I assume you are using some remote connect like putty. Try hooking your RPi HDMI directly to a monitor, plugging a usb keyboard into your RPi then powering up. Watch the screen for errors then run fsck when boot complete.

edited Jun 07 '15 at 15:06

Ghanima

15,578
15
58
113

answered Jun 05 '15 at 15:13

user31572

11

Checking sdcard for errors, unmount problem

4 Answers4

1. Remove the SD card media from the RPi

Step 1:

Step 2:

Step 3:

Step 4:

Step 5:

2. Run it during the `boot` process - which happens before it's mounted

Linked

Checking sdcard for errors, unmount problem

4 Answers4

1. Remove the SD card media from the RPi

Step 1:

Step 2:

Step 3:

Step 4:

Step 5:

2. Run it during the boot process - which happens before it's mounted

Linked

2. Run it during the `boot` process - which happens before it's mounted