Tiny Core Linux
Tiny Core Base => TCB News => Alpha Releases => Topic started by: Juanito on May 30, 2013, 04:49:17 AM
-
Team Tiny Core is pleased to announce Tiny Core 5.0 Alpha1 is available for public testing:
http://repo.tinycorelinux.net/5.x/x86/release_candidates/
This is an alpha level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.
Since this is an alpha cut, although the team has worked through several preview cuts, we ask that only experienced users test. This cut is not for general use. The features in any alpha are not fixed and may change before a public release candidate is available.
At the moment, only a few extensions have been copied over from the 4.x repo - there's no reason why most of them shouldn't work and we can copy them over to the 5.x repo as they are proven to work.
An updated Xorg series of extensions is in the pipeline, but there's no firm release date as yet.
We appreciate testing and feedback.
If you use distribution files note that you need a new vmlinuz and core.gz
Changelog for 5.0 alpha1:
* kernel update to 3.8.10 with (u)efi boot enabled
* option to use vmlinuz + rootfs.gz + modules.gz or vmlinuz64 + rootfs.gz + modules64.gz (where boot loader permits)
* aterm, freetype, imlib2, jpeg and libpng factored out of Xlibs/Xprogs
* glibc updated to 2.17 and recompiled against 3.8.x kernel headers
* gcc updated to 4.7.2, recompiled against 3.8.x kernel headers and cloog, gmp, mpc, mpfr and ppl
* e2fsprogs base libs/apps updated to 1.42.7
* util-linux base libs/apps updated to 2.22.2
* scm extensions have been dropped from this release
Special Note:
This is alpha software. This is the first public access. Expect bugs. Not recommended for general use.
-
Great! Glad to hear that, and rushing to test it.
-
Note that with this version of gcc, extensions can be compiled in the usual way:
CFLAGS="-march=i486 -mtune=i686 -Os -pipe" CXXFLAGS="-march=i486 -mtune=i686 -Os -pipe -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local
..or it can be done like this:
CC="gcc -flto -fuse-linker-plugin -march=i486 -mtune=i686 -Os -pipe" CXX="g++ -flto -fuse-linker-plugin -march=i486 -mtune=i686 -Os -pipe -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local..which often results in significantly smaller executables and dynamic libs, but significantly larger static libs
-
A quick test with userspace tczs (Xvesa+firefox+fluxbox) from 4.x caused no apparent issue.
One trivial issue is wrong own/perms of Xprogs/usr/local/tce.installed directory.
linux-headers-xxxx.tcz would be nice to have (can its build be automated?).
For experimentation more than bugreporting:
I like separation into rootdir/modules very much. I tried to load only rootdir, which boots to shell: however, busybox mount of squashfs, rather than failing, hangs busybox, which is strange.
Even stranger is the fact that insmodding squashfs.ko.gz is no fix to that.
-
Sometimes tce-load -i hangs.
After a quick check, looks like "sudo (busybox) depmod -a" is the cause.
I occasionally observed this behavior in the past; this does not happen with original (module-init-tools) depmod, which is forcibly excluded by tce-load, however.
Manually running sudo busybox depmod -a does not terminate, indeed.
I have tczs from 5.x and 4.x loopmounted, maybe this mingling could cause the trouble. I think this is a more general problem with busybox, however.
-
* scm extensions have been dropped from this release
What are the reasons to drop .scm extensions? Is it more of a merging things together, or was the decision taken because of maintenance problems? ???
Not complaining. I'm just interested to know because I like to have 1x 40Meg extension independent, rather than 200+ tcz each dependant of the rest...
It's easier for me to manage the system that way.
-
Sometimes tce-load -i hangs.
After a quick check, looks like "sudo (busybox) depmod -a" is the cause.
Sorry, I myself cannot reproduce this bug.
It's likely that it originated when I custom built git://linuxtv.org/media_build.git, but in a way I don't understand.
-
I don't have any usable testing hardware in front of me right now so I've got the Core 5.0.alpha1 running in a VM under qemu-0.13.0-windows on Win7 Pro 32 bit. It is set up as follows:
Qemu command line:
qemu.exe -L . -m 1024 -hda tc477.img -boot c -soundhw sb16,es1370 -localtime -M pc
The HD image is a 1 GB file partitioned as one partition, the partition formatted as ext2 and labeled tc477.img
Booting with grub4dos. Relevant menu.lst stanza is:
title Core 5.0 alpha 1
find --set-root /boot/grub/tc477.img
kernel /boot/core5.0.a1/vmlinuz quiet tce=LABEL=tc477.img/boot/core5.0.a1/tce pause multivt
initrd /boot/core5.0.a1/core.gz/
I downloaded vmlinuz and core.gz to the right places an verified the core.gz md5 sum. There was no vmlinuz.md5.txt.
... and the system boots right up
During boot up, there is a message "Failed to access perfctr msr (MSR c1 is 0)" but it does not stop the boot up process.
Perhaps whatever it was trying to perfect was already perfect? :)
On the first boot up, there was a message like "...fast TSC failed..." but it does not recur on subsequent reboots. This did not stop the boot process.
So far so good.
I got to the core console and verified the environment using "version", "uname -a" and "ls -l /etc/sysconfig" then used tce-load -w to grab:
Xlibs.tcz
Xprogs.tcz
Xvesa.tcz
flwm_topside.tcz
wbar.tcz
emelfm.tcz
and loaded same with tce-load -i.
No problems.
Used Xsetup.sh to select Xvesa resolution 1280x1024x16 and "USB & IMPS/2 Wheel" mouse.
startx yielded the expected results.
Tried out cpanel and editor - both OK.
Tried out apps tool - not so good.
Apps connects to the repo but fails when trying to download an extension with the status box indicating "mc.tcz failed".
Tried to verify that tce-load -w mc.tcz works... but no aterm icon on the wbar.
Tried to execute aterm from emelfm's command box... but no aterm.
Oh yeah - something in the release notes about aterm...
Tried to execute tce-load -w aterm.tcz directly in emelfm's command box... That worked.
Tried to use apps to "load app locally" extension aterm.tcz... That worked.
Permissions/ownership:
/mnt/sda1/boot/core5.0.a1 rwxr-xr-x root:root
/mnt/sda1/boot/core5.0.a1/tce rwxrwxr-x tc:staff:root
/mnt/sda1/boot/core5.0.a1/tce/optional rwxrwxr-x tc:staff:root
So first glance result:
Good over all.
Looks like an issue with the apps tool when downloading extensions
Some of the items on the menu, under "system tools", don't seem to do anything...
"top" doesn't do anything unless aterm is loaded.
Both sda and sda1 appear in mnttool, which seems wrongish to me. /etc/fstab lists /dev/sda as type "dos" I suppose this might have to do with running core in a vm or with how the vd was created. I'll try it on hardware as soon as I can.
-
Looks like an issue with the apps tool when downloading extensions
Some of the items on the menu, under "system tools", don't seem to do anything...
"top" doesn't do anything unless aterm is loaded
aterm (or eventually another terminal app) is required for apps and several other ftlk applets to work.
Note also that some fltk apps (eg flit) will need recompiling to work
Both sda and sda1 appear in mnttool, which seems wrongish to me. /etc/fstab lists /dev/sda as type "dos" I suppose this might have to do with running core in a vm or with how the vd was created.
This appears on real hardware also - not yet sure what causes it
-
On a real hw there are mounting points like /mnt/sda /mnt/sdb etc., not only for the partitions.
-
I see fstype gives wrong results due to blkid giving a PTTYPE field.
-
I copied nfs-utils.tcz, portmap.tcz, and tcp_wrappers.tcz from 4.7 and verified that PXE booting with tce=nfs works.
-
Looks like an issue with the apps tool when downloading extensions
Some of the items on the menu, under "system tools", don't seem to do anything...
"top" doesn't do anything unless aterm is loaded
aterm (or eventually another terminal app) is required for apps and several other ftlk applets to work.
Since aterm is factored out of Xlibs, load updated Xprogs from 5.x repo. This has the Xprogs (apps & cpanel) using generic xterm. Then either load the new aterm, which set the link for xterm, or choose another terminal program (must set xterm link). Same applies for top when called from WM menu as well as for any X hosted CLI apps.
-
Thanks juanito and roberts.
Confirmed: Apps tool works as expected after aterm loaded. I suppose mc wouldn't have worked without it anyhow (under X). ;)
-
I copied nfs-utils.tcz, portmap.tcz, and tcp_wrappers.tcz from 4.7 and verified that PXE booting with tce=nfs works.
Thanks - copied over
-
grub2-efi uploaded in case anybody wants to test (u)efi boot.
Note that many (most?) machines seem to use 64bit (u)efi - in this case you'll need to use corepure64/grub2-efi to write the bootloader after which core64 (rootfs+modules64+vmlinuz64) will work.
Tested OK on a mac mini and dell e6220
-
* scm extensions have been dropped from this release
What are the reasons to drop .scm extensions? Is it more of a merging things together, or was the decision taken because of maintenance problems? ???
Not complaining. I'm just interested to know because I like to have 1x 40Meg extension independent, rather than 200+ tcz each dependant of the rest...
It's easier for me to manage the system that way.
I have to say that the scm extensions are often useful.
For example, are the only way for me to use libreoffice, since tcz version does not work with all versions of java on the repository and that I need to be able to use the version of java most useful for me.
And still, be able to unmount libreoffice when I do not need is a great way to keep free memory.
Or also i remember when scm were the only way to use gtk3.
I understand that this type of package has not been successful between the packagers, but being honest we must also admit that we hasn't made a work of due information on how to create this kind of packets, such as there is nothing on the wiki talk about how to create a scm.
I do not object to this decision, because undoubtedly one type of package less confusing than two, but I also hope that I can continue to use libreoffice without having to boot another distribution.
For the rest, I am very happy that development continues unabated, I hope that with the new xorg can use my touchscreen monitor again and so on!
-
..or it can be done like this:
CC="gcc -flto -fuse-linker-plugin -march=i486 -mtune=i686 -Os -pipe" CXX="g++ -flto -fuse-linker-plugin -march=i486 -mtune=i686 -Os -pipe -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local..which often results in significantly smaller executables and dynamic libs, but significantly larger static libs
Using LTO gain is varying. On mc (Midnight Commander) it is 3.4% on the .tcz
-
sylpheed-gtk1.tcz from the 4.x repo seems to be working on 5.0.alpha1 in my vm.
-
zile.tcz from the 4.x repo seems to be working on 5.0.alpha1 in my vm.
-
Fwiw, tce-load -i firefox.tcz from inside tce4/optional works and runs just fine under tc5 as long as lipng12.so* are copied from tc4's Xlibs.tcz into /usr/lib.
I use firefox 18.0.
-
What is about trying libpng.tcz from the 5.x repo and if necessary add a symlink?
-
What is about trying libpng.tcz from the 5.x repo and if necessary add a symlink?
Not working, that exact version of libpng is needed.
At the moment I can't reproduce the exact error messages.
-
Yep the PNG lib changed the API after 1.2.
-
(http://i40.tinypic.com/9s75us.png)
-
Hi: I am running the 5 version in same Virtual Box as the 4.7.7
For me it seems 5.0 alpha1boots slower and runs slower than 4.7.7
-
What does it mean "runs slower"?
-
Apps ondemand maintenance has incorrect left panel. Items in right panel also appear in left panel.
-
One feature of scm that would be great to have with tcz is the ability to install more than one version of a lib/app. Then extensions wouldn't break all the time.
-
They also won't break if you don't do updates between major releases.
RHEL learned this long ago.
-
by slower I mean that I think that it takes longer to have the terminal open and the prompt available than in 4.7.7
Same with the mc (midnight commander) extension. I have a rel. slow desktop AMDXP CPU so it might be hardware. What are other members experiencing here?
-
Hi beerstein
... so it might be hardware.
Or it might just be more apparent at a slower clock speed.
-
Opening MC from a GUI with Xvesa in a VM is instantaneous for me I don't think it was meant to be used in a gui but works well all the same
-
Opening MC from a GUI with Xvesa in a VM is instantaneous for me...
Works nicely for me, too, but not "instantaneous" by a long shot - though not distractingly slow. It might have something to do with the fact that I cut the memory in my VM from 1 GB back to 128 MB or the fact that I'm a total noob at virtualization.
-
Note that there is no necessary direct relation between boot time vs. operational speed of an OS.
-
Booted 5.0Alpha in a VM I noticed this message fly by during boot,
tsc: Fast TSC calibration failed
tsc: Unable to calibrate against PIT
tsc: using PMTIMER reference calibration
-
Booted 5.0Alpha in a VM I noticed this message fly by during boot,
tsc: Fast TSC calibration failed
tsc: Unable to calibrate against PIT
tsc: using PMTIMER reference calibration
It appears synchronization succeeds shortly after this message, so it appears safe to allow loglevel=3 to hide the previously failed attempt. (message only appears when using quiet boot code)
-
It's also worth noting that on two different machines I see several error messages when booting using the bios, but the error messages disappear when booting the same machines using (u)efi
-
Fwiw, tce-load -i firefox.tcz from inside tce4/optional works and runs just fine under tc5 as long as lipng12.so* are copied from tc4's Xlibs.tcz into /usr/lib.
tc-5.x libpng has been patched as per "Optional patch to include animated png functionality in libpng (required to use the system libpng in Firefox)"
..so it would be worth recompiling firefox for tc-5.x
-
There is a remasters/remix forum. Please read the guidlines in that forum.