Installing an extension located in /tmp - can tce-load be used?

[bigpcman]

Now that I have figured out how to use "rsync" and "squashfs" to create a custom extension I am wondering if there is a way to use "tce-load" to install the extension rather than having to manually move the extension from /tmp to".../tce/optional and creating a new entry in "onboot.lst"

I suppose I can have squashfs send the output directly to .../tce/optional. Anyway I'm just curious as usual.

[vitex]

tce-load -i /path/to/your.tcz

[bigpcman]

tce-load -i /path/to/your.tcz

I had tried that already. Nothing seems to happen.

Code: [Select]

tc@box:/tmp$ ls
aberr              fetch_result       package/           tcloop/
audit_results.txt  myext.tcz          tce/               wm_errors
tc@box:/tmp$ tce-load -i myext.tcz
tc@box:/tmp$ cd /mnt/sda1/tce/optional/
tc@box:/mnt/sda1/tce/optional$ ls
opera.tcz                       rsync.tcz.md5.txt
opera.tcz.md5.txt               squashfs-tools-4.0.tcz
popt.tcz                        squashfs-tools-4.0.tcz.md5.txt
popt.tcz.md5.txt                tce.db
rsync.tcz                       tce.lst
rsync.tcz.dep
tc@box:/mnt/sda1/tce/optional$
Here's another try with full path to /tmp:

Code: [Select]

tc@box:/tmp$ tce-load -i /tmp/myext.tcz
sudo: /etc/sudoers is not a regular file
tc@box:/tmp$ sudo tce-load -i /tmp/myext.tcz
sudo: /etc/sudoers is not a regular file
tc@box:/tmp$

Here's my file list:
tc@box:/mnt/sda1$ cat myfilelist.lst
home/tc/.profile
home/tc/.wbar
etc/shadow
etc/sudoers

[vitex]

"tce-load -i" works for me.

Have you verified that your extension was built correctly?  Have you ever loaded your extension successfully?  Do you see your extension listed if you execute "df"?

Try the following:

Code: [Select]

mkdir /tmp/squashfs
sudo mount -t squashfs /tmp/myext.tcz /tmp/squashfs -o loop
ls -lR /tmp/squashfs

That is essentially to process that tce-load performs.  You should see a directory listing for the files in your extension.

[bigpcman]

I tried a simple test by moving an existing "ondemand" extension to /tmp and then executed tce-load. Here are the results:

Code: [Select]

tc@box:/mnt/sda1/tce/optional$ sudo mv 915*.* /tmp
tc@box:/mnt/sda1/tce/optional$ cd /tmp
tc@box:/tmp$ tce-load -i /tmp/915resolution.tcz
Intel 800/900 Series VBIOS Hack : version 0.5.3

ATI chipset detected.  915resolution only works with Intel 800/900 series graphic chipsets.
tc@box:/tmp$ cd /mnt/sda1/tce/optional/
tc@box:/mnt/sda1/tce/optional$ ls
opera.tcz          popt.tcz.md5.txt   rsync.tcz.md5.txt
opera.tcz.md5.txt  rsync.tcz          tce.db
popt.tcz           rsync.tcz.dep      tce.lst
tc@box:/mnt/sda1/tce/optional$

It looks like the extension was "executed/installed" but was not placed in the "optional" directory and "onboot" was not updated.

edit: Upon further examination and after repeating the above with the tightvnc extension I see the extensions are installed in /usr/local/tce.installed but they are not in ".../tce/optional".

[vitex]

It looks like the extension was "executed" but was not placed in the "optional" directory and "onboot" was not updated.

That is not the way things work. 

Executing "tce-load -i" installs an extension by loop mounting the squashfs in the .tcz as a directory system top of the directory /.  If the installation is successful, you should see /tmp/tcloop/myext if you execute "df". 

Tce-load does not place the .tcz in /tce/optional and add its name to onboot.lst; you must do those things if you want your extension loaded during the boot process.

[bigpcman]

