Tiny Core 2.0

[roberts]

Reverting back to prior lspci. Will be in 2.1rc1.

[bigpcman]

Is this thread concluding that "tce-load xxxx.tcz wget install" does not work in tc2.0?

When I try to use it I get :

Code: [Select]

wget: server returned error: HTTP/1.1 404 Not Found
md5sum: xxxx.tcz.md5.txt: No such file or directory
If so I can spend my time elsewhere.

[roberts]

No. The discussion was regarding tce-wget a small wrapper script, not tce-load.

There has been no change to tce-load. Note that tce-load uses the content of /opt/.tcrc to know what server, what protocol, and what repository to use.

Perhaps you have a mismatch there. This can happen if you are bouncing back and forth between respositories tce and tcz. Check the contents of your /opt/.tcrc which is normally set by using appbrowser and defaults to tce. It can of course be manually edited.

[jpeters]

Is this thread concluding that "tce-load xxxx.tcz wget install" does not work in tc2.0?

When I try to use it I get :

Code: [Select]

wget: server returned error: HTTP/1.1 404 Not Found
md5sum: xxxx.tcz.md5.txt: No such file or directory
If so I can spend my time elsewhere.

The problem appears to have corrected itself....I posted about it earlier.   Must be an intermittant  issue on the server.

edit: no....it's a bug......as Robert suggested, script alone doesn't change to the correct repository.

Fix: first change to correct repository

Code: [Select]

case $APP in
 *.tce* ) sed -i 's/tcz/tce/g' /opt/.tcrc ;;
 *.tcz* ) sed -i 's/tce/tcz/g' /opt/.tcrc ;;
esac


[bigpcman]

Is this thread concluding that "tce-load xxxx.tcz wget install" does not work in tc2.0?

When I try to use it I get :

Code: [Select]

wget: server returned error: HTTP/1.1 404 Not Found
md5sum: xxxx.tcz.md5.txt: No such file or directory
If so I can spend my time elsewhere.

The problem appears to have corrected itself....I posted about it earlier.   Must be an intermittant  issue on the server.

edit: no....it's a bug......as Robert suggested, script alone doesn't change to the correct repository.

Fix: first change to correct repository

Code: [Select]

case $APP in
 *.tce* ) sed -i 's/tcz/tce/g' /opt/.tcrc ;;
 *.tcz* ) sed -i 's/tce/tcz/g' /opt/.tcrc ;;
esac


Robert did this issue get resolved in tc2.orc1?

[roberts]

I explained that appbrowser sets the rc file (/opt/.tcrc).
Appbrowser calls tce-load. tce-load is a support script for appbrowser.
I had designed such for my personal use in debugging appbrowser.

Now with microcore and further nonGUI use in practice, we have a suggestion for tce-wget as the preferred command line tool.

It would make more sense and be more consistent to have tce-wget set the rc as appbrowser currently does than to set the rc file twice with every invocation of appbrowser.

A change in specifications based on a change in usage, I don't consider a bug.

I notice that the update script has hard coded values rather than using the rc file.
That is another reason for change in specification.

[bigpcman]

I explained that appbrowser sets the rc file (/opt/.tcrc).
Appbrowser calls tce-load. tce-load is a support script for appbrowser.
I had designed such for my personal use in debugging appbrowser.

Now with microcore and further nonGUI use in practice, we have a suggestion for tce-wget as the preferred command line tool.

It would make more sense and be more consistent to have tce-wget set the rc as appbrowser currently does than to set the rc file twice with every invocation of appbrowser.

A change in specifications based on a change in usage, I don't consider a bug.

I notice that the update script has hard coded values rather than using the rc file.
That is another reason for change in specification.

Any command line solution you come up with is fine with me. I look forward to whatever you come up.

[jpeters]

I explained that appbrowser sets the rc file (/opt/.tcrc).

I notice that the update script has hard coded values rather than using the rc file.
That is another reason for change in specification.

The update script does use the rc file, first setting it to the path needed by $APP

Code: [Select]

