5

Due to an sd card corruption I decided to mount the root fs as read only. Therefore, I added the 'ro' argument in /etc/fstab 

/dev/mmcblk0p1  /boot           vfat    defaults,ro          0       2
/dev/mmcblk0p2  /               ext4    defaults,ro,noatime  0       1

After the device is booted, the filesystem is mounted read-only - so that's fine. However, sometimes I need write access to the file system. So, I remount the root fs with

sudo mount / -o remount,rw

as read/write. However, if I want to remount the filesystem with

sudo mount / -o remount,ro

I get the following error:

mount: / is busy

If I run:

fuser -v ./

I get the following output: 

USER PID ACCESS COMMAND
pi   2421 ..c.. sftp-server
pi   2477 ..c.. bash

Does anybody know what's causing the problem? Why can the filesystem be mounted as read only at startup, but not if I remount it manually?

Improve this question
2
  • Have you solved your problem? If so, please mark the answer that helped you, or if you solved it on your own, create a self-answer and mark it as such. We are trying to get the site Q:A ratio up and marking answers is what does that. If you resolved it and mark then people in the future will be able to profit from what you did and it helps move the site closer to graduation. Thanks!
    – RPiAwesomeness
    Mar 23, 2014 at 16:57
  • Same problem here. What's more, sometimes remount,ro succeeds, sometime is shows "/ is busy".
    – Osman-pasha
    Apr 9, 2014 at 16:21

6 Answers 6

Reset to default
3

You can emulate a magic sysrq keypress by executing

# echo "u" > /proc/sysrq-trigger

This causes the kernel to low-level try to remount all filesystems read only, see here.

Improve this answer
0
2

This is most likely because something (by the looks of that command it is the BASH shell and SFTP-Server) is/are accessing the root filesystem. During boot nothing is accessing anything in / yet, so it can be set to read-only.

However, once boot-up is complete, some software may want a lock on the filesystem or some files are being changed within. Obviously, as all the files that Raspbian uses - software, personal files, logs, etc. - are within the root filesystem. Thus you get the mount: / is busy error.

If you were able to kill both BASH and SFTP-server and then run the command, I suspect that it would work fine. However, because BASH is the way you are entering the commands, and BASH is stored on the / partition, that can't happen.

Improve this answer
1
  • If you shut off the SSH service via /etc/init.d/ssh stop that might be enough to make it go, even without killing bash.
    – Fred
    Mar 24, 2014 at 10:14
2

If you still can not unmount or remount your device after stopping all services and processes with open files, then there may be a swap file or swap partition keeping your device busy. This will not show up with fuser or lsof. Turn off swapping with:

sudo swapoff -a

You could check beforehand and show a summary of any swap partitions or swap files with:

swapon -s

or:

cat /proc/swaps

As an alternative to using the command sudo swapoff -a, you might also be able to disable the swap by stopping a service or systemd unit. For example:

sudo systemctl stop dphys-swapfile

or:

sudo systemctl stop var-swap.swap

In my case, turning off swap was necessary, in addition to stopping any services and processes with files open for writing, so that I could remount my root partition as read only in order to run fsck on my root partition without rebooting. This was necessary on a Raspberry Pi running Raspbian Jessie.

Improve this answer
1

On many SD cards, there is a switch prohibiting write access. If it is off, switch it the other way to disable write protection.

Image Courtesy of jackenhack.com

If the switch is not to blame, I would advise following the advice here for rescuing.

Improve this answer
1
  • 3
    On the raspberry pi, the write protect switch is not connected, so the position of the switch on the card does not matter.
    – TomG
    Feb 27, 2014 at 2:03
1

I was banging the same wall for a long time, until I found this: https://wiki.debian.org/ReadonlyRoot#Find_processes_blocking_the_remount_readonly

When lsof and fuser do not show any files opened for writing on / (which seems your case), there could still be processes that have opened files that were deleted since, and they are blocking the remount.

The following command shows these proceses:

lsof +L1; lsof|sed -n '/SYSV/d; /DEL\|(path /p;' |grep -Ev '/(dev|home|tmp|var)'

After restarting deamons shown in the list and killing the rest, mount -o remount,ro / went fine.

Improve this answer
1
  • Thanks for this, an upgrade had replaced the binary for agetty, yet the processes were still running with the old (now deleted) binary. Your command identified the problem.
    – André Paramés
    May 29, 2016 at 8:29
0

you probably have some app writing to the filesystem... i suspect the sftp-server is transferring something.

So until the file is not write closed or killed, it's probably locking up the remount as ro

Improve this answer
1
  • I had the same idea, but killing the sftp-server didn't change anything. However, after countless hours of trying I finally got it to work with IPE riscpi.co.uk/nutcom-services-ltd
    – user9760
    Oct 1, 2013 at 18:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.