1

I followed a guide to make a Raspberry Pi boot a read-only file system.

$ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait fastboot noswap ro

$ cat /etc/fstab
proc                  /proc     proc    defaults             0     0
PARTUUID=fb0d460e-01  /boot     vfat    defaults,ro          0     2
PARTUUID=fb0d460e-02  /         ext4    defaults,noatime,ro  0     1
tmpfs                 /tmp      tmpfs   nosuid,nodev         0     0
tmpfs                 /var/log  tmpfs   nosuid,nodev         0     0
tmpfs                 /var/tmp  tmpfs   nosuid,nodev         0     0

When I compute the SHA512 hash of its SD card, the hash changes after reboot... why?

$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         500.1 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +500.1 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD - Data     340.9 GB   disk1s1
   2:                APFS Volume Preboot                 85.9 MB    disk1s2
   3:                APFS Volume Recovery                529.0 MB   disk1s3
   4:                APFS Volume VM                      3.2 GB     disk1s4
   5:                APFS Volume Macintosh HD            11.3 GB    disk1s5

/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *15.9 GB    disk2
   1:             Windows_FAT_32 boot                    268.4 MB   disk2s1
   2:                      Linux                         15.7 GB    disk2s2

$ sudo openssl dgst -sha512 /dev/rdisk2
...
2
  • 1
    Well, for one you're computing the hash of the entire disk and not just the partitions mounted read-only. Commented Mar 2, 2021 at 21:20
  • Thanks for helping out @AndrewHenle. My understanding is that both /boot and / are read-only. Commented Mar 2, 2021 at 21:24

1 Answer 1

2

This is expected behaviour and is documented in the manual. At the terminal type man 8 mount:

-r, --read-only

Mount the filesystem read-only. A synonym is -o ro. Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, Ext3 or ext4 will replay its journal if the filesystem is dirty. To prevent this kind of write access, you may want to mount ext3 or ext4 filesystem with "ro,noload" mount options or set the block device to read-only mode, see command blockdev(8).

So the chances are you are mounting ext4 (or similar) and it is making expected changes.

5
  • Thanks so much for shedding light on noload. In the context of a read-only file system, are there any negative side effects to using noload? Commented Mar 2, 2021 at 23:32
  • @sunknudsen that depends. If the filesystem is "clean" and only ever mounted readonly/noload then it should be fine. The warnings in the manual refer to what happens when a readwrite filesystem was not unmounted cleanly and then mounted readonly/noload: "skipping the journal replay will lead to the filesystem containing inconsistencies that can lead to any number of problems." Basically the journal is there to protect corruption while the file system is being modified. So if it's never being modified it can effectively be ignored. Commented Mar 2, 2021 at 23:50
  • I tried appending ,noload in /etc/fstab after ,ro which triggered a "You are in emergency mode" error when booting Raspberry Pi OS. Would you happen to know what might trigger this? Commented Mar 3, 2021 at 0:40
  • Btw, perhaps it has something to do with me enabling "Overlay File System" simultaneously? Commented Mar 3, 2021 at 0:41
  • @sunknudsen I can't say I've seen that one before. Sorry. Commented Mar 3, 2021 at 1:03

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.