Can not permanently mount /tmp in tmpfs, RAMTMP in /etc/default/tmpfs is igored

[mkreisl]

I want to mount /tmp as a tmpfs Filesystem. To do this I added an entry in /etc/fstab file. But after each running of xbian-update, this entry is removed. Then I looked in /etc/default an found a file called tmpfs, in which it can be configured - theoretically. The entry RAMTMP seems to be ignored, and the files in /lib/init/ seems never to be used. Modifying /etc/init/mountall.override (adding post-start script) does the job, but will probably be overwritten by xbian-update Oh, that's terrible: /etc/default/tmpfs will be also overwritten by xbian-update. Is there another way to configure it?

[mk01]

@mkreisl

you could be right..., this should be aligned up to the standard Debian docs, or simply we should remove the custom code taking care of tmpfs's (/dev, /run, /tmp, /tmp/shm ...).

((better aligned to standard, by removing we would rely (in case of upstart) on mountall process - which works, but quite slow and late for use in embedded devices)). when XBian was migrating to upstart, Debian (wheezy) was still (and IS) primarily a SYSV kind of process/job control system (and that was also a REQUIRED behaviour for all system-level tools and packages - including upstart and it's toolchain what means literally 2 steps ahead and then 1 step back).

That means /dev, /run and /tmp are by definition FIXED folders, /run is just symlink to /var/run, kernel without dynamic /dev content building (no dynamic dev management - so usage of busybox/mdev or as late as udevd from runlevel2 - and other prehistoric designs.

now it is already changed with jessie (of course kernels and udev->systemd too), still not that effective (and IN order) as we need (meaning without fully generated /dev we cant start IR modules before fast XBMC load, what ever daemon started BEFORE all tmpfs are properly provided will make them stop working properly - as tmpfs /run and /tmp will mount OVER already created pipe files, tmp files, internal status data etc).

So let's keep statusQ for now, even for Jessie (the current job control and XBian injections work the same expected and tested way also in Jessie (with again diverged design a bit by forced use of systemd). With sid we can reassess again.

If you can/are willing to debug/fix alone: In case XBian boots via initramfs - tmpfss are handled at the begginging of initramfs/init script (template used for initramfs generation is at /etc/xbian-initramfs/init), then are with full generated content moved properly to new root. In case of booting directly (and root being mounted by kernel direct), /dev/ is handled (and content generated) by kernel itself (in initramfs case by kernel too), others (run, shm, tmp, ...) is taking care of in /etc/init/xbian-run (which is in both cases FIRST job started - that override defined from cmdline (--startup-event mountall)).

I can later this week look into it too. But in case you manage - feel free to fix the TMPFS, only keep in mind the memory pressure which can happen by accidentally misconfiguration on user side with combination with bugged binary (flooding /tmp), or even not properly updated service/daemon/script TO NEW guidelines which require NOT using /tmp for temporary files creation anymore (due exactly to the possibility that system will be configured - as properly allowed - to provide /tmp in memory).

((as example - even ON JESSIE try "tempfile". it creates by default the name/file exactly inside /tmp. and it is not uncommon to do (even by myself).

dd if=/dev/XXX of=$(tempfile)

you can imagine the consequences. or even more standard usage pattern having after some days ~20-40mb of waste i /tmp. not "that" much - only imagine impact of that on users running RPI1 with 256mb total ram. So fix yes, but let's put upper limit and maybe log via syslog interface in case the size is clamped by us - for users like you who will investigate why the size is not as requested. you can use simple "logger" for it.

logger --help

(the initramfs files (/etc/xbian-initramfs/*) are part of xbian-package-initramfs repo (and package), all inside /etc/init comes as overrides (or extra) files via xbian-update (pkg and also repo name) - in case you open pull requests. feel free to push your idea, we can always adapt by adding more and more commits by you pushing to your clone (after pull request is opened).

[mkreisl]

@mk01 Thank you for your excellent answer. It will take a little bit time to understand everything you wrote. Currently I have "solved this issue" for my own, because now I know the behavior of this and I can workaround this. It is not perfect, but I can live with this at the moment. But one thing should be changed imho: The file /etc/default/tmpfs will be hard overwritten by xbian-update without any notice. It makes no sense to put a file in /etc/default which always will be reset to a factory default

[mk01]

I pushed to xbian-update https://github.com/xbianonpi/xbian-update/commit/dcc0fc38416050230343dd0aa50c51a3e3413ab3

this should provide tmpfs for /tmp and fix the overwriting

can you report later ?

[Smultie]

@mk01 could this possibly be related? https://github.com/xbianonpi/xbian/issues/711

[mkreisl]

@Smultie Not here

@mk01 Thank you for this modificatiion. Unfortunately there still exists issues:

1. Running xbian-update prints an error sed: -e Ausdruck #1, Zeichen 27: Unbekannte Option fürs'`, probably this sed calling in function deployconfig()
2. RAMTMP will be preserved, but all others followed by RAMTMP will be set to default, maybe 1. is responsible for this. My variables were

#TMPFS_SIZE=20%VM
RUN_SIZE=10%
#LOCK_SIZE=1024000
#SHM_SIZE=2048
TMP_SIZE=30%

(TMP_SIZE was uncommented and set to 30%

3. mount command in xbian-run.conf does not accept 20%VM, only 20% works

[mk01]

@mkreisl

exactly that forward incompatibility between pre-wheezy (different format for size and standard use of /etc/default/rcS) and wheezy (no VM suffix, migration to /etc/default/tmpfs) we were force overwriting the setting file - just historical insight.

anyhow, I will fix this, then you can retest.

[mk01]

@Smultie

in some way it seems it is related - but I'm curious what chain is leading to this particular error (what you are experiencing). check your specific configuration, whether you have by any chance RAMTMP set to 'yes'. in files

/etc/default/rcS or
/etc/default/tmpfs

because by default this is set to no and in that case the new added code is not executed so even there is a change, the actual code executed is the same as before this change. (still, I was testing it of course also with yes and had no troubles - only to tell @mkreisl I tested with "50M")

[Smultie]

@mk01 no "RAMTMP=yes" in any of the files with xbian-update 20150407-0) Will try the same after the update of xbian-update 20150408-0.

[Smultie]

Same with xbian-update 20150408-0. But it still doesn't work.

[mkreisl]

@mk01 Hmmm, I don't want to make stress - same behaviour with 20150408-0 Before running xbian-update:

#TMPFS_SIZE=20%VM
RUN_SIZE=10%
#LOCK_SIZE=1024000
#SHM_SIZE=2048
TMP_SIZE=30%

after xbian-update

#TMPFS_SIZE=20%
RUN_SIZE=10%
#LOCK_SIZE=1024000
#SHM_SIZE=2048
#TMP_SIZE=20480

However, no sed error message and no other issues

Oh yeah, the VM in #TMPFS_SIZE=20%VM has been removed

But... in xbian-run.conf it is still there: [ -n "$TMPFS_SIZE" ] || TMPFS_SIZE='20%VM' shoultd better changed in [ -n "$TMPFS_SIZE" ] || TMPFS_SIZE='20%'

[mk01]

@mkreisl

ok, that's odd. as look https://github.com/xbianonpi/xbian-update/blob/master/content/etc/init/xbian-run.conf#L17

also I checked all three boxes I have (all installed 20150408-0) and read the same as should be. can you try

apt-get install --reinstall xbian-update

[mkreisl]

@mk01 20150408-0 is not currently available. --reinstall just installs xbian-update_20150407-0_armhf.deb again :-(, so I can't test it. So I have to wait until a new version arrives ...

[CurlyMoo]

I removed 20150408-0 because users where having issues with it. To test the latest source please clone https://github.com/xbianonpi/xbian-update, run gen.package.sh inside the source folder and install the final deb with dpkg -i.

[mkreisl]

@CurlyMoo Yes, I know that ;-) Ok, I will make my own package an than test it again

[mkreisl]

@mk01 xbian-run.conf is now ok, but IMHO /etc/default/tmpfs will not be managed correctly. For me, function deployconfig() makes no sense, it does only take care of options which are uncommented in template. So right now, there is no chance to uncomment and set options to other values in the file which is already installed. Why don't you take the template if file does not exist and leave file unchanged if it already exists? That's the way I would to it.

[mk01]

@mkreisl

please retest

[mkreisl]

@mk01 Much better :-) Thank you for your quick response. I will try today afternoon a little bit more, now I am too tired ps: if you release a new version, please don't forget removing the set -x

[mkreisl]

@mk01 Tested with 3 different installations (sd-cards) on two RPi-1B, no issue found. Works perfect now, thank's for your excellent work

[mk01]

@mkreisl

what happened is that @CurlyMoo was removing xbian-update packages from APT after fix was pushed so he also removed the correct one. I wanted to test with @Smultie but actually there was nothing to test after all as he had no troubles as well - and the reports speaking of "latest" version were simply just out-of-date (although it does look fresh, apt index is from night and all it's operations are working only on top of this information (of course if "apt-get update" wasn't triggered manually again)).

(still it would be fine to confirm this http://download.serveftp.net/xbian-update20150430-0.deb with few more manual installs, then we will just re-release it again as is/was) @Smultie can you please as agreed manage small test group for this one particular update?

((manual install steps would be:))

cd /tmp
sudo -s
wget http://download.serveftp.net/xbian-update20150430-0.deb
dpkg -i xbian-update20150430-0.deb
reboot

[mkreisl]

@mk01 This version you provide on serveftp still does not work (tmpfs parameters are changed as I already mentioned). The current version on github instead is ok

[mk01]

yes, imagine that. changed. ;) I was somehow in wait mode - just to only click "generate" - and it would go from git anyhow.

I was sure we somehow managed the tmpfs story. @Smultie should assure it wont break boot o something like the first one.