> Thanks for your help. I have tried Ralfs approach and it works. Just > for my understanding (I like to learn more) : can you explain why this > works? This is not very clear to me. But anyhow, thanks both of you
It has to do with how the Linux kernel manages deleted files and mounted filesystems. When you unlink a binary that is being executed (for instance: /bin/busybox), said binary is not deleted at once, because it is still in use (processes executing it have a fd open on it). The binary is just marked for deletion; when all processes executing it have exited, the real deletion occurs. To remount / read-only, Linux must be able to guarantee that / will not change at all after it is remounted, so it makes sure there is no pending write operation on the root filesystem. That means, no file descriptor open for writing pointing to a file on the root filesystem, *and* no pending deletion of a file that is currently in use. (Plus other esoteric things that are irrelevant here). If one of those conditions is unmet, "device is busy": / can't be remounted read-only because it is still being used read-write. Processes accessing deleted files must first exit, then the pending deletion can occur, then the device is not "busy" anymore. Of course, when the deleted file is the executable for process 1, as is often the case for /bin/busybox used as a shell, it is not easy to do this cleanly... Renaming /bin/busybox to /bin/busybox.old solves the problem because there is no pending deletion operation: processes that were executing /bin/busybox are now executing /bin/busybox.old, and nothing prevents / from being remounted read-only. After you reboot, processes are executing the new /bin/busybox, nothing is executing /bin/busybox.old, so you can unlink /bin/busybox.old and have it immediately deleted from the disk, then remount / read-only without trouble. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
