Seeking location of code instructing TC to seek save data, PPI, PPR on boot

[slo.sleuth]

I am working on a forensic project and wish to disable TC from automatically mounting and searching attached storage devices for save data, PPI and PPR on boot unless explicitly instructed in boot codes.  

Can someone please tell me what boot script controls this behavior?  Is it just what I find in /etc/init.d/rcS or is there something else to watch for?

Thanks,
slo.sleuth

[gerald_clark]

Add "base norestore" to the boot codes.

[slo.sleuth]

Add "base norestore" to the boot codes.

Yes, thank you, that is a temporary fix, but I am looking to hard code this to avoid accidental mistakes, however unlikely.

[maro]

Why don't you read '/etc/init.d/tc-config' carefully and just take out those parts that could cause side-effects for your intended purpose?

In the end relying on a boot code (which are in most cases are evaluated in said file) still bears the risk that someone finds a work-around, but when the respective handling routine is remove this "risk" is gone. Obviously changing that file (or any other from the initrd) requires a remastering of the initrd.

[slo.sleuth]

Why don't you read '/etc/init.d/tc-config' carefully and just take out those parts that could cause side-effects for your intended purpose?

Thank you, maro, that is just what I ended up doing.

I read through the /etc/init.d/tc-config script which calls /usr/bin/tc-setup at line 453 if boot option "base" is not given. 

Line 43 of /usr/bin/tc-setup calls the "autoscan" function from /etc/init.d/tc-functions at line 117 which in turn calls the "find_mountpoint" function at line 73 in the same file.  It is the find_mountpoint function that determines partitions and supplies mount points back to the autoscan function.  autoscan then mounts each partition and searches for the /etc directory on root before unmounting.

So, it looks like if I comment out line 43 of /usr/bin/tc-setup, then I remove the automatic mounting and scanning of attached devices for /tce directories and accomplish my goal.  Please let me know if I have overlooked something, and/or I will report back if I discover more.

[gerald_clark]

Or add a line near the top:
ONLYBASE=1 ; NORESTORE=1

[slo.sleuth]

Or add a line near the top:
ONLYBASE=1 ; NORESTORE=1

That's a possibility, but i'd like to retain the ability to explicitly set a tce/ directory, which I think the mod I propose will still accommodate.   Your suggestion would trump that.  I'll be testing over the next day or so.

[slo.sleuth]

So, it looks like if I comment out line 43 of /usr/bin/tc-setup, then I remove the automatic mounting and scanning of attached devices for /tce directories and accomplish my goal.

Well, on first blush, commenting out line that is not the solution, because it failed to load the /tce dir on my iso.  More code review ahead...

[gerald_clark]

You said you wanted to prevent users from finding a workaround.
You really need to make up your mind.

[slo.sleuth]

You said you wanted to prevent users from finding a workaround.
You really need to make up your mind.

Sorry, I didn't fully explain myself in this thread.  I am developing a forensic edition of TinyCore.  I have remastered it already, changing mount options in rebuildfstab.  The goal is to prevent TC from mounting storage devices read/write by default.  However, tc-options was still mounting partitions rw that had a /tce folder in the root.  I wanted to change this default behavior, forcing users to expilicity choose a save partition if that is desired rather than explicitly avoid the mounting and searching behavior.

The remaster will have forensic tools not in the repository, but I will build the extensions and submit them as I go.  I'd prefer to have the modules outside the rootfs for easy updating without the need to decompress/recompress tinycore.gz.  Thus they need to be in /tce.

My current modification to tc-setup worked, just unexpectedly (though I should have anticipated it) didn't discover and mount the /tce directory in my iso.  I can explicitly call it as a boot option, but the users of my iso are unskilled in Linux and this is not my first preference.

I can build the modules into the rootfs and configure TC to find them there, which might be my best option, or I can change the detection to mount read-only since I don't expect the users of this specialty iso to make persistent changes.

I'll continue to explore the issue, but I thank you for you interest and suggestions.

[tinypoodle]

You said you wanted to prevent users from finding a workaround.
You really need to make up your mind.

Sorry, I didn't fully explain myself in this thread.  I am developing a forensic edition of TinyCore.  I have remastered it already, changing mount options in rebuildfstab.  The goal is to prevent TC from mounting storage devices read/write by default.  However, tc-options was still mounting partitions rw that had a /tce folder in the root.  I wanted to change this default behavior, forcing users to expilicity choose a save partition if that is desired rather than explicitly avoid the mounting and searching behavior.

The remaster will have forensic tools not in the repository, but I will build the extensions and submit them as I go.  I'd prefer to have the modules outside the rootfs for easy updating without the need to decompress/recompress tinycore.gz.  Thus they need to be in /tce.

There is a way to avoid the need of /tce and to place extensions into rootfs without any need of remastering tinycore.gz on each minor version upgrade.

http://wiki.tinycorelinux.com/Dynamic+root+filesystem+remastering

[slo.sleuth]

There is a way to avoid the need of /tce and to place extensions into rootfs without any need of remastering tinycore.gz on each minor version upgrade.

http://wiki.tinycorelinux.com/Dynamic+root+filesystem+remastering

Thanks for reminding me of that possibility!  It might very well be the ideal scenario.  When I first read it on the wiki, I confess that I didn't fully understand it, but after a little time with remastering TC under my belt, I think I get it now.