mjhjmtu

When the 4.9 Linux kernel boots and recognizes the presence of and MMC partition, does it alter the partition in any way if the partition is not mounted?

I pre-calculated the sha256 of a "filesystem.img" at build time (ext4.)

I apply my file system to an MMC partition as follows:

dd if=myfilesystem.img of=/dev/mmcblk0p2 bs=4096 count=XYZABC 

I can read the partition back and verify that the flash was correct:

dd if=/dev/mmcblk0p2 bs=496 count=XYZABC | sha256sum

Journaling is disabled. I can manually mount the file system read-only and unmount as much as I want. The sha256 remains the same.

However, if I reboot and run the checksum again, the sha256 on the partition comes out different. The partition I wrote to before rebooting is not mounted. But it is recognized as mmcblk0p2 by the kernel.

Does the kernel alter the data in a partition in any way before it is mounted?

Which distro / environment are you booting exactly?

It could be as simple as a filesystem check that just updates the last-checked timestamp. Instead of taking a hash sum, it would be more interesting to make a 1:1 copy and then compare them byte-by-byte (cmp -l) to find out what exactly changed.

Usually, it's not the kernel modifying the filesystems, but whatever userland you are booting into. Most LiveCDs (Live-USB-Sticks), even those made for rescue purposes, modify filesystems by mounting them in search of their own live data. With systemd/udev, there is also a lot of magic happening in the background that you might not be aware of.

If you are able to modify initramfs / early boot, try setting /proc/sys/vm/block_dump before anything else and you might get some surprises regarding what's writing where in dmesg.

Note: this will cause issues if you are already logging kernel messages to disk, as each write would cause another write for the log alone.

I can manually mount the file system read-only and unmount as much as I want.

Even a read-only mount doesn't always guarantee no-change:

# truncate -s 100M foobar.iso
# losetup --find --show foobar.iso 
/dev/loop0
# mkfs.ext4 foobar.iso
# md5sum foobar.iso 
59dea589bb84855e282d1415b3238230 foobar.iso
# mount -o ro /dev/loop0 loop/
# md5sum /dev/loop0
47c89177d619b55b701a1ddbde352c90 /dev/loop0

What happened here? No idea, really...

--- a.txt 2018-12-26 20:39:13.578096660 +0100
+++ b.txt 2018-12-26 20:39:18.444742584 +0100
@@ -1536,11 +1536,10 @@
 *
 03000400 c0 3b 39 98 00 00 00 04 00 00 00 00 00 00 04 00 |.;9.............|
 03000410 00 00 10 00 00 00 00 01 00 00 00 01 00 00 00 00 |................|
-03000420 00 00 00 00 00 00 00 00 00 00 00 12 00 00 00 00 |................|
+03000420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
 03000430 15 de d5 f7 6f 52 43 9b a9 18 9b 3d 28 65 2d 51 |....oRC....=(e-Q|
 03000440 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 |................|
-03000450 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
-03000460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
+03000450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
 *
 03800400 58 64 00 00 00 90 01 00 00 14 00 00 40 6d 01 00 |Xd..........@m..|
 03800410 4d 64 00 00 01 00 00 00 00 00 00 00 00 00 00 00 |Md..............|

If you want to reinforce the read-only idea a little, use mount -o loop,ro, it adds a read-only loop device in between. But even that is no guarantee for anything.