[Tce-load does not place the .tcz in /tce/optional and add its name to onboot.lst; you must do those things if you want your extension loaded during the boot process.

That was what I was trying to figure out. I know the -w -i options will download extensions and place them in "..tce/optional" so I was hoping there was a way to do this when the file was locally available.

Alrighty then I will add the manual operations to my custom extension build process. This ends up being simply the entry in the "onboot.lst" file and even that is not needed if the extension is used in the ondemand mode. This was a whole lot of fuss about nothing. Thanks for the help.

[vitex]

Alrighty then I will add the manual operations to my custom extension build process. This ends up being simply the entry in the "onboot.lst" file and even that is not needed if the extension is used in the ondemand mode. This was a whole lot of fuss about nothing. Thanks for the help.

As I recall, one of the reasons for your building an extension was to back up a set of personal files.  Now that you are comfortable using rsync to gather your files together, you could have rsync copy those files to a directory in persistent storage and add a call to rsync  to /opt/bootlocal.sh to restore those files whenever you boot.  Rsync is smart enough to only copy those files that have been changed.  It can also do network copies and incremental backups.

[bigpcman]

Alrighty then I will add the manual operations to my custom extension build process. This ends up being simply the entry in the "onboot.lst" file and even that is not needed if the extension is used in the ondemand mode. This was a whole lot of fuss about nothing. Thanks for the help.

As I recall, one of the reasons for your building an extension was to back up a set of personal files.  Now that you are comfortable using rsync to gather your files together, you could have rsync copy those files to a directory in persistent storage and add a call to rsync  to /opt/bootlocal.sh to restore those files whenever you boot.  Rsync is smart enough to only copy those files that have been changed.  It can also do network copies and incremental backups.

Yes you are right. This is an excellent idea especially if compression is used. I'll play around with rsync some more.

However, it seems to me I went down the path of using simple cp commands in bootlocal.sh a long time ago. I think I got in trouble with timing. Files like shadow, sudoer and profile needed to be loaded before bootlocal executed program startup commands. That was a long time ago so I don't remember the details.

[^thehatsrule^]

Just curious, what kind of file is your sudoers ? (i.e. `sudo file sudoers`)

I thought it was just a plain text file.

iirc the links generated by loading will not override existing files.

[bigpcman]

Just curious, what kind of file is your sudoers ? (i.e. `sudo file sudoers`)

I thought it was just a plain text file.

iirc the links generated by loading will not override existing files.

I'm not quite sure what you are getting at. I'm referring to the /etc/sudoers file. Are you saying rsync will not overwrite it?

[vitex]

Yes you are right. This is an excellent idea especially if compression is used. I'll play around with rsync some more.

As far as I can tell, rsync can compress files while copying (to conserve network bandwidth), but the files are uncompressed before being stored at the destination.

However, it seems to me I went down the path of using simple cp commands in bootlocal.sh a long time ago. I think I got in trouble with timing. Files like shadow, sudoer and profile needed to be loaded before bootlocal executed program startup commands. That was a long time ago so I don't remember the details.

Putting your restore script in the tce.installed file of a dummy extension is one way to restore your files earlier in the boot process than bootlocal.sh runs.

[bigpcman]

Putting your restore script in the tce.installed file of a dummy extension is one way to restore your files earlier in the boot process than bootlocal.sh runs.

Indeed, I have been investigating this. Seems it requires a remaster to have the script present when tc-config executes it?

[vitex]

Indeed, I have been investigating this. Seems it requires a remaster to have the script present when tc-config executes it?

I would build an extension that contains nothing but the tce.installed script.  You could remaster to put the extension in /opt/tce or just save the extension in your persistent tce directory.

[^thehatsrule^]

Just curious, what kind of file is your sudoers ? (i.e. `sudo file sudoers`)

I thought it was just a plain text file.

iirc the links generated by loading will not override existing files.

I'm not quite sure what you are getting at. I'm referring to the /etc/sudoers file. Are you saying rsync will not overwrite it?

I was referring to the error

/etc/sudoers is not a regular file