I can see on a Debian system that there is /etc/init.d/mountoverflowtmp which is designed to mount a tmpfs on /tmp even when /etc/fstab doesn't call for one in case there is very little space available on /. It seems unlikely that this is what you are encountering (how much free space do you actually have in /?) but can you check for that? It is the only thing that I can see in the init scripts that could be responsible for that.
–
CeladaAug 12 '12 at 22:54

26Gb free on /. will check that script to see if there's more hints. thanks! EDIT: you're right... found this part "If root is read only, default to mounting a tmpfs on /tmp, unless one is due to be mounted from fstab." very weird behaviour... don't know why it would need /tmp before the fs checks and remount as rw.
–
gcbAug 12 '12 at 22:59

Good catch on the read-only thing. That's funny. I should have thought the root would be remounted rw during execution of S35mountall.sh or earlier, which comes before S37mountoverflowtmp in sequence.
–
CeladaAug 13 '12 at 0:45

What are you actually trying to do? Increase the size of the automatic tmpfs you get for /tmp? A writable /tmp is needed for lots of things so I can understand why it gives you a tmpfs for it if there isn't one already. /etc/fstab is far from the canonical place to list everything that will ever be mounted and has been for a long time.
–
grifferzAug 13 '12 at 2:42

what's RAMTMP? a kernel option during compile time? boot option? the linked wiki mentions it without further explanation, and a search only leads me to flamewars on bug reports if it should default to yes or no :)
–
gcbAug 13 '12 at 4:53