Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: roberts on January 04, 2010, 01:19:42 PM
-
The First Release Candidate of v2.8 (tinycore_2.8rc1.iso), is now posted and ready for testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release_candidates
tinycore_2.8rc1.iso
tinycore_2.8rc1.iso.md5.txt
Change log for Tiny Core v2.8rc1
* Updated tce-load to allow miltiple loading, e.g., tce-load -i *.tcz
* Updated tce-load to drop ".tcz" requirement.
* Updated appsaudit to allow selective removal of items from "marked for deletion"
* Updated appsaudit to allow operation in tce directory as well as tce/optional directory, use File option.
* Updated appsaudit menu for smoother operation.
* Updated cd_dvd_symlinks.sh for better multiple cd and dvd devices.
* Cleanup of tce-setup & tce-update of l,m,lm, and ml code.
* Updated tce-fetch.sh to cleanup old dual repository support.
* Updated tce-update to prompt before beginning easy mode batch update operation.
* After much Team testing and input, the upx'ed kernel returns, prior kernel is in distribution files.
* Dropped symlinker by using builtin cp construct.
* Dropped GNU ftp from base.
Now at 9.9MB
-
Hi! Happy new year! I'm always excited to see a new RC!
At this point, I have two questions. First, when are we moving to next kernel version? Second, how much space is saved by removing ftp?
Thanks for your great work!
-
The First Release Candidate of v2.8 (tinycore_2.8rc1.iso), is now posted and ready for testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release_candidates
tinycore_2.8rc1.iso
tinycore_2.8rc1.iso.md5.txt
Change log for Tiny Core v2.8rc1
* Updated tce-load to allow miltiple loading, e.g., tce-load -i *.tcz
* Updated tce-load to drop ".tcz" requirement.
* Updated appsaudit to allow selective removal of items "marked for deletion"
* Updated appsaudit to allow operation in tce directory as well as tce/optional directory, use File option.
* Updated appsaudit menu for smoother operation.
* Updated cd_dvd_symlinks.sh for better multiple cd and dvd devices.
* Cleanup of tce-setup & tce-update of l,m,lm, and ml code.
* Updated tce-fetch.sh to cleanup old dual repository support.
* Updated tce-update to prompt before beginning easy mode batch update operation.
* After much Team testing and input, the upx'ed kernel returns, prior kernel is in distribution files.
* Dropped symlinker by using builtin cp construct.
* Dropped GNU ftp from base.
Now at 9.9MB
Robert, just out of curiosity, what did you discover was wrong with the previous attempt to use the upx'ed kernel ?
-
If items are not required by base infrastructure they become candidates for removal, as per our philosphy of a tiny core. ftp serves no purpose in core and is therfore better handled as an extension,
Since a new kernel means new modules means new repository, means many many extensions will have to be updated, moving to a newer kernel is not something to be done often.
The Team is evaluating a new kernel with a possible target of March/April. It is still tenative at this time.
-
Robert, just out of curiosity, what did you discover was wrong with the previous attempt to use the upx'ed kernel ?
At the time, I did not have much in the way of equipment and virtual machines to test it, so I dropped it.
Since then the entire Team has been testing on various devices, isolinux, cdroms, virtual machines and could not get a failure. So perhaps the issue is directly related to specific hardware or BIOS. Therefore, as a Team decision, we decided to use the smaller kernel while offering the un-upxed version in the distrubtion file area.
-
Can you explain why the symlinker line in tce-load is
sudo cp -as /tmp/tcloop/"$APPNAME"/. /
instead of
sudo cp -as /tmp/tcloop/"$APPNAME"/* /
the first gives as result
/usr/local/bin/dillo -> /tmp/tcloop/dillo2/./usr/local/bin/dillo
you have a spurious "/./"
the second line gives a clean link
/usr/local/bin/dillo -> /tmp/tcloop//dillo2/usr/local/bin/dillo
except for this both lines seem to work the same....
Only a detail - more interested in the reason behind this than in the "fix"
I suppose there is a side effect I don't know
-
Could probably use
sudo cp -as /tmp/tcloop/"$APPNAME"
-
Thanks, for the feedback. Will clean it up.
-
* After much Team testing and input, the upx'ed kernel returns, prior kernel is in distribution files.
I was one of the victims in tha last cycle of of the upx'ed kernel on my ACER ASPIRE 5720Z notebook experiencing booting problems and random feezes. Now booting works fine after 8-10 tries, but still I see random freezes frequently when using 2.8rc1
As I remember I was not the only one. For sure we need the standard kernel and there will be otheres, not reporting it just simply throw away TC/MC after testing.
I kindly ask not to use upx'ed kernel. Gain is musch less than trouble caused.
-
* Dropped GNU ftp from base.
It is true, that ftp is not really needed in the base, however there are some basic tools what is expected to be in all LINUX distribution, like telnet, ping, ... In TC most of them are provided by busybox and I don't think ftp with its 62k is harming too much.
What is about dropbearmulti? It is double sized compared to ftp and for sure SSH is not used by most of the users.
-
* Dropped GNU ftp from base.
It is true, that ftp is not really needed in the base, however there are some basic tools what is expected to be in all LINUX distribution, like telnet, ping, ... In TC most of them are provided by busybox and I don't think ftp with its 62k is harming too much.
What is about dropbearmulti? It is double sized compared to ftp and for sure SSH is not used by most of the users.
I strongly disagree regarding dropbear. I use it all the time for remote access to my MC based web server. I agree with removing ftp. I use proftp when I need it but now mostly use vpn access to the local net and then use samba for file sharing.
[^thehatsrule^: fixed post]
-
I did not say dropbear is useless neither that nobody is using. Just asked what is about to move it out to extension, that's all. It would make also easier to use alternative ssh clients or servers.
-
I did not say dropbear is useless neither that nobody is using. Just asked what is about to move it out to extension, that's all. It would make also easier to use alternative ssh clients or servers.
OK, I see your point.
-
i also see the point regarding ftp; it is not essential to have it in the base; i have found that dropbear behave better than the current openssh.tcz extension which seems to have critical issues; openssh lets you login as root (i find this feature very risky), does not seem to handel private/public keys correctly (you can still connect with password), and does not seem to catch the modifications you enter in your sshd_config file; dropbear behave as expected, and you can run sshfs and sftp with some tricks
-
Robert, just out of curiosity, what did you discover was wrong with the previous attempt to use the upx'ed kernel ?
At the time, I did not have much in the way of equipment and virtual machines to test it, so I dropped it.
Since then the entire Team has been testing on various devices, isolinux, cdroms, virtual machines and could not get a failure. So perhaps the issue is directly related to specific hardware or BIOS. Therefore, as a Team decision, we decided to use the smaller kernel while offering the un-upxed version in the distrubtion file area.
Have they tried it in a plain VirtualBox "Live" session, just creating a virtual machine with all the defaults, except no hard drive? Every time I've tried it with these UPX'd kernels, just booting off the raw .iso, I get the same message from ACPI: "Unable to load the System Description Tables". Seems like the UPX'd kernels were giving some people running on real systems a headache, too.
If we're going for size and compatibility, I'd say we seem to be better off with a non-UPX'd kernel, rather than a compressed one.
-
openssh lets you login as root (i find this feature very risky),...
This is not true. Just add
PermitRootLogin no
to /etc/ssh/sshd_conf. You can also define access on per user basis as to configure many other parameters. As OpenSSH used by REDHAT ENTERPRISE LINUX, CentOS and many other servers, driving more than 50% of the WEB applications worldwide I do not expect any serios security issues with it.
-
Lets keep the openssh discussion in its original thread. I have posted a follow-up there that may be helpful http://forum.tinycorelinux.net/index.php?topic=4471.0
-
ok, i replied on the openssh thread; by the way, i am not criticizing openssh, i just say that the tcz extension does not seem to behave as it should; so try to disable the root login in sshd_config file, and try to login as root again; i can login in as root in my server even if i disable the root login in the sshd_config file, i.e. turn it to ´no´ (and comment that line out).
-
* After much Team testing and input, the upx'ed kernel returns, prior kernel is in distribution files.
I kindly ask not to use upx'ed kernel. Gain is musch less than trouble caused.
Maybe the solution would be to move to a newer kernel. Starting from 2.6.30 (or so), the kernel image ("bzImage") can be LZMA-compressed, and so can the initram filesystem ("tinycore.gz," which would then become "tinycore.lzm"). It's a kernel configuration option, no third-party tools such as UPX are needed. Other advantages: the testing is/has been done by the larger Linux community (beyond TinyCore); and: there is an established trouble-shooting team, namely the kernel guys :-)
-
lzma makes the system boot too slow. We have tried it.
I know many are rich and can afford powerful machines, but not I and likely many others.
-
Robert, just out of curiosity, what did you discover was wrong with the previous attempt to use the upx'ed kernel ?
At the time, I did not have much in the way of equipment and virtual machines to test it, so I dropped it.
Since then the entire Team has been testing on various devices, isolinux, cdroms, virtual machines and could not get a failure. So perhaps the issue is directly related to specific hardware or BIOS. Therefore, as a Team decision, we decided to use the smaller kernel while offering the un-upxed version in the distrubtion file area.
Have they tried it in a plain VirtualBox "Live" session, just creating a virtual machine with all the defaults, except no hard drive? Every time I've tried it with these UPX'd kernels, just booting off the raw .iso, I get the same message from ACPI: "Unable to load the System Description Tables". Seems like the UPX'd kernels were giving some people running on real systems a headache, too.
If we're going for size and compatibility, I'd say we seem to be better off with a non-UPX'd kernel, rather than a compressed one.
I should defer this to one who has tested it. But I recall an update to the latest version of VirtualBox is required.
-
* After much Team testing and input, the upx'ed kernel returns, prior kernel is in distribution files.
I was one of the victims in tha last cycle of of the upx'ed kernel on my ACER ASPIRE 5720Z notebook experiencing booting problems and random feezes. Now booting works fine after 8-10 tries, but still I see random freezes frequently when using 2.8rc1
As I remember I was not the only one. For sure we need the standard kernel and there will be otheres, not reporting it just simply throw away TC/MC after testing.
I kindly ask not to use upx'ed kernel. Gain is musch less than trouble caused.
Duly noted. It was a team decision to try it again and will ultimately be a Team decision before final 2.8
May I ask how is Tiny Core Installed on such device? Is not having easy access to the original kernel not satisfactory?
For the moment I will be making an incompatible hardware list. So far, one item listed.
If there are other, speak now.
-
I'm also one of those users that use TC on VirtualBox. Even running the latest version (VB 3.1.2, under XP) produces the previously reported error messages at the very start of the boot process:
ACPI: Unable to load System Description Tables
IO APIC resources could not be allocated.
These messages did not appear with TC 2.7. The respective "dmesg" output also shows some differences (which can be made available). As much as I can tell those differences are all related to memory layout and (virtual) hardware detection.
During the (so far rather light) use of 2.8rc1 I have only come across the following difference in behaviour to 2.7, which seems related to those error messages: The VM needs to be manually closed (i.e. "switched off") after the shutdown of TC. The same was previously not required, but IIRC was also seen with the first trial with the "UPX kernel".
All this is (so far) in my view not a real show stopper, since it's easy to live with this regression. But I guess only more testing will tell ...
-
Duly noted. It was a team decision to try it again and will ultimately be a Team decision before final 2.8
May I ask how is Tiny Core Installed on such device? Is not having easy access to the original kernel not satisfactory?
For the moment I will be making an incompatible hardware list. So far, one item listed.
If there are other, speak now.
USB install with UNETBOOTIN. For me it is not a problem to replace the kernel with older, recompile, repack or whatever needed. If I'm affected only I can manage. Question is, what is about others having the same problem, if there are any.
Hopefully I will have access to another notebook with the same type where I can test it to exclude unique issue with my machine.
Also would be good to find others in the community using ACER ASPIRE 57xx or similar machines.
-
i am also unable to boot mc 2.7 and tc 2.7 on an aleutia E1 with 128 mb ram and a SiS processor, getting the message:
IO APIC resources could not be allocated.
i did not test it with the new rc.
-
VirtualBox 3.1.2r56127 (win64, win32, linuxMint 5 x86 - & Debian 5.0 x64 hosts)
I've just been booting with the raw .iso, which produces the ACPI errors.
I rebuilt the .iso using the non-UPX'd bzImage, and it works fine.
Is there any more information about my setup that would be useful? Debug logs, dmesg output, the VirtualBox .xml file, etc?
-
I kindly ask not to use upx'ed kernel. Gain is musch less than trouble caused.
I am an end user, not a contributor, so I do not have much saying in decision making process here. However I would like to agree with Bmarkus that the compressed kernel appears not worth of all the compatibility issues... If this community experiences quite a few issues linked to compressed kernel on such a small spectrum of hardware, this extrapolates to me that it is not expected to be behaving reliably on wide range of hardware. Instead of sure boot on most any machine we will be facing a 'maybe it will work' situation when we stick this CD in a new machine...
What is so compelling that we are gaining with this compressed kernel except a little space saved?
-
Hopefully I will have access to another notebook with the same type where I can test it to exclude unique issue with my machine.
Unfortunately couldn't test as machine was moved to country side :(
-
After feedback from this thread and Team discussion, it has been decided to drop dropbearmulti from base. It is not needed or used to bring up the system. By dropping it, as was pointed out, eases the use of openssh, a more fully featured version.