Tiny Core 5.0 Alpha 1 Testing

[Juanito]

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.

[caminati]

Great! Glad to hear that, and rushing to test it.

[Juanito]

Note that with this version of gcc, extensions can be compiled in the usual way:

Code: [Select]

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:

Code: [Select]

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

[caminati]

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.

[caminati]

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.

[pioj]

* 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.

[caminati]

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.

[Lee]

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:

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

/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.

[Juanito]

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

[bmarkus]

On a real hw there are mounting points like /mnt/sda /mnt/sdb etc., not only for the partitions.

[curaga]

I see fstype gives wrong results due to blkid giving a PTTYPE field.

[gerald_clark]

I copied nfs-utils.tcz, portmap.tcz, and tcp_wrappers.tcz from 4.7 and verified that PXE booting with tce=nfs works.

[roberts]

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.

[Lee]

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).   

[Juanito]

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