Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: jpeters on June 08, 2009, 01:59:29 AM
-
There's no /tmp/.tce_dir I'm booting with tce=hda3/tcZ.
-
Its always been /opt/.tce_dir and working fine.
I am booting with tce=sda1/tcZ
-
tce-wget:
TCEDIR="$(cat /tmp/.tce_dir)"
-
OK. I guess you are the first to use that new little wrapper tce-wget.
-
Sure....now it's officially OK to use the CLI :)
-
Very true, was mostly ignored now its a microcore necessity.
-
Not exactly a bug:
$ lspci
00:00.0 Class 0600: Device 8086:27a0 (rev 03)
00:02.0 Class 0300: Device 8086:27a2 (rev 03)
00:02.1 Class 0380: Device 8086:27a6 (rev 03)
...
..with pci-utils extension loaded:$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
...
Maybe something changed with the way pci-ids is parsed?
-
Our /usr/local always starts out empty. Typically /usr/local/share/ is the location for pci.ids.gz
Try:
lspci -i /usr/share/misc/pci.ids.gz
Of course you may wish to make a link to avoid specifying the location on the command line.
-
A cleaner solution would be lspci which looks in /usr/share/misc.
-
Or even better....run Juanito's pci-utils....can't afford 260 kB?? (cheapskates.... :D )
-
That is where the pci.ids.gz came from, but alas it is compiled to look at /usr/local which for an extension is fine but not in base. So best to recompile for base specs and not extension specs.
Cheapskates, you bet. 260 here, 260 there, is keeps adding up, no more is tinycore 10MB. :'(
-
:-X Even with pci-utils, a complete compile environmnent, 74 loops....., I still have 2/3 of my 512M ram. :)
edit: actually, if I close down skype, several instances of FF, xmms running, etc., I'm down to under 40M used (after adding back the cache & buffers)
-
That is where the pci.ids.gz came from, but alas it is compiled to look at /usr/local which for an extension is fine but not in base. So best to recompile for base specs and not extension specs.
I'll do this in the next day or two - I need to test this, but wouldn't the "lspci" from earlier versions of tc look in /usr if only pci-ids were replaced?
-
I thought this was working earlier. There's no problem with "wget ftp://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/tcz/... but:
tc@box:/mnt/hda3/tcZ2$ tce-load vim_7.1.244.tcz wget install
vim_7.1.244.tcz
wget: server returned error: HTTP/1.1 404 Not Found
md5sum: vim_7.1.244.tcz.md5.txt: No such file or directory
tc@box:/mnt/hda3/tcZ2$ tce-load xonclock.tcz wget install
xonclock.tcz
wget: server returned error: HTTP/1.1 404 Not Found
md5sum: xonclock.tcz.md5.txt: No such file or directory
-
That is where the pci.ids.gz came from, but alas it is compiled to look at /usr/local which for an extension is fine but not in base. So best to recompile for base specs and not extension specs.
I'll do this in the next day or two - I need to test this, but wouldn't the "lspci" from earlier versions of tc look in /usr if only pci-ids were replaced?
I took "lspci" from an earlier rc (2.0rc1) and things work fine - probably the easiest thing to do would be to revert back to this one, which works with the latest pci-ids
-
Reverting back to prior lspci. Will be in 2.1rc1.
-
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 :
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.
-
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.
-
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 :
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
case $APP in
*.tce* ) sed -i 's/tcz/tce/g' /opt/.tcrc ;;
*.tcz* ) sed -i 's/tce/tcz/g' /opt/.tcrc ;;
esac
-
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 :
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
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?
-
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.
-
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.
-
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
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??'
-
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
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.
#!/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.
-
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.
-
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.
-
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.
-
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.