Tiny Core Base > Alpha Releases
Tiny Core 5.0 Alpha 1 Testing
pioj:
--- Quote ---* scm extensions have been dropped from this release
--- End quote ---
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:
--- Quote from: caminati on May 30, 2013, 12:37:31 PM ---Sometimes tce-load -i hangs.
After a quick check, looks like "sudo (busybox) depmod -a" is the cause.
--- End quote ---
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: ---qemu.exe -L . -m 1024 -hda tc477.img -boot c -soundhw sb16,es1370 -localtime -M pc
--- End code ---
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: ---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/
--- End code ---
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: ---/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
--- End code ---
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:
--- Quote from: Lee on May 30, 2013, 01:47:05 PM ---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
--- End quote ---
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
--- Quote ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version