Tiny Core Linux
Tiny Core Base => TCB News => Alpha Releases => Topic started by: roberts on May 22, 2010, 01:11:19 PM
-
Please continue testing the alpha versions of Tiny Core v3.0.
Alpha4 is now posted:
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release_candidates/tinycore_3.0alpha4.iso
Change log for alpha4.
* Updated zlib 1.2.5
* updated ncurses 5.7
* Updated sudo 1.7.2p6
* Updated pcmciautils 017
* Updated module-init-tools 3.11.1
* Updated util-linux-ng 2.1.7.2
* Updated libpng 0.43
* Updated libfreetype 2.3.12
* Updated libImlib2 1.4.4
* Updated tc-config, tce-setup, startx, desktop.sh for legacy window manager support of freedesktop and ondemand.
fluxbox, hackedbox, jwm, jwm-snapshot, icewm will soon be posted in the 3.x extension area.
-
Hi!
The new alpha looks great! Haven't run any big testings, but the programs I use seems to work like they should. The most complicated I've done so far was playing pacman on the google site. Good work!
Have fun improving the new 3.0 Tiny Core,
meo
-
Hi again!
Had to try fluxbox and it works just like a charm.
Have fun,
meo
-
Rox-filer extension is broken in Alpha 4
Boot Alpha 4 without any extensions
Install Rox-filer via Appbrowser
The icon shows up but nothing happens when you click it
Boot Alpha 3 without any extensions
Install Rox-filer via Appbrowser
The icon shows up and opens a filer window when clicked
-
I can NOT confirm the reported problem with rox-filer.tcz on TC 3.0alpha4.
It works for me after booting a "plain" system from ISO (no backup, no persistence, i.e. "cloud" mode) both in GUI mode (using the 'wbar' icon or the 'Applications' menu) as well as in CLI mode (via rox from a 'xterm').
-
@roberts: Could that be a typo regarding the libpng version? AFAIK there was a 'libpng-1.2.43' released in February.
-
After further examination I found an "error" in the script that I need to run to load my network card firmware (and I need network access to use the appbrowser): it mounts a persistent home over /home/tc and in that home directory is my ROX configuration directory /home/tc/.config/rox.sourceforge.net
If I don't mount this persistent home ROX does indeed start
For information the offending file that causes rox to not start is
/home/tc/.config/rox.sourceforge.net/ROX-Filer/globicons
This XML file links icons to programs/directories
Why this file is interpreted differently between Alpha3 and Alpha4 is a mystery for me. I will have to examine this further
-
Here is another one of my "silly" observations:
tc@box:~$ echo $PATH | tr ":" "\n" | while read d ; do ls -l ${d}/* ; done | grep -v 'root root'
ls: /usr/local/sbin/*: No such file or directory
-rwsr-xr-x 1 root staff 650048 May 20 2009 /usr/bin/Xvesa
-rwxr-xr-x 1 tc staff 636 Apr 25 14:54 /usr/bin/flwm_topside_initmenu
-rwxr-xr-x 1 tc staff 44 Nov 13 2009 /usr/bin/flwm_topside_restart
-rwxr-xr-x 1 root staff 42044 Feb 28 00:36 /usr/bin/wbar
-rwxr-xr-x 1 tc staff 218 Oct 28 2009 /usr/bin/wbar.sh
I guess it's almost a "matter of taste" whether the initrd should contain all directories included in $PATH. Maybe another question is whether all executables in the "standard" $PATH should be owned by 'root:root' to have some consistency in that regard.
-
@maro:
What happens if, in alpha4 and with a freshly installed ROX, you right-click on a file or directory and select the "Set Icon..." function?
Here it causes the filer window to disappear without warning.
In alpha3 you get the correct behaviour: the Set Icon dialog appears.
-
@maro:
What happens if, in alpha4 and with a freshly installed ROX, you right-click on a file or directory and select the "Set Icon..." function?
Here it causes the filer window to disappear without warning.
In alpha3 you get the correct behaviour: the Set Icon dialog appears.
I confirm this behaviour.
-
Have either of you tried running ROX from the command line to see if it spews out any error messages when setting an icon?
I'm guessing the ROX extension probably needs to be rebuilt against the newer libraries to work properly with this revision of TC3.
-
Rebuilding Rox does not help.
I will look into it further, but let's continue the Rox discussion in the Rox extension thread.
Thanks.
-
Boot Alpha 4 without any extensions
Install Rox-filer via Appbrowser
The icon shows up but nothing happens when you click it
Similar happened to me when I installed GIMP-1 via ab while using icewm (alpha 4). I got a GIMP icon in wbar (with no menu entry) but had to launch it from a terminal because clicking the icon did nothing. Didn't have more time to poke around but will try sometime Sunday.
-
Didn't give any of the earlier alpha's a shot, and haven't been following the threads all that closely, but don't recall seeing this mentioned yet.
Wifi doesn't seem to work correctly for atheros chips.
lspci shows:
03:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
iwconfig correctly shows wlan0 as being a wireless interface.
The command:
sudo ifconfig wlan0 upreturns "Unknown Error 132"
EDIT: Ok, so, apparently linux respects the wireless button on my keyboard now, so this is a non-issue, just an unexpected change in behaviour.
EDIT2: Further to this, it seems that if I reboot, I can't enable wireless again. Hard shutdown is necessary if I want wireless network when TC comes back up.
-
Similar happened to me when I installed GIMP-1 via ab while using icewm (alpha 4). I got a GIMP icon in wbar (with no menu entry) but had to launch it from a terminal because clicking the icon did nothing. Didn't have more time to poke around but will try sometime Sunday.
This is due to: $ cat /usr/local/share/applications/gimp1.desktop
...
Exec=exec /usr/local/bin/gimp
Corrected version uploaded.
@Jason - it might be worth scanning the 3.x repo for similar errors?
-
Problem with openbox on alpha 4: obconf segfaults.
-
Another case of application breakage: galculator
Base Tinycore + fresh install of galculator via appbrowser
- works normally in Alpha3
- doesn't work in Alpha4: "Segmentation fault"
-
@u54749: Have a look at this post (http://forum.tinycorelinux.net/index.php?topic=3858.msg32760#msg32760). I have just done a quick install of 'galculator' with my re-build 'libxml2' library and it appears to not crash with that one.
@althalus: I imagine it could be the same reason for your reported issue.
Since 'gtk2.tcz' depends on 'libxml2.tcz' there could be many other problems. I can't attach the library I've compiled here in the forum (it's too large with ca. 533k), but I'm sure you could either follow my steps (in building your own temporary library) or you just wait until an "official" update has happened.
-
I have recompiled libxml2 myself and can confirm that it solves both the ROX and the galculator issue
-
Since obconf would have to parse openbox's XML config file, I think you're right in that obconf is just one more casualty of libxml2.
-
rebuilding libxml2 as we speak, will be uploaded shortly.
EDIT:
Done.
-
Juanito-
For the desktop file entries, I think we are now at the point where we can deal with them individually as they are found.
-
used boot code local=hda1 and there was acopy2fs.flg in my tce. after TC booted up, there were a bunch of symlinks that would usually point to files in .tcz's mounted on /tmp/tcloop/* , but there were no .tcz's mounted. should this be fixed? I thought this way I would get a persistent /usr/local on my hard. you know, the traditional -install-like mount of /usr/local.
one more thing. i think i saw checkfs option when I pressed f2 or f3 at boot prompt. but there doesn't seem to be such option in /etc/init.d/tc-config.
-
Another small observation: Booting just the TC 3.0alpha3 ISO I thought I saw an additional error message in the terminal from which the X server got started. So I did an 'Exit to Prompt' and could read (apart form the familiar xauth: creating new authority file /home/tc/.Xauthority) the new
ls: /usr/local/share/applications: No such file or directory
Well I guess those files are now in '/usr/share/applications' so a couple of scripts (e.g. 'flwm_topside_makemenu', 'ondemand', 'startx', and 'wbar_icon_upd.sh') are not yet aware of that change.
Edit: small correction and removal of a false claim
-
I already have that fixed. The message is harmless.
It appears when there are no extensions that have menu items, which I wasn't too interested in at the time.
-
@roberts: Thanks, I was not suggesting for this to be a real issue.
@Sandras: I guess your are correct the code for 'checkfs' boot code seemed to be "gone". I had a look through my archived files and I found it last in TC 2.3.1
Regarding your other problem I'm not quite sure what your are trying to achieve, so I attempted something myself to see if I could find anything "outrageously" wrong (I was using QEMU since that allows easy testing of such scenarios, but I dont' think that "real" hardware will behave differently):
(1) First boot from CD-ROM with an freshly formatted hard disk, using boot code 'tce=hda1' to create the required directories. I've installed a small number of extensions and took a "snapshot" of '/usr/local'. This showed all the expected links from '/usr/local/...' into '/tmp/tcloop/...'. Then created the "flag" with touch /mnt/hda1/tce/copy2fs.flg
(2) Next boot from CD-ROM with the prepared hard disk (but not using any boot code). Due to the 'copy2fs.flg' no files were present in '/tmp/tcloop' but all were extracted into the (in-memory) root file system -> exactly as expected.
(3) This time the system got booted with the boot code of 'local=hda1'. The booting took a bit longer and the hard disk got "busy". There was an additional (and entirely expected) mount of '/usr/local' from '/dev/hda1' to be found (binding '/mnt/hda1/tclocal' to '/usr/local'). By now the files had been extracted from the *.tcz files into '/usr/local' (i.e. '/mnt/hda1/tclocal'). I'm not sure what that is meant to achieve, to have the squash-fs files and the extracted content on the same disk. So I assume my test is not what you had in mind. Nevertheless I believe it all worked as it should have done.
I've done a few more tests and none of them showed anything unexpected. So maybe you could describe what result you are after.
-
@Sandras: try again with a fresh local? It could be that some were loaded before copy2fs was set.
@Sandras: I guess your are correct the code for 'checkfs' boot code seemed to be "gone". I had a look through my archived files and I found it last in TC 2.3.1
Regarding your other problem I'm not quite sure what your are trying to achieve, so I attempted something myself to see if I could find anything "outrageously" wrong (I was using QEMU since that allows easy testing of such scenarios, but I dont' think that "real" hardware will behave differently):
(1) First boot from CD-ROM with an freshly formatted hard disk, using boot code 'tce=hda1' to create the required directories. I've installed a small number of extensions and took a "snapshot" of '/usr/local'. This showed all the expected links from '/usr/local/...' into '/tmp/tcloop/...'. Then created the "flag" with touch /mnt/hda1/tce/copy2fs.flg
(2) Next boot from CD-ROM with the prepared hard disk (but not using any boot code). Due to the 'copy2fs.flg' no files were present in '/tmp/tcloop' but all were extracted into the (in-memory) root file system -> exactly as expected.
(3) This time the system got booted with the boot code of 'local=hda1'. The booting took a bit longer and the hard disk got "busy". There was an additional (and entirely expected) mount of '/usr/local' from '/dev/hda1' to be found (binding '/mnt/hda1/tclocal' to '/usr/local'). By now the files had been extracted from the *.tcz files into '/usr/local' (i.e. '/mnt/hda1/tclocal'). I'm not sure what that is meant to achieve, to have the squash-fs files and the extracted content on the same disk. So I assume my test is not what you had in mind. Nevertheless I believe it all worked as it should have done.
I've done a few more tests and none of them showed anything unexpected. So maybe you could describe what result you are after.
I wasn't actually trying to achieve anything with the particular setup, I was just experimenting. It was my first time using the local=* bootcode, so i decided to explore it a bit more. Once I manually copied extensions to a partition on my hard drive and made TC mount it via bootlocal. And that gave me a very fast boot, it took practically the same time too boot as a base norestore boot. The thing is, it was very sluggish and that was an expected downside. I just wanted to see how much slower would it be. And I repeated that same experiment with the alpha4. Not that I'm going to go for a traditional type of /usr/local. The thing is it didn't seem to work properly. But anyway, I'll repeat the experiment and check if maybe I did something wrong.
-
With the libxml2 update, alpha4 now seems to be running perfectly on my machine.
-
@Sandras, if you load extensions in the background, using nice would help the interactivity during loading.
-
Does anybody see (very rare) mount problems, like one extension out of many that does not mount on /tce/tcloop the first time?
Repeating the mount or tce-load command solves the problem.
I see these rare mount problems from time to time in the Alpha releases. The mount fails with a "Cannot allocate memory" message, even when there is ample memory available. I didn't see this behaviour in the 2.x releases.
I can not reliably reproduce this problem. It happens randomly.
-
System ram and swap sizes? Could you also post /proc/meminfo from around the time that happens?
Also, how many extensions are you loading?
Final edit, any relevant dmesg output?
-
Does anybody see (very rare) mount problems, like one extension out of many that does not mount on /tce/tcloop the first time?
Repeating the mount or tce-load command solves the problem.
I see these rare mount problems from time to time in the Alpha releases. The mount fails with a "Cannot allocate memory" message, even when there is ample memory available. I didn't see this behaviour in the 2.x releases.
I can not reliably reproduce this problem. It happens randomly.
happens to me, when using Appbrowser. Also, once I had to drop some things off of onboot.lst, because TC showed the same error.
-
>>> System ram and swap sizes?
512 M system RAM with 512 M swap size
>>> Could you also post /proc/meminfo from around the time that happens?
you will have to wait until the problem manifests itself. I have seen it happening five times or so since 3.0 Alpha is available.
>>> Also, how many extensions are you loading?
I have a quite heavily tuned setup: I load 96 extensions in one single mount. This mount I never have seen fail until now. But I load Openoffice and the compiler/development stuff in the classic TC way with tce-load -i xxx.tcz and that's when I see the problem happening.
>>> Final edit, any relevant dmesg output?
I see nothing special. The kernel sees all the RAM and sees the swap space. Memory consumption of my environment is moderate (I think): with Xorg, jwm, and the (ROX)-desktop loaded, dbus and CUPS running and the 96 extensions mounted and available I consume 43,5 Megabytes so there is absolutely no RAM scarcity.
-
I had the mount problem happening for the first time today
exact message that was issued
mount: mounting /dev/loop5 on /tmp/tcloop/sed failed: Cannot allocate memory
this is the result of the free command just after it happened
total used free shared buffers
Mem: 514192 502596 11596 0 124088
Swap: 511992 10500 501492
Total: 1026184 513096 513088
Here is /proc/meminfo
MemTotal: 514192 kB
MemFree: 11720 kB
Buffers: 123940 kB
Cached: 199760 kB
SwapCached: 10004 kB
Active: 196632 kB
Inactive: 272268 kB
Active(anon): 65328 kB
Inactive(anon): 104736 kB
Active(file): 131304 kB
Inactive(file): 167532 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 514192 kB
LowFree: 11720 kB
SwapTotal: 511992 kB
SwapFree: 501456 kB
Dirty: 720 kB
Writeback: 0 kB
AnonPages: 136580 kB
Mapped: 42216 kB
Shmem: 24848 kB
Slab: 27676 kB
SReclaimable: 12572 kB
SUnreclaim: 15104 kB
KernelStack: 936 kB
PageTables: 1364 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 769088 kB
Committed_AS: 386536 kB
VmallocTotal: 508476 kB
VmallocUsed: 1148 kB
VmallocChunk: 504600 kB
DirectMap4k: 11708 kB
DirectMap4M: 512000 kB
There is interesting stuff in dmesg: here are the relevant lines:
mount: page allocation failure. order:4, mode:0xd0
Pid: 3203, comm: mount Not tainted 2.6.33.3-tinycore #2012
Call Trace:
[<c015a343>] ? 0xc015a343
[<c01742a8>] ? 0xc01742a8
[<c0226ecb>] ? 0xc0226ecb
[<c01744c5>] ? 0xc01744c5
[<e07af6ff>] ? 0xe07af6ff
[<c022b8d8>] ? 0xc022b8d8
[<c0195070>] ? 0xc0195070
[<c0179a36>] ? 0xc0179a36
[<e07af5e6>] ? 0xe07af5e6
[<e07af6b1>] ? 0xe07af6b1
[<c0179604>] ? 0xc0179604
[<c01797e0>] ? 0xc01797e0
[<c0189011>] ? 0xc0189011
[<c011a080>] ? 0xc011a080
[<c0187c5b>] ? 0xc0187c5b
[<c01890c4>] ? 0xc01890c4
[<c03bcc35>] ? 0xc03bcc35
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Normal per-cpu:
CPU 0: hi: 186, btch: 31 usd: 0
active_anon:15742 inactive_anon:24482 isolated_anon:0
active_file:36247 inactive_file:42147 isolated_file:0
unevictable:0 dirty:18 writeback:0 unstable:0
free:3647 slab_reclaimable:2650 slab_unreclaimable:2346
mapped:10159 shmem:6072 pagetables:330 bounce:0
DMA free:2056kB min:88kB low:108kB high:132kB active_anon:36kB inactive_anon:216kB active_file:1404kB inactive_file:7748kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15872kB mlocked:0kB dirty:0kB writeback:0kB mapped:48kB shmem:36kB slab_reclaimable:88kB slab_unreclaimable:16kB kernel_stack:8kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 491 491 491
Normal free:12532kB min:2788kB low:3484kB high:4180kB active_anon:62932kB inactive_anon:97712kB active_file:143584kB inactive_file:160840kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:503360kB mlocked:0kB dirty:72kB writeback:0kB mapped:40588kB shmem:24252kB slab_reclaimable:10512kB slab_unreclaimable:9368kB kernel_stack:768kB pagetables:1320kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 0*4kB 1*8kB 0*16kB 0*32kB 2*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2056kB
Normal: 2135*4kB 299*8kB 78*16kB 7*32kB 2*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 12532kB
84724 total pagecache pages
259 pages in swap cache
Swap cache stats: add 562, delete 303, find 118/133
Free swap = 510568kB
Total swap = 511992kB
130927 pages RAM
0 pages HighMem
2411 pages reserved
65787 pages shared
80734 pages non-shared
SQUASHFS error: Failed to allocate zlib workspace
sed is the first mount happening in my development tools install script, which consists of nothing more than a sequence of tce-load -i commands.
the mounts that came immediately after went all through without problems
running the script a second time mounted sed without problems
-
About my earlier posts about local=* and copy2fs:
Tried that setup again and it seems everything works fine. Seems like it was a mistake on my part, so sorry to waste everybody's time. Still, I don't remember and/or understand what did i do wrong the first time.
-
Found another problem - I've built 2 compositing managers (xcompmgr and cairo-compmgr) which I've been testing before I submit to the repo.
If i install the graphics-KERNEL extension for TC3a4, both compositing managers breaks down (blank screen with occasional flicker of open windows).
Xcompmgr has been tested and is working in TC2.11 with the appropriate graphics-KERNEL for 2.x installed.
I can make the xcompmgr available for others to test with, but it's not really ready to submit as a proper extension yet (no info file, for starters)
EDIT: Probably important to mention
lspci
01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200M]
-
I created a bootable flash card using the "usb install" tool then tried booting from it on a eeepc 900a.
Using boot codes "waitusb=15 base norestore pause tce=UUID="3EA1-E917" " everything comes up fine.
Note the "tce=UUID="3EA1-E917" " is inserted by the "install usb" tool.
Using boot codes "waitusb=15 norestore pause tce=UUID="3EA1-E917" " I get a stream of "bus error" messages right after the "loading Tiny Core Applications Extensions..." message. There are no extensions installed at this point.
After I install the 915resolution.tcz and reboot I get the same results - "bus errors".
However, if I add the "showapps" boot code then I get the extension loaded messages "including the Patch mode 50 to resolution 1024x600 complete" and the "bus error" messages go away.
Any ideas as to what is going on?
edit: tried the same above procedure using a usb stick instead of a flash card and the stream of "bus error" messages is reduced to one message when no extensions are installed. After I install 915resolution I get a message after the "loading Tiny core applications extensions" as follows: udev[96]: can not read '/etc/udev/rules.d/75-cd-dvd.rules'
edit2: I just tried all of the above with tc2.11.1 and everything works perfect! Great release!
-
bigpcman, could you post your dmesg? Also, on a boot you see the udev error, the output of "ls -lh /etc/udev/rules.d".
Udev outputs that error when it can't read the file, or the file is empty.
-
bigpcman, could you post your dmesg? Also, on a boot you see the udev error, the output of "ls -lh /etc/udev/rules.d".
Udev outputs that error when it can't read the file, or the file is empty.
I just noticed that the eeepc_laptop was not loaded at boot. Here is the 2.11.1 lsmod report:
Module Size Used by Not tainted
vfat 5652 1
fat 29692 1 vfat
squashfs 11732 1
scsi_wait_scan 260 0
eeepc_laptop 5264 0
hwmon 640 1 eeepc_laptop
atl1e 19596 0
backlight 1404 1 eeepc_laptop
battery 5976 0
rfkill 4012 2 eeepc_laptop
ac 1732 0
and here is tc3alpha4 lsmod report
Module Size Used by Not tainted
vfat 5596 1
fat 30220 1 vfat
squashfs 14884 1
ramzswap 10240 1
loop 8068 2
scsi_wait_scan 276 0
sparse_keymap 1168 0
battery 6028 0
video 12712 0
backlight 1632 1 video
ac 1696 0
output 724 1 video
atl1e 19316 0
Does this explain the problems?
I tried to do a "modprobe eeepc_laptop" but it failed with the message "unknown symbol in module or unknown parameter"
See attached dmesg report for the usb stick boot failure. It seems to be the worst case. I reran the tests with a different usb stick so the "/tce" name is different than in my previous post.
edit: The following is reported in the syslog report:
May 25 16:39:29 (none) user.warn kernel: eeepc_laptop: Unknown symbol hwmon_device_register
May 25 16:39:29 (none) user.warn kernel: eeepc_laptop: Unknown symbol pci_hp_deregister
May 25 16:39:29 (none) user.warn kernel: eeepc_laptop: Unknown symbol __pci_hp_register
May 25 16:39:29 (none) user.warn kernel: eeepc_laptop: Unknown
See attached syslog:
-
I was wondering whether it would be desirable to use "KERNEL" within an extension name used as parameter of 'tce-load'. E.g.
tce-load -wi filesystems-KERNEL
instead of
tce-load -wi filesystems-$( uname -r)
AFAIK the "-KERNEL" placeholder is only used for dependency files but not available from the CLI.
-
@bigpcman: there were no errors in the dmesg posted. I wonder if syslog would catch them better.
I'm a bit torn about the eeepc module - all other platform modules are in the base, and work fine, but eeepc now requires both hwmon and pci-hotplug. Separating it on its own wouldn't improve much, and separating all platform drivers wouldn't make sense either.
-
@bigpcman: there were no errors in the dmesg posted. I wonder if syslog would catch them better.
I'm a bit torn about the eeepc module - all other platform modules are in the base, and work fine, but eeepc now requires both hwmon and pci-hotplug. Separating it on its own wouldn't improve much, and separating all platform drivers wouldn't make sense either.
I have updated my previous post with the syslog output. It does indeed show eeepc_laptop does not load.
Also, the ath9k module for wireless does not load on boot. Although unlike eeepc_laptop it does load using "sudo modprobe ath9k" and seems to work fine with wpa_supplicant.
The error messages are a pain because they overrun the boot screen wiping away all the other info.
edit: BTW the eeepc_laptop module has worked going all the way back to version tc2.2. It would be a shame to not continue the previous automatic operation.
-
I am having no problems on my eeepc 1000he. I am using tc3.0a4 as my daily OS at home.
-
@bigpcman: Nothing in messages.txt either. If you haven't already, please check the md5sums of all extensions, the base image, and do a fsck. Also, is your kernel current? There was an update after the first alphas.
On eeepc, try loading the hwmon and pci-hotplug extensions.
-
Just thought I'd point out again that there seems to be a problem with the graphics extension, on radeon cards, at least.
Games that need graphics-2.6.29.1-tinycore.tcz (Games from the Humble Indie Bundle) to run at full speed in 2.11 are acting as if graphics-2.6.33.33-tinycore.tcz hasn't been installed when run under TC3.
-
@bigpcman: Nothing in messages.txt either. If you haven't already, please check the md5sums of all extensions, the base image, and do a fsck. Also, is your kernel current? There was an update after the first alphas.
On eeepc, try loading the hwmon and pci-hotplug extensions.
OK, I installed hwmon and pci-hotplug extensions to load on boot and now the "eeepc_laptop" driver installs correctly on boot. That's good news.
Now then, the bad news is I still get error messages as follows:
5-10 of these "/etc/init.d/rcS: line 459: usleep: Text file busy"
and 20-30 "Bus error"
See attached syslog
edit: Note, just as before if I use the "showapps" boot code all the errors go away (even when no extensions are installed). Seems to me there is a race condition on boot.
BTW all of today's testing has been done on a completely new install.
-
Just thought I'd point out again that there seems to be a problem with the graphics extension, on radeon cards, at least.
Games that need graphics-2.6.29.1-tinycore.tcz (Games from the Humble Indie Bundle) to run at full speed in 2.11 are acting as if graphics-2.6.33.33-tinycore.tcz hasn't been installed when run under TC3.
Please post Xorg.0.log and dmesg.
-
Moving on to more applications. Tried running Xampp today. Installed bash and ipv6 extensions. I get the following errors:
tc@box:/mnt/sdb1/mysys$ sudo /opt/lampp/lampp start
Starting XAMPP for Linux 1.7.3a...
netstat: /proc/net/tcp6: No such file or directory
netstat: /proc/net/udp6: No such file or directory
netstat: /proc/net/raw6: No such file or directory
netstat: /proc/net/tcp6: No such file or directory
netstat: /proc/net/udp6: No such file or directory
netstat: /proc/net/raw6: No such file or directory
XAMPP: Starting Apache with SSL (and PHP5)...
netstat: /proc/net/tcp6: No such file or directory
netstat: /proc/net/udp6: No such file or directory
netstat: /proc/net/raw6: No such file or directory
XAMPP: Starting MySQL...
netstat: /proc/net/tcp6: No such file or directory
netstat: /proc/net/udp6: No such file or directory
netstat: /proc/net/raw6: No such file or directory
XAMPP: Starting ProFTPD...
XAMPP for Linux started.
In tc2.11.1 the firewall extension is required to resolve all ip6 errors. No firewall extension exists in 3.0 repository.
-
A modprobe of ipv6 should handle that. Was the module loaded automatically in 2.x?
-
A modprobe of ipv6 should handle that. Was the module loaded automatically in 2.x?
Looks like a reboot fixed the problem. The extension installation by itself did not load the ipv6 module.
-
This may not have anything to do with tc3.0 but I used to be able to:
sudo /usr/local/etc/init.d/dropbear start -w -g -m -p 57231 -b /etc/dropbear/banner
where the -p option set the port number. Now the -p seems to be ignored:
from "top"
1266 1264 root S 2236 0.1 0 0.0 /usr/bin/dropbear -w -g -b /etc/dropbear/banner
and indeed port 22 is used not 57231.
edit: Ok, I see what's going on, I'm calling the dropbear script which needs to be modified to include the command options. When using the command:
sudo dropbear -w -g -m -p 57231 -b /etc/dropbear/banner
it works as before.
-
odd error on manual backup using panel tool:
Should be sdb1/tce?
tc@box:/tmp$ cat backup_status
tar: can't open '/mnt/sdb1/tcebackup/mydata.tgz': No such file or directory
tc@box:/tmp$
removed mydata.tgz and selected none on panel backuptool then entered sdb1/tce and tried again. Then I received the following error:
tc@box:/tmp$ cat backup_status
tar: etc/group : No such file or directory
tar: etc/passwd : No such file or directory
tar: error exit delayed from previous errors
So I guess if the files in the .filetool.lst are not found this can cause problems. Not sure what caused the first problem? The files passwd and group do exist so I don't know why they can't be saved. Perhaps they are in use?
-
Just thought I'd point out again that there seems to be a problem with the graphics extension, on radeon cards, at least.
Games that need graphics-2.6.29.1-tinycore.tcz (Games from the Humble Indie Bundle) to run at full speed in 2.11 are acting as if graphics-2.6.33.33-tinycore.tcz hasn't been installed when run under TC3.
Please post Xorg.0.log and dmesg.
This little idiot should have looked at dmesg before posting about his problems. Turns out that I now need to load firmware.tcz before trying to use graphics-2.6.33.3-tinycore.tcz with my gfx chip.
EDIT: Actually, the firmware module seems to have corrected a couple of other little annoyances that had cropped up in TC3 that i hadn't experienced in 2.x.
-
The work-around for the gtk-2 bug, requiring export GDK_NATIVE_WINDOWS=true no longer works very well in tc3.0a.
As soon as I right-click on a file in rox, and select open as text, and close rox, the previously set global variable GDK_NATIVE_WINDOWS is cleared.
I checked back into tc2.11.1 and the problem is not present there, so I report it here.
-
Split out OT discussion to:
http://forum.tinycorelinux.net/index.php?topic=6167.0
http://forum.tinycorelinux.net/index.php?topic=6166.0
2) What is the strategy when it comes to 64 bits? Will 64 bit support only come with the base system and the extensions will stay 32 bit? If not, shouldn't the 64 bit extensions and 32 bit extensions be separated?
None of this is essential in any way, but I wanted to ask these before it's too late, because the design has been declared fix again.
Greetings,
SvOlli
See earlier threads, esp. alpha1 and alpha2.
More splits:
http://forum.tinycorelinux.net/index.php?topic=6192.0
http://forum.tinycorelinux.net/index.php?topic=6208.0
-
Base & extensions will stay 32-bit for the time being. The kernel already brings most benefits (ie. large amounts of ram). If someone needs to build a 64-bit app for speed reasons or whatever, the runtime libs are available separate from toolchain64.
-
Base & extensions will stay 32-bit for the time being. The kernel already brings most benefits (ie. large amounts of ram). If someone needs to build a 64-bit app for speed reasons or whatever, the runtime libs are available separate from toolchain64.
I'm not an expert 32 vs. 34 bit but recall few articles explaining cases when 64 bit apps run slower than 32 bit. Just a thought.
-
Base & extensions will stay 32-bit for the time being. The kernel already brings most benefits (ie. large amounts of ram). If someone needs to build a 64-bit app for speed reasons or whatever, the runtime libs are available separate from toolchain64.
That's exactly what I wanted to know. Thanks!
I'm not an expert 32 vs. 34 bit but recall few articles explaining cases when 64 bit apps run slower than 32 bit. Just a thought.
I discovered a case of the exact opposite: if your code does heavy float calculations you'll get ~50%(!) speed gain on the same machine. I tried it with oggenc.
-
I thought I understood the apps audit tool but maybe not. See the attached pic. The OnDemand part of the tool seems to be out of sync with the ".OnDemand" directory in /home/tc.
edit: I deleted the x11vnc entry out of .OnDemand and rebooted and now I get different results. See the second pic.
-
I thought I understood the apps audit tool but maybe not. See the attached pic. The OnDemand part of the tool seems to be out of sync with the ".OnDemand" directory in /home/tc.
edit: I deleted the x11vnc entry out of .OnDemand and rebooted and now I get different results. See the second pic.
One has nothing to do with the other. Any currently uninstalled extension, at the time of script invocation, is shown as available for select for ondemand.
-
Am having problems suddenly today booting off usb stick on a Toshiba tecra with centrino (whatever that means):
symbol lookup error: /usr/local/lib/libgdk-x11-2.0.so.0 undefined symbol: g_malloc_n
I didn't have this problem yesterday booting off same stick. ???
[edit] the above is displayed when I try to run beaver2, rox or chromium from a terminal.
-
symbol lookup error: /usr/local/lib/libgdk-x11-2.0.so.0 undefined symbol: g_malloc_n
Isn't it called
/usr/local/lib/libgtk-x11-2.0.so.0 ??
-
Isn't it called
/usr/local/lib/libgtk-x11-2.0.so.0 ??
both is true :)
see gtk2.tcz.list
-
When I click on the cpanel Update Apps button it opens the terminal for a second and then closes it. The console is blank as near as I can tell.
When I issue the command "sudo tce-update" the program works just as it should. Ideas?
edit: tried this on another system with just one extension and I get the same results.
-
Another minor question: What is the purpose of /etc/skel/.webdata.lst and /etc/skel/.webdatarc which end up in the users home directory?
Maybe they could be removed from the initrd if not anymore required.
-
These were to be used for a web backup/restore feature. I had first implemented such in Lua/Fltk for DSL. Have not gotten around to do for Core. Perhaps it is no longer desireable. I will remove for now.
-
using appsaudit, I noticed that when you check for updates the full path of each extension is listed - i.e. /mnt/sda1/tce/optonal/extension_name - which means that most of the extension names are not fully displayed without scrolling sideways.
Since the full path of the tce/optional directory is displayed at the top of the left hand pane, could we show just the extension names in the left hand pane to make them easier to see?
-
Sure!
EDIT: Done! Will be in next cut.