Why is there a "write" to microsd on the very first boot? about seedsigner-os HOT 6 CLOSED

This explanation is perfectly reasonable! Thank you!

Thanks for your time and the enthusiasm with this! :)

Please feel free to Close the Issue if you think that it get solved to you.

from seedsigner-os.

@jdlcdl Thanks for your research on this.

That is probably because of "Dirty bit". We actually remove the MicroSD without umounting it from system...
Long time ago, we were talking about to remove MicroSD manually or not. And we end up to do it without umounting it, to be easier for all users. "Just power ON and release MicroSD".

True it adds a single bit, which changes the hash of all MicroSD:

inode.c

But the good news are that the files integrity still in ALL files. They still have the same hash even having the "Dirty bit".

This can be probably solved umouting manually, but all users will need to umount it manually and probably isn't that handy for user experience.

The best approach I could do, is to verify the files hashes with something like:

sha256sum * 

Here goes mine from https://github.com/SeedSigner/seedsigner/releases/download/0.5.1_EXP/SeedSignerOS_0_5_1_EXP.img:

f4c9a9f6556ea3d24ffb216bb7f9c512035fae15a4c9c89c42b53a4f86f55017  bcm2708-rpi-b.dtb
3cc3738d3470e0d193222268628e65e015792c6c2ae061571eed84b4b1d5b11a  bcm2708-rpi-b-plus.dtb
29e5cf16a2ccd6f78cce9639c936405583f82fafb16a8afb34bc0fcf5c774382  bcm2708-rpi-zero.dtb
bb9cda6053e34057bd8e61e2431c41c4aef41f1b31fd9606a6e4e496b7617ae2  bcm2708-rpi-zero-w.dtb
4c0b766693d7e7e90e5b89c1edbfaee8fa957973ab1169940bbe79aedd2b43ba  bcm2709-rpi-2-b.dtb
b008b8809587cccc5d949baa17dfd769e4ae23b45c15317de64423e4942f0c44  bcm2710-rpi-3-b.dtb
e9edb014025f05c5fa746a6e8a925f4ea3695d631dda0bfb9bd502aa76f20b7c  bcm2710-rpi-3-b-plus.dtb
2f094dba5607251c0e73cf01c865deba6bd199a4fdd45acf6b942952df3d33db  bcm2710-rpi-zero-2-w.dtb
b5072dbcaa1d2d92d9e4ac382fe030ad7c3bde203f1f12e75aa3c80f80ef963c  bcm2711-rpi-4-b.dtb
7d2c9ba22bddb57d24d56bbf6b0a073eb389d5dd6e58b45379fae2a67ce6c241  bcm2837-rpi-3-b.dtb
69309823da13dc96b89e3d82b44f820e4f84efa79d207adad2c8784559794f03  bootcode.bin
f717f8ddd291ec4a6cf6d0808c61cf65ef9453ed68deddfbf78fd37036c701f4  cmdline.txt
95a6bdc89000d71bdd57143e402fae84818ff404349c318b71418e99ef36f446  config.txt
5837c8f36125e593006d7ee2bbded46a596ac5641bcfc4b2951b934522bd52cf  fixup_x.dat
f9773f18f318e6e1254d5ba9b41753fdd944dab6076219526d3879cfc2f749df  start_x.elf
83ee666b2fd309abb9ab061cd145707731a8a3874648b2ca8972cf0b2259cc9b  zImage

Ping @newtonick @SeedSigner in case they want to add someting about this.

from seedsigner-os.

This explanation is perfectly reasonable! Thank you!

from seedsigner-os.

Btw: this is repeatable.

I can zero my microsd card, then write my custom version of seedsigner onto and even extract the exact hash that matches that file.

If I boot once, fully, and do nothing, then yank it... I get a different hash when I check my microsd.

I can do this again and again, I always end up with a changed hash that matches the last time I tried this.

It is not at all worrisome to me, because after that first boot, it stops changing. I'm just hoping to be able to explain it.

from seedsigner-os.

If it is at all helpful,

sudo dd if=/dev/sdf bs=35652096 count=1 | cmp -l - ~/Downloads/seedsigner_0_5_2.img gives me:

     550   1   0
1+0 records in
1+0 records out
35652096 bytes (36 MB, 34 MiB) copied, 1.75199 s, 20.3 MB/s

I read that as the only write that is occurring on first boot is that byte 550 (knowing cmp starts at index 1) is being changed from 0x00 to 0x01

I can confirm that if I change that byte from 0x00 to 0x01 in the original custom 0_5_2 for pi2 image, I am getting the same hash that I pull off my microsd card after the first boot. This is what it looks like in hexedit (we're looking at byte 0x225 here because hexedit starts at 0).

from seedsigner-os.

https://forum.cgsecurity.org/phpBB3/viewtopic.php?t=1791

No idea if this is related, but in this thread, someone is talking about 0x41 not being the same, and that's the same byte before the 0x29 that I'm seeing. Some talk of a "dirty bit" in boot sector to signify that something was not written correctly in the past?

from seedsigner-os.