Tiny Core Linux
Tiny Core Base => TCB News => Alpha Releases => Topic started by: roberts on May 11, 2010, 06:02:12 PM
-
Continuing on with 3.0 Alpha Testing (see: http://forum.tinycorelinux.net/index.php?topic=5949.0)
tinycore_3.0alpha2.iso is now available for testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release_candidates/tinycore_3.0alpha2.iso
Alpha 2 is bug fixes, tweaks, and adjustments.
* Updated wallpaper for new default background color.
* Updated .profile for flwm titlebar new color.
* Updated tce-setdrive and tc-restore.sh for better /tmp/tce test.
* Updated 55-tc-rules for better permission on ramzswap.
* Updated tc-functions with new getMajorVer and getMirror
* Updated tce-audit, tce-fetch.sh, tce-load, tce-update, and appbrowser for getMirror.
* Updated tce-setup for microcore .gzs in /opt/tce remaster
-
Wow you are fast. Great progress on tc3!
Testing Alpha2 now.
I'm not sure if getMajorVer and getMirror are supposed to work from the command terminal but I tried them out. The getMajorVer command returns 3 as expected but getMirror doesn't return anything. Is this correct?
-
In AppsAudit, The "On Demand Results" pane does not show current selections as it does in "On Boot".
Same is seen in V2.11.
-
I meant to ask this in the alpha1 thread:
What does this mean?
* delta extension updates as the default using zsync.
Sounds like only new version extensions are updated... but that was what was happening before...
-
I was wondering whether in the age of "unlimited loop devices" there is still a need to have 255 of them "hardcoded" in the initrd.
Maybe a little function (e.g. in 'tc-functions') to create an additional chunk of loop devices could be called (when required) by 'tce-load'.
-
Regarding zsync-
I have made .zsync files for all extensions in 2.x and 3.x. Also I make them for new extensions before uploading. Therefore when zsync.tcz is installed in your system, you will get the benefit of zsync when using the update function of Appsaudit. In other words, it is like with rsync and only the changed parts of extension files are downloaded. In the case of an extension like openoffice3.tcz, a change in the extension may only affect the menu entry or icon files. Without zsync, you would have to download the entire new 168MB extension to update it. With zsync, the difference that is downloaded may only be measured in kilobytes in that case. Possibly a huge savings in bandwidth when updating extensions.
-
I'm not sure if getMajorVer and getMirror are supposed to work from the command terminal but I tried them out. The getMajorVer command returns 3 as expected but getMirror doesn't return anything. Is this correct?
They are functions (are part of tc-functions as stated).
I was wondering whether in the age of "unlimited loop devices" there is still a need to have 255 of them "hardcoded" in the initrd.
Maybe a little function (e.g. in 'tc-functions') to create an additional chunk of loop devices could be called (when required) by 'tce-load'.
I think this was covered in the previous thread... it is covered by a certain revision in busybox.
-
Regarding zsync-
I have made .zsync files for all extensions in 2.x and 3.x. Also I make them for new extensions before uploading. Therefore when zsync.tcz is installed in your system, you will get the benefit of zsync when using the update function of Appsaudit. In other words, it is like with rsync and only the changed parts of extension files are downloaded. In the case of an extension like openoffice3.tcz, a change in the extension may only affect the menu entry or icon files. Without zsync, you would have to download the entire new 168MB extension to update it. With zsync, the difference that is downloaded may only be measured in kilobytes in that case. Possibly a huge savings in bandwidth when updating extensions.
This sounds interesting. In fact it sounds like zsync might be well considered to be in base instead of an extension, since this is such a central feature of tinycore.
(I haven't looked at zsync.tcz so don't know what it does but I can guess. Will look tonight.)
-
zsync is in the base of 3.0 and an option (extension) for 2.x.
-
My bad, I overlooked that zsync was in 3.x base.
-
Hi Robert!
It seems that the link is pointing at the now obsolete alfa 1 release that doesn't exist. I guess it would be a good thing to link to the tinycore 3.0 alfa 2 instead.
Have fun refining the tinycore 3.0,
meo
-
OK. Added a direct link to alpha2 iso.
-
All was running fine up to the point I did a 'Build dep reporting database' in AppsAudit. Then all the deps containing abc-2.6.33.3-tinycore.tcz became abc-KERNEL.tcz, and my system stopped working because it can't find those KERNEL dependencies.
KERNEL seems not getting parsed...?
-
I see some strange boot behavior in Alpha 2
with "quiet" boot mode enabled
In Alpha 1
- shows GRUB4DOS messages
- shows "Booting Tinycore_3.0alpha1" below the GRUB4DOS messages
(boot continues with more messages and finally TC desktop is shown)
In Alpha 2
- Shows GRUB4DOS messages
- Overwrites the GRUB4DOS messages on top of the screen with error message:
pci 0000:01:00.0: no compatible bridge window for [mem 0x80000000-0x8001ffff pref]
- after a fraction of a second clears the screen completely (you have to read really fast...)
- then shows "Booting Tinycore_3.0alpha2" on the top of the screen
(boot continues with more messages and finally TC desktop is shown)
It's the first time I see this particular error message
-
Check for a BIOS update for your machine.
-
>>> Check for a BIOS update for your machine.
This does not explain why Alpha1 (and 1.x and 2.x) boots correctly and Alpha2 does not.
The configuration of the machine has not changed
-
You could compare any relevant messages from `dmesg`
-
I have overwritten Alpha1 by Alpha2 on my system. I can't find Alpha1 any more in the TC download area. So I can't do the comparison at this time.
-
All was running fine up to the point I did a 'Build dep reporting database' in AppsAudit. Then all the deps containing abc-2.6.33.3-tinycore.tcz became abc-KERNEL.tcz, and my system stopped working because it can't find those KERNEL dependencies.
KERNEL seems not getting parsed...?
Found it. Fixed it. Thanks!
-
I see some strange boot behavior in Alpha 2
with "quiet" boot mode enabled
In Alpha 1
- shows GRUB4DOS messages
- shows "Booting Tinycore_3.0alpha1" below the GRUB4DOS messages
(boot continues with more messages and finally TC desktop is shown)
In Alpha 2
- Shows GRUB4DOS messages
- Overwrites the GRUB4DOS messages on top of the screen with error message:
pci 0000:01:00.0: no compatible bridge window for [mem 0x80000000-0x8001ffff pref]
- after a fraction of a second clears the screen completely (you have to read really fast...)
- then shows "Booting Tinycore_3.0alpha2" on the top of the screen
(boot continues with more messages and finally TC desktop is shown)
It's the first time I see this particular error message
Did you download distribution files or the iso?
Did you check md5sum to ensure a good download?
Since there was no change in kernel or modules for alpha1 to alpha2 and
since you are seeing error before "Booting Tiny Core.." I would start by checking that the download is good.
The only change, early in the boot proces, but after "Booting Tiny Core" was a change to permission on ramzswap. You could also try to boot using the 'embed' option to eliminate that change.
-
What is ramzswap ?
-
From change log of Alpha 1:
* compressed swap in ram -> able to run more and longer, less crashes due to out of ram
The system will use a portion of ram for compressed swap. Look in /etc/fstab.
-
Boot errors in Tiny Core 3.0 Alpha 2 (not present in Alpha 1 or 2.10 or 2.11).
I have TC installed in an ext2 sd card, from which I boot. After the EXTLINUX greetings, usual boot messages, when loading the Tiny Core Extension I get error messages and after a while the system boots.
Things go very fast, so I have only been able to read something like:
/etc/init.d/rcS : line 460 : usleep : text file busy
repeated about 20 times
after taht, sometimes it says 'done' and continues booting, while other times I get another error message before the 'done' and booting.
After rebooting with syslog enabled, I've found the following messages:
daemon.err udevd-work[594] exec of program '/sbin/modprobe' failed
daemon.err udevd-work[593] exec of program '/sbin/modprobe' failed
.... up to 10 times total (with different numbers inside the brackets), and then:
daemon.err udevd-work[671] exec of program '/bin/sh' failed
daemon.err udevd[93] can not read '/etc/udev/rules.d/56-lsusb.rules'
daemon.err udevd[93] can not read '/etc/udev/rules.d/64-md-raid.rules'
and then a lot of more info that seems normal to me (messages about mounting things from tce/optional)
I've booted several more times, and the syslog seems to vary:
* sometimes the daemon.err udevd-work[xxx] exec of program '/sbin/modprobe' failed are missing
* sometimes the daemon.err udevd[93] can not read '/etc/udev/rules.d/56-lsusb.rules' or daemon.err udevd[93] can not read '/etc/udev/rules.d/64-md-raid.rules' is missing
Hope it helps
-
I downloaded the ISO for alpha2.
I have checked the md5 and it was correct
I boot already with "embed"
-
From change log of Alpha 1:
* compressed swap in ram -> able to run more and longer, less crashes due to out of ram
The system will use a portion of ram for compressed swap. Look in /etc/fstab.
Yeah, I have seen it there but never seen ramzswap before in other distros. Does it have a fixed (max) size? How is it determined? What is about low mem systems? Is it always there or can be disabled (boot code)?
-
@bmarkus: LWN article on it http://lwn.net/Articles/334649/
Many live cds use it nowadays, including Ubuntu. It's set at 25% of ram, and can be disabled with the embed bootcode.
Even on really low-ram systems it usually helps more than it hurts.
-
@bmarkus: LWN article on it http://lwn.net/Articles/334649/
Many live cds use it nowadays, including Ubuntu. It's set at 25% of ram, and can be disabled with the embed bootcode.
Even on really low-ram systems it usually helps more than it hurts.
Thanks! Just a side note, I'm not using UBUNTU, LUBUNTU, EDUBUNTU, XBUNTU, ... In the last 9 monthes using only TC or trying other distros for a short time to see which packages they are using, how DE configured, etc. And running CentOS 5 for home file and mail server, VoIP switch, special amateur radio applications, etc.
-
Didn't mean Ubuntu like that, just thought of a high-profile user of the project. :)
-
Is there a 3.0 version of firewall-2.6.29.1-tinycore.tcz? Perhaps the name changed for 3.0?
Enjoying 3.0 alpha. Great work TC team!!!!
Best regards,
sci_fi
-
Pure idle curiosity: How did the team pick a kernel version?
-
Is there a 3.0 version of firewall-2.6.29.1-tinycore.tcz? Perhaps the name changed for 3.0?
Enjoying 3.0 alpha. Great work TC team!!!!
Best regards,
sci_fi
Yes, the new name is netfilter-xxx. Note that iptables might need an update, not sure if the 2.x iptables runs fine with the new kernel.
Pure idle curiosity: How did the team pick a kernel version?
Early plans were either .33 or .34. After .33 was stable, we tested it and the patchlevels, but faced oopses until 33.3.
-
Boot errors in Tiny Core 3.0 Alpha 2 (not present in Alpha 1 or 2.10 or 2.11).
I have TC installed in an ext2 sd card, from which I boot. After the EXTLINUX greetings, usual boot messages, when loading the Tiny Core Extension I get error messages and after a while the system boots.
Things go very fast, so I have only been able to read something like:
/etc/init.d/rcS : line 460 : usleep : text file busy
repeated about 20 times
after taht, sometimes it says 'done' and continues booting, while other times I get another error message before the 'done' and booting.
After rebooting with syslog enabled, I've found the following messages:
daemon.err udevd-work[594] exec of program '/sbin/modprobe' failed
daemon.err udevd-work[593] exec of program '/sbin/modprobe' failed
.... up to 10 times total (with different numbers inside the brackets), and then:
daemon.err udevd-work[671] exec of program '/bin/sh' failed
daemon.err udevd[93] can not read '/etc/udev/rules.d/56-lsusb.rules'
daemon.err udevd[93] can not read '/etc/udev/rules.d/64-md-raid.rules'
and then a lot of more info that seems normal to me (messages about mounting things from tce/optional)
I've booted several more times, and the syslog seems to vary:
* sometimes the daemon.err udevd-work[xxx] exec of program '/sbin/modprobe' failed are missing
* sometimes the daemon.err udevd[93] can not read '/etc/udev/rules.d/56-lsusb.rules' or daemon.err udevd[93] can not read '/etc/udev/rules.d/64-md-raid.rules' is missing
Hope it helps
Replaced bzImage and tinycore.gz from alpha2 with a copy from alpha1 and all the errors are gone. Therefore I think there is clearly a problem with alpha2
-
The b44 network driver is broken.
Excerpt from dmesg shown below.
b44: Unknown symbol ssb_device_is_enabled
b44: Unknown symbol ssb_pcicore_dev_irqvecs_enable
b44: Unknown symbol ssb_bus_may_powerdown
b44: Unknown symbol ssb_dma_free_consistent
b44: Unknown symbol ssb_pcihost_register
b44: Unknown symbol ssb_device_disable
b44: Unknown symbol ssb_dma_alloc_consistent
b44: Unknown symbol ssb_dma_set_mask
b44: Unknown symbol ssb_device_enable
b44: Unknown symbol ssb_driver_unregister
b44: Unknown symbol __ssb_driver_register
b44: Unknown symbol ssb_bus_powerup
b44: Unknown symbol ssb_clockspeed
b44: Unknown symbol ssb_dma_translation
-
Ah, I was under the impression that only Broadcom wireless required ssb. Will add in the base for the next alpha.
-
Thanks.
-
Moving on to alpha3