Dogs are doing their 4am catscan of the front yard (searching for stray cats in their territory).
Me, well, the old say, idle hands ....
Observations on reading mrinstaller.sh:
Your sourcing /etc/rc.d/functions twice for legacy devices.
The commands:
mount -o,remount rw <device>
Does not return an error if already mounted rw;
Does not return an error if mounted ro and succeeds in changing to rw
I.E: return code == 0 it either did it or it already was
mount -o,remount ro <device>
Does not return an error if already mounted ro;
Does not return an error if mounted rw and succeeds in changing to ro
I.E: return code == 0 it either did it or it already was
AND there is no call reference counting - you only need one rw to change a ro mount, regardless of how many times it was remounted ro.
Same with ro and one or more prior calls to rw.
So I am still pretty sure you can bit bucket all of the awking and greping and other crap from the mntroot script.
You can trust the kernel to 'get it right' without checking up on it.
Note:
Another thing mis-understood by Lab126 when they wrote that script (and repeated here by other posters) - -
Changing the mount status of '/' does not change the mount status of any of the other sub-mounts in the tree.
Those ro/rw status settings are **per mount point** !!
General Note:
There are only two (maybe three) special cases to the above:
The mount point is backed by storage that does not support write (cramfs, squashfs, others) - -
'mount' should return a correct error code, but this is busybox mount - it should be tested to behave correctly.
The mount point is mounted with an errors=ro option and errors have been encountered - -
same as above - 'mount' should return a correct error code
I.E: you can umount and mount a file system with errors but not over ride with the remount option.(*)
Something else to be checked to see if busybox mount gets it correct.
The third case comes up when using network file systems -
Which is going to be a rare case for a Kindle outside of the Lab126 development setup.
(Hmm... which might explain why they wrote mntroot script to begin with.)
A trivia note:
the command:
mount -o,remount <device>
(notice the lack of any ro or rw specification)
will cause the kernel to flush all of that mount point's buffers
(if the backing store supports write, if it hasn't been errors=ro set ro, and for some kernel versions, isn't VFAT
)
Edit:
(*) something about what I wrote in that sentence is bothering me - I may have made a mistake in that description.