Sometimes a change in the chrooted read/write root might hold a file open, in the example below it appears a service is started and the remount to read-only fails: $ mount -v | grep /ro Set the file system to read/write mode and create a using your editor of choice: sudo vi /ro/usr/bin/rwshell, then paste the following script: #!/bin/bashĪnd be sure to make it executable: sudo chmod +x /ro/usr/bin/rwshell. When developing a software stack or configuration for deployment it may be necessary to make lots of little tweaks in response to testing so wrapping the whole process in a script can make life a lot easier, especially if the script lives on the SD card as is always available. Some changes do not get picked up so easily and a logout or reboot may be required which will also ensure we are back in read-only mode. We can then return to the parent file system by exiting the shell and then return to the original state by remounting in read-only mode. A "chrooted" environment has access the the majority of the host features including the network and the Internet. $ sudo chroot here we can run apt update or apt install amongst other things. One such example would be installing software packages using apt.įor most actions that expect root to be at / we can use chroot which can run commands or provide an interactive shell using a given folder as /. There are other changes that anticipate the root file system and the associated directory structure being available at the / mount point (rather than /ro). Now the file system can be remounted in read-only mode: sudo mount -o remount,ro /roĪ quick reboot will also get it back to read-only mode. OverlayFS is presenting a writable layer over the read-only file system, so any underlying changes are visible immediately (unless there's also a modification in the temporary read/write layer). We can also see immediately that the file is available: $ ls /home/pi/ Where it was previously read-only (ro) it's now read/write (rw) and we can make a test file: touch /ro/home/pi/test.txt dev/mmcblk0p2 on /ro type ext4 (rw,relatime) The command above should succeed silently, which can be verified with: $ mount -v | grep /ro To make basic changes we can simply remount that in read/write mode: sudo mount -o remount,rw /ro Touch: cannot touch '/ro/home/pi/test.txt': Read-only file system dev/mmcblk0p2 on /ro type ext4 (ro,relatime)Īs ro suggests, we can't make any changes to it: $ touch /ro/home/pi/test.txt ro is the root partition, and it is currently mounted as read-only: $ mount -v | grep /ro Unlike the built-in Raspberry Pi process to enable OverlayFS the steps above keeps the read only file system visible as a mount: $ df -hįilesystem Size Used Avail Use% Mounted on Set up the pi for read-only with OverlayFS using my Mini Guide: Read only Raspberry Pi (without NFS) - at the time of writing this still works with RasberryPI OS, formerly Raspbian. The ability to boot a Raspberry Pi from a read-only file system can be advantageous for a variety of reasons and I've previously written a number of posts that look at use cases and implementation approaches.Ī key challenge is then making changes, often this requires a reboot to change from read-only to read-write, then the changes are made, then the read-only setting is reintroduced with another reboot - this can get tedious when developing a solution.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |