Please clarify tce-load rules in bootlocal

[bigpcman]

Robert: TC uses a different default shell than DSL. However, I don't understand why one would want to manually maintain and load extensions from bootlocal.sh when there are already the options of autoloading at boot or manually loading from optional directory. All extensions load before /opt/bootlocal.sh is started. In fact as I pointed out in the opera/flash thread that order of tces before tczs are important. So what would be the benefit of delaying extension loading? It would seem to me to have more of a 'timing' issue? Perhaps not backgrounding /opt/bootlocal.sh would be better? I have no issue with my wireless extensions in tce directory and configuration in /opt/bootlocal.sh Given the fact that autoloading the wireless extensions from tce directory then manually running your script is successful would suggest no need to  move extension loading.

So is the conclusion that tce-load will not work (ever) in bootlocal?

I was planning on creating custom boot codes that a bootlocal script would parse from cmdline to then load different environments. For instance for environments dedicated to things like multi-media development, a local web server, or browser banging.  Each environment would have it's own collection of extensions.

This also would require a tcz-load command as well - does it exist?

[roberts]

You can achieve the same effect with named tce directories which are ready to use/

Example:

tce=hda3/Multimedia

or perhaps

tce=hda3/Office

or maybe

tce=hda2/Lamp

You can still place your custom boot codes in /opt/bootlocal.sh and check bootcode tce

You would likely have these "collections" in spearate directories anyway or even in separate partitons.

[^thehatsrule^]

So is the conclusion that tce-load will not work (ever) in bootlocal?

If you just want to do this for a technical perspective, you can log in as user tc.

This also would require a tcz-load command as well - does it exist?

tce-load works transparently for all extensions.

[bigpcman]

Thanks for the ideas. I like to conserve space so I keep all the extensions in the optional directory. This way I don't have to be concerned with duplicated extensions in multiple directories. For example emelfm2 and flash share many of the same support extensions. I have to admit there is also a bit of convenience in just typing  mm as a custom code instead of tce=hda3/mm.

Regarding

^thehatsrule^: If you just want to do this for a technical perspective, you can log in as user tc.

Do you mean within the bootlocal script as in "su tc tce-load..." ?

I thought I read in a post that did not work. If there is a way to be user tc within the bootlocal script that would great.

[bigpcman]

Well, I' beginning to understand the complexity of loading extensions via the  bootlocal script. I entered the command :

Code: [Select]

sudo -u tc tce-load /mnt/sda1/tce/optional/emelfm2.tcz
in the bootlocal script which did indeed load at bootup the extension in the /usr/local/tce.installed directory just as it normally does but since there is no xsession running yet for user tc the menu and wbar entries don't go anywhere (based on trying it) and executing emelfm2 via a command line doesn't work either so I guess other things failed to setup as well. I'm beginning to understand how clever Robert's boot script is.

However, if I run the commands in the xsessions setup after the tc xsession has completed the extension load will repeat every time the tc user logs out and back in which I'm assuming is not good either.

So the question is how do get a script to automatically run once after bootup and after the tc user xsession is setup? Does this end up being a job for cron?

[^thehatsrule^]

This way I don't have to be concerned with duplicated extensions in multiple directories. For example emelfm2 and flash share many of the same support extensions.

Could try using symlinks (or hardlinks), if supported

I have to admit there is also a bit of convenience in just typing  mm as a custom code instead of tce=hda3/mm.

Could use a bootlabel, menu, etc. (or whatever your bootloader's options are called) that's an alias for tce=hda3/mm

Code: [Select]

sudo -u tc tce-load /mnt/sda1/tce/optional/emelfm2.tcz
in the bootlocal script which did indeed load at bootup the extension in the /usr/local/tce.installed directory just as it normally does but since there is no xsession running yet for user tc the menu and wbar entries don't go anywhere (based on trying it) and executing emelfm2 via a command line doesn't work either so I guess other things failed to setup as well.

Could be how sudo is set up, and how it retains some of the calling root environment - there might be options... or try `su` as in your earlier post (su -c mycommand tc).

However, if I run the commands in the xsessions setup after the tc xsession has completed the extension load will repeat every time the tc user logs out and back in which I'm assuming is not good either.

So the question is how do get a script to automatically run once after bootup and after the tc user xsession is setup? Does this end up being a job for cron?

I think that if the extension sees the name entry in tce.installed it doesn't re-install it, though you could use a similar marker to check for all instead of running tce-load through them.

[bigpcman]

I think that if the extension sees the name entry in tce.installed it doesn't re-install it, though you could use a similar marker to check for all instead of running tce-load through them.

As it turns out the sudo -u tc ... command does indeed load the extensions with the ability to execute them through the command line. So all that's left to solve is the menu and wbar entries.

In Looking at Robert's scripts, it seems desktop.sh should be taking care of the menu and wbar entries so this may be where things are going haywire.
 
Anyway, could you please explain what you meant by "you could use a similar marker..." , I don't get what you mean.

[^thehatsrule^]

Perhaps a code example might be easier to explain

Code: [Select]

if [ ! -f /tmp/.startupmarker ]; then
  # do extra startup stuff here...
  touch /tmp/.startupmarker
  chmod 0 /tmp/.startupmarker
  # could 'lock' the file here, ie with chattr, but that doesn't seem to be available in default TC
fi


[webb]

I find using tce-load on non-critical extensions in bootlocal.sh to be an excellent way to speed up the startup process. I had to try it many ways to get it to work, but this works (for me):
Add to bootlocal.sh:

Code: (bash) [Select]

ls /mnt/sda5/tce/optional/*.tcz | xargs -n1 sudo sudo -u tc tce-load -i(Note: contrary to what bigpcman wrote, sudo -u tc doesn't work (for me). I had to use sudo sudo -u tc. Perhaps this is because I am using the user=webb bootcode.


I recommend adding this feature to base tce, via an afterboot.lst alongside onboot.lst in tce/ .
First, in bash:

Code: (bash) [Select]

ls --color=never /mnt/sda5/tce/optional/*.tcz | xargs -n1 basename > /mnt/sda5/tce/afterboot.lst
Then, add to bootlocal.sh:

Code: (bash) [Select]

cat /mnt/sda5/tce/afterboot.lst | xargs -n1 sudo sudo -u tc tce-load -i
Efficiency could be increased by pruning afterboot.lst to stop tce-load from trying to load already-loaded dependencies of previously loaded extensions. Sorting extensions by size when creating afterboot.lst works ok.

Best,
Webb