case $APP in
 *.tce* ) sed -i 's/tcz/tce/g' /opt/.tcrc ;;
 *.tcz* ) sed -i 's/tce/tcz/g' /opt/.tcrc ;;
esac
tce-load $APP  wget install

bigpcman,

You can make a simple script, using the above example....just make APP=$1, save as install,
and run 'install someapp.tc??'

[bigpcman]

I explained that appbrowser sets the rc file (/opt/.tcrc).

I notice that the update script has hard coded values rather than using the rc file.
That is another reason for change in specification.

The update script does use the rc file, first setting it to the path needed by $APP

Code: [Select]

case $APP in
 *.tce* ) sed -i 's/tcz/tce/g' /opt/.tcrc ;;
 *.tcz* ) sed -i 's/tce/tcz/g' /opt/.tcrc ;;
esac
tce-load $APP  wget install

bigpcman,

You can make a simple script, using the above example....just make APP=$1, save as install,
and run 'install someapp.tc??'

If I'm not mistaken, the path for microcore extensions is not created by tce-load correctly using .tcrc. I modified .tcrc with the correct path but that still didn't work. I suspect tce-load is trying to insert tce or tcz ino the wrong place in the path. Actually I do have a a script that works it's just a brute force approach. However, I can't seem to start the X environment after everything is loaded without rebooting. Startx does not bring up the desktop.

Code: [Select]

#!/bin/ash
wget ftp://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release/core_elements/Xlibs.core.tczl -O /mnt/sda1/tce/Xlibs.core.tczl
wget ftp://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release/core_elements/Xprogs.core.tczl -O /mnt/sda1/tce/Xprogs.core.tczl
wget ftp://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release/core_elements/Xvesa.core.tcz -O /mnt/sda1/tce/Xvesa.core.tcz
wget ftp://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/tcz/jwm.tcz -O /mnt/sda1/tce/jwm.tcz
tce-load /mnt/sda1/tce/Xlibs.core.tczl
tce-load /mnt/sda1/tce/Xprogs.core.tczl
tce-load /mnt/sda1/tce/Xvesa.core.tcz
tce-load /mnt/sda1/tce/jwm.tcz
what comes next? startx does not bring up the desktop.

[roberts]

You are still trying to use core elements as if they are regular extensions. They are not.
However if you place core elements in your tce directory then the system will boot into X just as Tiny Core does.

If you have done this setup, and then wish to boot microcore without X, boot it with the text option.

Once microcore has the above setup, then booting microcore with text option, one can start X by simply typing startx

It is really that simple.

[bigpcman]

You are still trying to use core elements as if they are regular extensions. They are not.
However if you place core elements in your tce directory then the system will boot into X just as Tiny Core does.

If you have done this setup, and then wish to boot microcore without X, boot it with the text option.

Once microcore has the above setup, then booting microcore with text option, one can start X by simply typing startx

It is really that simple.

Yes I'm trying to load  the core extensions just like any other after the very first boot up of microcore before the core extensions have been put in the tce directory. I'm just trying to use the tc load-tce wget install tools to load them. If you are saying the tce-load wget install and tce-wget tools are not intended for loading (ever) microcore elements that's OK I'll handle it another way.

[roberts]

core elements are mounted. The extension tools do mount them.
However other processes occur at boot time and in batch mode  that properly setup the system.

Trying to load after boot, would then also mean that every extension is going to be tce-loaded which is not batch mode even when scripted and therefore not efficent.

Choosing to force the system to run in a way that it is not designed will always present challenges.

[bigpcman]

core elements are mounted. The extension tools do mount them.
However other processes occur at boot time and in batch mode  that properly setup the system.

Trying to load after boot, would then also mean that every extension is going to be tce-loaded which is not batch mode even when scripted and therefore not efficent.

Choosing to force the system to run in a way that it is not designed will always present challenges.

Thank you for that explanation, I didn't know that. Alright then I will load the core extensions using the wget with a full path command and reboot. Rebooting my floppy system is a slow process that's why I try to get around it.