Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: roberts on September 11, 2011, 12:38:09 PM
-
The First Release Candidate of Tiny Core v4.0 is now posted and ready for testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/4.x/x86/release_candidates (http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/4.x/x86/release_candidates)
tinycore_4.0rc1.iso
tinycore_4.0rc1.iso.md5.txt
Change log:
* 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.
* New loadcpufreq to handle module loading.
* Updated eglibc for 486/586 support.
* Updated busybox 1.19.2 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.
* Updated AppBrowser Search and Keyword as described below.
* Updated ab Search and Keyword.
* Updated search.sh internal script support for new search method shared by AppBrowser & ab
* New keyword.sh internal script support for new keyword method shared by AppBrowser & ab
Notes:
The Search method for both AppBrowser and ab is now a local info.lst search.
To use enter the starting few characters of the desired extension, e.g., abi for abiword, or ope for opera
Both AppBrowser and ab now offer Keyword searching.
Examples: enter browser to display browsers, enter game to list games.
The following has been deprecated in the 4.x series:
* Floppy Tool (floppytool.sh & fdtool)
* Starter Packs (loadpack & loadpack.sh)
* Hybrid Mode (boot local & mktclocal)
The new repository areas:
http://distro.ibiblio.org/tinycorelinux/4.x/x86/tcz/ (http://distro.ibiblio.org/tinycorelinux/4.x/x86/tcz/)
Attn: microcore users will need new Xprogs.tcz from 4.x repository.
-
can you post info on any changes since last alpha ?
-
As requested change log since alpha 3
* Updated busybox to 1.19.2 + chpasswd patch
* Removed the following:
* Floppy Tool (floppytool.sh & fdtool)
* Starter Packs (loadpack & loadpack.sh)
* Hybrid Mode (boot local & mktclocal)
* Updated cpanel to reflect changes above.
* Updated ondemand to handle freedesktop item with no icon spec.
-
Thanks.
What is the immediate user feeling for a person upgrading 3.8.4 to 4.0: more speed at boot? quicker extension load? (I like speed... especially with my old box).
-
i can say that now i don't get graphical glitches on ati hardware anymore. they were prevalent on lxde + xorg + tc 3.8
usually i would get a messed up rectangle around the cursor and sometimes occasional garbage around window borders.
using ati radeon x1300 pro (rv515).
-
4.0 is slightly faster in the kernel part, slightly slower in the main part of the base boot. In total it's a win of ~5%.
(http://preview.shareapic.net/preview7/025376991.png) (http://www.shareapic.net/View-25376991-TC.html) (http://preview.shareapic.net/preview7/025376992.png) (http://www.shareapic.net/View-25376992-TC.html)
BRB rewriting loadcpufreq in C.
-
Ah, that's better.
(http://preview.shareapic.net/preview7/025377147.png) (http://www.shareapic.net/View-25377147-TC.html)
-
A nice boost in boot speed comes from the fact that, while 3.8.3 takes five to seven seconds worth of "waitusb" time to recognize my usb stick, 4.0rc1 recognizes it in approximately zero seconds. Like!
-
I think the '4.x Release Candidates (Testing)' (http://distro.ibiblio.org/tinycorelinux/4.x/release_candidates) link on the downloads page (http://distro.ibiblio.org/tinycorelinux/downloads.html) is broken (I guess this one (http://distro.ibiblio.org/tinycorelinux/4.x/x86/release_candidates) was meant to be used).
-
What is a good upgrade path wrt /tce? Ditch all old stuff and start from scratch?
-
What is a good upgrade path wrt /tce? Ditch all old stuff and start from scratch?
i think i asked on the forums already.
apparently replacing kernel + initrd with ones from new tinycore and running updates should do the trick.
things might get tricky with xorg, though. you might want to boot into text mode.
-
Xorg 7.4, 7.5 and 7.6 have been reported working with 4.x. There have been no changes to the 7.4 and 7.5 extensions in 4.x.
edit: 7.6 requires changes not yet in the rc1.
-
As requested I have split off the discussion of tce-load handling of KERNEL to programming and scripting:
http://forum.tinycorelinux.net/index.php/topic,11416.msg59847.html#msg59847 (http://forum.tinycorelinux.net/index.php/topic,11416.msg59847.html#msg59847)
This subject has nothing to do with Alpha or Release Candidates of which we have asked the community to test but instead is for the benefit of those who happen to have both 32 and 64 machines AND wish to co-mingle extenions that are module dependent, a rather select few I would imagine.
-
Ah, that's better.
(http://preview.shareapic.net/preview7/025377147.png) (http://www.shareapic.net/View-25377147-TC.html)
I don't see any cpufreq in this image, why?
-
bootchart ignores very short-lived processes to avoid clutter. The C version is some 16 times faster than the script.
-
Impressive, but I expect multitasking to be a big factor here when measured in real time. Can you see how do their cpu times compare?
-
Good speed. My first experience with MC 4.0.1 + Xorg7.4:
a) my bootcodes had to be changed from "hdx" to "sdx"; example my TCE from "hdd3" to "sdc3".. no big issue, only an information (I know.. but labels etc. takes too many characters on my boot code line)
b) the error message appear on the screen during boot "hwclock: can t open dev/misc/rtc no such file or directory. No big issue
c) all Icons of wbar are gone. In the end of the dmesg log file I have..
[ 81.286884] wbar[2516]: segfault at 8 ip b73975f7 sp bfa1bc3c error 4 in libc-2.13.so[b7338000+132000]
[ 81.944419] wbar[2524]: segfault at 8 ip b74b05f7 sp bffa711c error 4 in libc-2.13.so[b7451000+132000]
[ 111.960914] wbar[2595]: segfault at 8 ip b74e95f7 sp bfebb8bc error 4 in libc-2.13.so[b748a000+132000]
[ 113.606922] wbar[2599]: segfault at 8 ip b748e5f7 sp bffc4edc error 4 in libc-2.13.so[b742f000+132000]
[ 116.151117] wbar[2603]: segfault at 8 ip b74eb5f7 sp bfa5238c error 4 in libc-2.13.so[b748c000+132000]
[ 116.899406] wbar[2607]: segfault at 8 ip b74905f7 sp bf994f1c error 4 in libc-2.13.so[b7431000+132000]
[ 169.002069] wbar[2712]: segfault at 8 ip b73605f7 sp bfbe28ac error 4 in libc-2.13.so[b7301000+132000]
They takes a long boot time.
-
WRT wbar:
Did you get a fresh copy of wbar.tcz? If so, it was updated around the end of August (see the .info) such that you have to fix your ~/.wbar to use "-pos" instead of "-p". It segfaults if you don't. That stumped me for a while, too, until I checked the .info file. :)
Lee
-
It is great to have cpufreq modules in the base. Tested on three different machines, one notebook with Intel Core Duo and two desktops with AMD dual CPUS-s where one doesn't support scaling. Proper drivers (acpi and powernow_k8) were loaded, ondemand governor were activated and scaling was working after boot without doing any extra.
I love this behavior.
-
mdadm.tcz is missing in TC4 repo.
-
raid modules are not part of base, therefore raid devices are not recognized during boot. Please considere adding them to base even if they are big (?). Using any live distro without instant raid support is a pain when used for disaster recovery.
To have raid moduls included is much more important than cpu frequency scaling. Even if size matters, move out cpufreq modules to extension as it is now but add raid.
-
bmarkus: I have not looked at the size of the RAID modules, but if they are big would not a more suitable place for such an add-on that probably only a few users need for disaster recovery be either in the 'multicore.iso' or in ones own re-mastered image?
-
bmarkus: I have not looked at the size of the RAID modules, but if they are big would not a more suitable place for such an add-on that probably only a few users need for disaster recovery be either in the 'multicore.iso' or in ones own re-mastered image?
If something is not in base, you can make your own version always. However raid is a bit different. But lets see what others are saying. I made my vote :)
-
You have computers without USB? I'm curious...
-
Wouldn't raid also need the mdadm userspace tools to be useful?
@hiro:
time loadcpufreq
real 0m 0.07s
user 0m 0.01s
sys 0m 0.00s
time loadcpufreq.sh
real 0m 1.02s
user 0m 0.66s
sys 0m 0.27s
-
Wouldn't raid also need the mdadm userspace tools to be useful?
normally mdadm is not needed, only to manage raid (add, remove devices, create arrays, etc., not on a daily bases.
Kernel detects raid devices at boot (if raid array supports autodetect which is the usual case) and next it can be mounted, etc on a usual way as any other block device.
Status can be displayed with 'cat /proc/mdstat'
-
RC1 is running great for me in VMWare Workstation, seems to be even a lot faster than 3.x, yeehaaw!
One problem appears (sometimes): udevadm settle from dhcp.sh doesn't quit, therefore no udhcpc starting for my network device... when I kill udevadm manually after startup, everything continues to work as expected. I can reproduce this with running udevadm settle myself, it's timeouting every second on polling some device (it seems) - attaching log, anyone else seeing this? Already loaded the scsi extension to make sure he's maybe not waiting for that (although I use an IDE hdd in VMWare).