DietPi-Drive_Manager | Read only filesystem option.

[Fourdee]

http://fuzon.co.uk/phpbb/viewtopic.php?f=12&t=333&p=1463#p1459

[Fourdee]

As DietPi uses Ramlog, our SD writes are extremely low when compared with other images, a read-only filesystem will only benefit users who wish to prevent file modifications / sudden power outage.

[xenfomation]

Agreed -- read-only FS can be avoided with a USB drive if the idea is dodging entropy

[axel-h]

One use case might be that an accidental shutdown of the system does not do any harm. I had a few cases with other distributions where power loss makes the SD card unusable and only a fsck on another machine can fix this. But it might also be a weakness of the file system that is used - should just pick a better one. Or it's a bug in the Odroid's SD usage. We'll see if I run into this with DietPi also.

[trajano]

@axel-h I presume you tried touch /forcefsck and it doesn't really help with the file system corruption errors either like I did.

[ParaplegicRacehorse]

Use case for write protection: thin clients and high availability fail-over server systems and anything else that might want or need to have most of its filesystem served to it over the network.

[WolfganP]

I was investigating on this front as well to reduce SDcard wear, and found useful to install both iotop (apt-get install iotop) and iostat (apt-get install sysstat)
With the ramdisk implementation, it seems no much I/O activity is directed to the SDcard (mmcblk0 in my case) but still there is some, even in idle systems. Will keep investigating and share the results.

[trajano]

One option that @ddurdle uses in his Pi installations is BTRFS and he makes a stable snapshot at one point which he can readily recover from. Although I don't really like the idea of having a fully read only file system (since I like to play around with my Pi) using that may be an option. F2FS is too lean and have no real recovery features from what I can tell so I won't really recommend that unless it is for a read only file system, but that won't really make sense unless you plan to make a device that is single in purpose and have an external storage device or separate partition for other things.

Actually that may not be a bad idea too, to provide a way of locking down the file system once a stable state has been reached and every reboot will restore back to that state. This can be further expanded to make it such that /home gets mounted on a different partition separate from the rest of root which will be mounted as a ramdisk with copy on write. On reboot we can then do a mount home as read-only do the fsck then remount as rw. However in case that does not work too well we can still do login as root and umount /home and do the fsck then remount it.

[ddurdle]

I highly recommend at least mounting the SD card in read-only mode during normal operation, at least for the OS component. Break out user files to a separate partition or device. Highly recommend using overlays for this purpose (supported on kernel 3.18 or newer). Secondly, I recommend leveraging BTRFS to allow for snapshots for easily backing up and for handling corruption if you refuse to go the read-only route. Mount the booting OS as a subvolume snapshot. If it badly gets corrupt, flip back to a snapshot. I recommend not mounting the root BTRFS on a regular basis because if you corrupt the root BTRFS, you lose your snapshots. It also comes in handy to at least backup snapshots periodically to a difference device.

I've kissed corrupt SD cards goodbye.

[ddurdle]

I'll also add one other bit of warning. Even if you are not writing to SD card regularly, simply having the partition mounted in read-write will eventually lead to corrupting the partition if undervolting or improper shutdown occurs. I average 6 months before I get into a situation where I can't boot anymore and this is from very little or no actual writes to the partition (simply mounting it, not using it).

Leveraging overlays to capture all writes, I have yet corrupt a SD card. I even have a few SD cards that are nearing their end-of-write life (they will be unbootable after 1-2 reboots in read-write mode), and they still run forever bootable and fully working when I redeploy.

[Fourdee]

Notes:

Need some tweaks running / under RO

• 🈯️ Ramdisk:

root@DietPi:~# systemctl status dietpi-ramdisk -l
● dietpi-ramdisk.service - DietPi-RAMdisk
   Loaded: loaded (/etc/systemd/system/dietpi-ramdisk.service; enabled)
   Active: failed (Result: exit-code) since Sun 2017-05-07 12:42:44 BST; 51s ago
  Process: 554 ExecStart=/bin/bash -c /boot/dietpi/dietpi-ramdisk 0 &>> /etc/dietpi/logs/dietpi-ramdisk.log (code=exited, status=1/FAILURE)
  Process: 517 ExecStartPre=/bin/mkdir -p /etc/dietpi/logs (code=exited, status=0/SUCCESS)

May 07 12:42:44 DietPi bash[554]: /bin/bash: /etc/dietpi/logs/dietpi-ramdisk.log: Read-only file system
May 07 12:42:44 DietPi systemd[1]: dietpi-ramdisk.service: control process exited, code=exited status=1
May 07 12:42:44 DietPi systemd[1]: Failed to start DietPi-RAMdisk.
May 07 12:42:44 DietPi systemd[1]: Unit dietpi-ramdisk.service entered failed state.

• Going from RO to RW = issues, due to the way we inject /etc/fstab during init for newly found drives, and, write to it directly. 🈯️ Fixed with additional code checks for R/O RootFS

[Fourdee]

[Fourdee]

Completed.

Supports toggling R/W R/O on all partitions, including RootFS.