Tiny Core Linux
Tiny Core Base => TCB News => Alpha Releases => Topic started by: roberts on September 01, 2011, 11:14:14 PM
-
Tiny Core 4.0 Alpha2 is available for public testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/4.x/x86/alpha/
Change log:
alpha1:
* Updated kernel to 3.0.3
* Updated udev to 173
* Updated glibc to eglibc-2.13
* Updated e2fsprogs base libs to 1.41.14
* Updated gcc base libs to 4.6.1
* Updated util-linux base libs to 2.19.1
* Updated all the custom core utilities to use the new repository area:
http://distro.ibiblio.org/tinycorelinux/4.x/x86/tcz/
alpha2
* New loadcpufreq to handle module loading.
* Updated eglibc for 486/586 support.
* Updated busybox 1.19 with latest patches and fix for chpasswd segfault.
* Updated ondemand for console based extensions via Freedesktop Exec=cliorx prgname
* Adjusted .xsession to handle X startup failure.
* Adjusted .setbackground colors for wallpaper handling.
-
Good news, the two items I mentioned about 4.0a1 are resolved.
So, as was the case in the later stages of the TC 2.x phase a rebuild of the 'libc' resolved the 'Xvesa' failure when run in a QEMU VM with KQEMU. This seems to be somewhat connected with what is labeled as "486/586 support".
I wonder what it was exactly that was changed for the 'eglibc' rebuild. To know this might help me in the future if I stumble somewhere else over a similar issue again.
-
I wonder what it was exactly that was changed for the 'eglibc' rebuild. To know this might help me in the future if I stumble somewhere else over a similar issue again.
The issue is that the eglibc documention seems to be incorrect as regards compiling for i486/i586 compatibility, "--host=i486-pc-linux-gnu --target=i486-pc-linux-gnu" was required, wheras the documentation stated only "--host=i486-pc-linux-gnu" was needed.
-
TC now works on Vortex86 SOC.
Also tested with MC, Xorg-7.4 and Xorg-7.5, and flwm_topside.
-
My mistake, nbd.ko.gz is present.
Busybox was apparently compiled without nbd-client.
I compiled a standalone nbd-client for testing, and now have boot option "nbd=server:port tce=nbd0" working.
The problem I am now having is that powerdown kills nbd-client before /dev/nbd0 is umounted.
-
What kind of changes are to be expected in the TC 4.0 in terms of the actual 'core' (that is, those features, interfaces, and graphics, which are created for TCL)?
Also, is FLTK going to be updated to 1.3? I know that it is somewhat incompatible with earlier versions, but it's a much-needed update, I think, considering that 1.1.10 was released over a year and a half ago (somewhere on the order of 20-21 months); in comparison, 1.3 was released 3 months ago, relatively stable yet modern. If TC doesn't update FLTK now, then we'll probably have to wait yet another year for an update.
-
Hi TheNewbie
Just out of curiosity, are you looking for an update simply because something newer is available, or
because you are having a specific problem with the version currently in use?
-
Hi TheNewbie
Just out of curiosity, are you looking for an update simply because something newer is available, or
because you are having a specific problem with the version currently in use?
I don't personally have a specific problem to deal with, I'm just wondering if the team/community considers it worth it, and asking whether or not such an update will be include it. It supposedly offers Unicode support, and I did have small issues with special characters when browsing the Web, but in general, an update would not bring many benefits.
For clarification, I am not looking for an update -- I asked whether it would be updated, and also stated some time frames for reference. I did use the words "much-needed," and those were specifically taking into account only those time frames. I don't think 1.3 would introduce major issues, but I understand if the team feels that it's not mature enough to warrant updating TC to use it.
Really though, I'm more worried about the TC-specific updates, as opposed to external lib availability and inclusion.
-
Hi TheNewbie
For clarification, I am not looking for an update -- I asked whether it would be updated,...
Poor choice of words on my part, I was just curious about your inquiry.
-
Re: fltk 1.3 See: http://forum.tinycorelinux.net/index.php/topic,10141.msg54736.html#msg54736
-
I don't see your problem. fltk 1.3 is already available in the repository.
It supposedly offers Unicode support, and I did have small issues with special characters when browsing the Web, but in general, an update would not bring many benefits.
What browser are you using that is built against fltk 1.1?
-
Has anybody tried building the core graphic apps statically against fltk 1.1?
-
hi roberts,
just that you are informed:
with alpha2 the b44-modul of my broadcast-wired-eth0 isn't loaded.
that's my dmesg in alpha2:
b44: Unknown symbol ssb_device_is_enabled (err 0)
b44: Unknown symbol ssb_pcicore_dev_irqvecs_enable (err 0)
b44: Unknown symbol ssb_bus_may_powerdown (err 0)
b44: Unknown symbol ssb_pcihost_register (err 0)
b44: Unknown symbol ssb_device_disable (err 0)
b44: Unknown symbol ssb_device_enable (err 0)
b44: Unknown symbol ssb_driver_unregister (err 0)
b44: Unknown symbol __ssb_driver_register (err 0)
b44: Unknown symbol ssb_bus_powerup (err 0)
b44: Unknown symbol ssb_clockspeed (err 0)
b44: Unknown symbol ssb_dma_translation (err 0)
with 3.8.4 it's loaded properly and my dmesg looks like that:
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.
-
I see two possibilities:
1. The ssb module needs to be loaded
or
2. The ssb module is loaded and it needs to be blacklisted (blacklist= boot code)
-
Right, ssb should be in the base and not in the wireless extension.
-
..but doing that in tc-3 stopped the broadcom "wl" driver (and possibly others) from working, as ssb needed to be blacklisted.
-
modprobe ssb
modprobe -r b44 ssb
don't work...
is it a mistake in the core and should it work with the base without user interaction or as an onboot.lst-item?
there is also a hint to a modprobe.dep, what does that mean?
what do you recommend?
-
Right, it's a compromise either way. As I have no broadcom hw of any kind, I'm probably not the right person to make that choice.
I would lean towards supporting the wired one by default, and requiring blacklisting to use the broadcom wl module, but would like to hear what you guys think.
-
I believe it makes most sense to support wired connections by default
-
I believe it makes most sense to support wired connections by default
+1
-
I believe it makes most sense to support wired connections by default
hopefully that's the direction or decision!
-
Supporting as much wired as was possible with the kernel was the original goal and should therefore remain.
-
when using Xorg, installing firmware-radeon and graphics-3.0.3 the boot progress gets stuck on loading extensions.
i have a few dmesg messages about radeon drm and then i get the rotating spinner, and nothing else happens. it just keeps spinning, and apparently waits for something.
i'd like someone with radeon gfx card to re-check this.
-
If you can, boot with boot option, 'showapps'. Each extension will then be displayed. This might be useful to see which extension is hanging.
-
The busybox binary isn't setuid root anymore. Is this intentional?
I have serious instabilities with this alpha version (Xorg, ALSA, ...). After four hours of searching I have come to the conclusion that the new "ldconfig" binary is malfunctioning.
Here is an example with the libva extension
~ $ tce-load -i libva.tcz
libva.tcz: OK
~ $ ldconfig -p | grep libva
result with the alpha2 ldconfig
libva.so.1 (libc6) => /usr/local/lib/libva.so.1
libva.so (libc6) => /usr/local/lib/libva.so
libva-x11.so.1 (libc6) => /usr/local/lib/libva-x11.so.1
libva-x11.so (libc6) => /usr/local/lib/libva-x11.so
libva-tpi.so.1 (libc6) => /usr/local/lib/libva-tpi.so.1
libva-tpi.so (libc6) => /usr/local/lib/libva-tpi.so
libva-glx.so.1 (libc6) => /usr/local/lib/libva-glx.so.1
libva-glx.so (libc6) => /usr/local/lib/libva-glx.so
result with the alpha1 ldconfig
libva.so.1.0.4 (libc6) => /usr/local/lib/libva.so.1.0.4
libva.so.1 (libc6) => /usr/local/lib/libva.so.1
libva.so (libc6) => /usr/local/lib/libva.so
libva-x11.so.1.0.4 (libc6) => /usr/local/lib/libva-x11.so.1.0.4
libva-x11.so.1 (libc6) => /usr/local/lib/libva-x11.so.1
libva-x11.so (libc6) => /usr/local/lib/libva-x11.so
libva-tpi.so.1.0.4 (libc6) => /usr/local/lib/libva-tpi.so.1.0.4
libva-tpi.so.1 (libc6) => /usr/local/lib/libva-tpi.so.1
libva-tpi.so (libc6) => /usr/local/lib/libva-tpi.so
libva-glx.so.1.0.4 (libc6) => /usr/local/lib/libva-glx.so.1.0.4
libva-glx.so.1 (libc6) => /usr/local/lib/libva-glx.so.1
libva-glx.so (libc6) => /usr/local/lib/libva-glx.so
The new ldconfig misses part of the entries.
When I copy over the old "ldconfig" in alpha2 everything works normally.
-
If you can, boot with boot option, 'showapps'. Each extension will then be displayed. This might be useful to see which extension is hanging.
i'm having a hunch it's actually alsa startup script atm.
will test with the parameter.
edit: well, this is beyond embarrassing, but it seems i left the getfllash10 script in onboot.lst
and it asks for confirmation to reinstall, but it only shows with showapps boot parameter.
-
I noticed and fixed that getFlash10 issue as i saw the same thing almost a week ago. It happened when flash10.tcz is lower down the list in onbootl.st, which it naturally would be.
Have you updated your extensions recently, or is it doing this on a new install?
I will take another look at the startup script.
EDIT: I see that my correction got lost in the shuffle, corrected extension is uploaded now.
-
I noticed and fixed that getFlash10 issue as i saw the same thing almost a week ago. It happened when flash10.tcz is lower down the list in onbootl.st, which it naturally would be.
Have you updated your extensions recently, or is it doing this on a new install?
I will take another look at the startup script.
EDIT: I see that my correction got lost in the shuffle, corrected extension is uploaded now.
new install.
also, there is no cryptsetup in 4.x repositories. version from 3.x works just fine.
-
The busybox binary isn't setuid root anymore. Is this intentional?
I have serious instabilities with this alpha version (Xorg, ALSA, ...). After four hours of searching I have come to the conclusion that the new "ldconfig" binary is malfunctioning.
Here is an example with the libva extension
~ $ tce-load -i libva.tcz
libva.tcz: OK
~ $ ldconfig -p | grep libva
result with the alpha2 ldconfig
libva.so.1 (libc6) => /usr/local/lib/libva.so.1
libva.so (libc6) => /usr/local/lib/libva.so
libva-x11.so.1 (libc6) => /usr/local/lib/libva-x11.so.1
libva-x11.so (libc6) => /usr/local/lib/libva-x11.so
libva-tpi.so.1 (libc6) => /usr/local/lib/libva-tpi.so.1
libva-tpi.so (libc6) => /usr/local/lib/libva-tpi.so
libva-glx.so.1 (libc6) => /usr/local/lib/libva-glx.so.1
libva-glx.so (libc6) => /usr/local/lib/libva-glx.so
result with the alpha1 ldconfig
libva.so.1.0.4 (libc6) => /usr/local/lib/libva.so.1.0.4
libva.so.1 (libc6) => /usr/local/lib/libva.so.1
libva.so (libc6) => /usr/local/lib/libva.so
libva-x11.so.1.0.4 (libc6) => /usr/local/lib/libva-x11.so.1.0.4
libva-x11.so.1 (libc6) => /usr/local/lib/libva-x11.so.1
libva-x11.so (libc6) => /usr/local/lib/libva-x11.so
libva-tpi.so.1.0.4 (libc6) => /usr/local/lib/libva-tpi.so.1.0.4
libva-tpi.so.1 (libc6) => /usr/local/lib/libva-tpi.so.1
libva-tpi.so (libc6) => /usr/local/lib/libva-tpi.so
libva-glx.so.1.0.4 (libc6) => /usr/local/lib/libva-glx.so.1.0.4
libva-glx.so.1 (libc6) => /usr/local/lib/libva-glx.so.1
libva-glx.so (libc6) => /usr/local/lib/libva-glx.so
The new ldconfig misses part of the entries.
When I copy over the old "ldconfig" in alpha2 everything works normally.
Both will be corrected in next cut. Thanks for reporting.
-
yoshi314-
Try getFlash10 from a new download again, my correction had a typo that is fixed now.
Also, cryptsetup or anything that depends on kernel modules was not copied over to the 4.x repo. When new modules are made and the 3.x extension tested, they can be submitted to 4.x. Every extension was manually reviewed and copied or not copied over to 4.x on a case by case basis, so as to not start out with a broken repo.
-
Oh, I see that the raid-dm kernel modules are in 4.x now, I will copy over crypsetup and adjust it's dep file.
Any more similar extension issues, we can open a new topic in the TCE forum area.
-
Hi,
I've been using ldd that looks like this:
#!/bin/sh
for file in $@; do
case $file in
*/*) true
;;
*) file=./$file
;;
esac
LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 $file
done
Now, ldd that comes with Alpha2 is bigger. It also calls bash.
Thank you.
-
ldd and ldconfig in alpha 2 will be fixed for 3.