Tiny Core Linux

Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: roberts on July 17, 2011, 10:30:23 AM

Title: tinycore_v3.8rc2
Post by: roberts on July 17, 2011, 10:30:23 AM
The Second Release Candidate of Tiny Core v3.8 is now posted and ready for testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release_candidates

tinycore_3.8rc2.iso
tinycore_3.8rc2.iso.md5.txt

Change log:
rc1
* New icons for AppBrowser and AppsAudit.
* Updated mnttool - added a refresh button.
* Updated AppsBrowser - clear Search&Provides field upon results.
* Updated Wallpaper - Improved GUI. Now with a single window.
* Updated AppsAudit - updated error reporting and now reports stale extensions.
* Updated tce-load - now allows re-downloading non-installed extensions to better handle download failures.
* Updated tce-setup & tce-load to ensure busybox calls thus avoiding conflicts with gnu utilities.
* Updated rc.shutdown - removed sleep to improve shutdown speed.

rc2
* Updated AppsAudit - md5 function slowness corrected.
* Updated wbarconf - support for no initial .wbar
* Updated busybox  -  1.18.5 new depmod applet and audit of required applets.
* Updated search.sh  - improved searching by title results and support for fat file-system.
* Updated provides.sh  - support for fat file-system.
* Updated tce-setup, tce-load, and loadpack.sh - alias for new depmod applet.
* Updated .profile - new user login sudo issue resolved.
* Removed remnant .wbar from /etc/skel
* Updated AppBrowser & AppsAudit icons - slightly larger

Note: depmod has been moved to extensions, gnu depmod may be required by certain extensions, e.g., alsa.
Title: Re: tinycore_v3.8rc2
Post by: netnomad on July 17, 2011, 12:25:37 PM
hi roberts,

the md5sum-check is now just like a dream again! good job!
now i have only the problem to restore my backup.
3.8rc1 worked just fine for me, but in 3.8rc2 my encrypted backup isn't restored anymore.
the error message in red letters disappears so fast that i can't read it...

this is the entry of my multibootiso-config

title MicroCore testing
find --set-root /microcore-testing.iso
map /microcore-testing.iso (hd32) || map --mem /testing-testing.iso (hd32)
map --hook
kernel (hd32)/boot/bzImage waitusb=5 protect restore=LABEL=tc laptop mydata=mc-test multivt
initrd (hd32)/boot/microcore.gz
boot

thank you for your help!
Title: Re: tinycore_v3.8rc2
Post by: roberts on July 17, 2011, 01:53:21 PM
Fixed encrypted restore. Reposted rc2.
Title: Re: tinycore_v3.8rc2
Post by: netnomad on July 17, 2011, 02:29:21 PM
now it restores just fine... thank you!
Title: Re: tinycore_v3.8rc2
Post by: maro on July 17, 2011, 04:35:48 PM
Robert, as I can see that BusyBox got rebuild I wonder whether this suggestion (http://forum.tinycorelinux.net/index.php?topic=9717.0) (i.e. to include the 'stat' applet) was considered and revoked or has it just "fallen through the cracks"?

Furthermore I'd like to pause for a moment to lament the removal of 'uuencode' / 'uudecode' from the Core. Those might be rather ancient tools in the eyes of many who have not known the limitations of 7-bit ASCII emails (e.g. in the early 1990). I for one can still see their use in allowing the inclusion of binary blobs (e.g. icon files) in scripts to build an extension. True, those tools live on in the 'shareutils.tcz' extension, but until now one could rely on the fact that they were there right "out of the box".
Title: Re: tinycore_v3.8rc2
Post by: roberts on July 17, 2011, 08:29:13 PM
Maro, busybox was scheduled to be rebuilt at 1.19. However, the team brought up the topic of slimming busybox. With the premise that if an applet is not required by the base then it should be considered for removal. Thus an audit occurred and several unused applets were removed. This was a team decision. This is consistent with the philosophy of Core. If you wish to add/remove other applets then it should be discussed for team consideration. Perhaps some of the team will share their thoughts on this matter and the resulting decision.
Title: Re: tinycore_v3.8rc2
Post by: danielibarnes on July 17, 2011, 08:40:34 PM
Quote
until now one could rely on the fact that they were there right "out of the box".

I felt the same way about dropbear. I really missed it, but I understand that the core needs to be true to itself. Remastering it back in as an extension was trivial, anyway. Is there a detailed list of busybox applets which were removed and which extensions include the replacements?
Title: Re: tinycore_v3.8rc2
Post by: roberts on July 17, 2011, 08:50:48 PM
This was the result from the audit.
The new binary is about 11K smaller with these applets disabled:
-dhcprelay
-dnsd
-fakeidentd
-telnetd
-pscan
-uudecode
-uuencode
-zcip

I am mainly focused on Core custom so not big on extensions,  perhaps Brian or other team members will chime in for replacements.
Title: Re: tinycore_v3.8rc2
Post by: ixbrian on July 17, 2011, 10:03:07 PM
Hi Maro,
Regarding 'stat', my personal opinion is that it would be useful to have included in Core because in my opinion it is a standard/essential UNIX command.  

Regarding 'uuencode' / 'uudecode', they were flagged as a possible candidate for removal because they are not used anywhere in the base system.  I totally agree with you that these commands can be useful and I have used them myself, however in my opinion they are not essential UNIX commands and therefore should be available via an extension rather than in base.  For example, Ubuntu 11.04 does not include uuencode or uudecode in the default install.  

Regarding Extension replacements for the removed BusyBox applets:

-dhcprelay - This relays DHCP requests between other computers on the local subnet to a DHCP server on a different subnet.  There isn't an extension I am aware of that provides this.  If there are people who need this functionality I would be happy to create an extension of a build of BusyBox that includes just this applet.  

-dnsd - DNS server, see bind.tcz

-fakeidentd - Probably not used by anyone.  Again, if there is a demand for this I would be happy to create a 1 applet BusyBox extension that provides this.  

-telnetd - Telnet server, see inetutils-servers.tcz

-pscan - port scanner, see nmap.tcz

-uudecode/uuencode - See sharutils.tcz

-zcip - Zero config IP setup.   Probably not used by anyone.  I could create an extension if needed.  

I would be more than happy to create a new extension that contains just a single BusyBox applet if these commands are needed by anyone.   See busybox-httpd.tcz as an example of where a single BusyBox applet was turned in to an extension.  

Thanks,
Brian
Title: Re: tinycore_v3.8rc2
Post by: Lee on July 18, 2011, 09:36:49 AM
Quote
I would be more than happy to create a new extension that contains just a single BusyBox applet if these commands are needed by anyone.

I haven't done a lot of compiling of -anything- lately and I haven't actually -looked- at the busybox sources, but it seems to me that:

- the busy box source code must include an enormous amount of useful stuff
- busybox, as compiled for tc base, prunes out much of that to stay lean
- what's included in a busybox build is controlled by a fairly simple config list
- busybox behaves differently based upon the name by which it is invoked but it doesn't much matter what the busybox file is named - could be busybox or mybusybox or busyboxplus.

Would it be feasible to put together a busybox-dev.tcz with all the sources ready to compile so all the user has to do is tweak the config to include the desired additional applets and compile "mybusybox" to be packaged up as a personal extension.

Or is not quite that easy?  I can see how such might not be for the average noob if there's rocket science involved.

Title: Re: tinycore_v3.8rc2
Post by: curaga on July 18, 2011, 09:50:23 AM
Lee, what you're describing is almost what the busybox source tarball is ;)

make menuconfig && make && make install
Title: Re: tinycore_v3.8rc2
Post by: gerald_clark on July 18, 2011, 09:58:52 AM
Perhaps a complete busybox initrd would be preferable.
It would completely replace the one in base, and there would not be two copys present.
Title: Re: tinycore_v3.8rc2
Post by: Lee on July 18, 2011, 12:58:16 PM
@ curaga: You make it sound so easy that now I have to go play with it some.  :)

@ gerald_clark: I started down that path in my previous post then backed out that part because I always lean toward keeping the base intact - just a personal pref.

(an hour passes)

OK.  That -was- easy.  Read README and INSTALL from the busybox source tarball.  Loaded up compiletc.  Built busybox with just uuencode and uudecode (and a few others that looked interesting).

edit: corrected typo. 20110718 2146
Title: Re: tinycore_v3.8rc2
Post by: ixbrian on July 18, 2011, 03:14:29 PM
Perhaps a complete busybox initrd would be preferable.
It would completely replace the one in base, and there would not be two copys present.

By complete busybox initrd, do you mean an extension?   If so, it probably would not be a good idea to have an extension (full BusyBox) replace functionality (BusyBox) in Core.   In my opinion this would be a recipe for problems down the road (for example if the extension BusyBox version, options, etc. where ever out of sync with the Core BusyBox)

Brian
Title: Re: tinycore_v3.8rc2
Post by: floppy on July 18, 2011, 11:57:42 PM
rc1
...
* Updated mnttool - added a refresh button.
...

My feedback:
- Refresh button: very good
- A bit disturbing: after boot, the mntool window is top right. By clicking "refresh", it jumps top left (over my conky window).
Title: Re: tinycore_v3.8rc2
Post by: andrewb on July 19, 2011, 12:16:53 AM
Just a thought  as wbar updates are mentioned...

Could wbar be made suitable for swallowing in a JWM tray? For netbooks this would be a bonus
Title: Re: tinycore_v3.8rc2
Post by: maro on July 19, 2011, 07:45:20 PM
As 'time-nw.nist.gov' appears to have been AWOL now for a while (i.e. no response even with a 'ping') I'd like to suggest to change 'usr/bin/getTime.sh' to use 'time.nist.gov' instead.
Title: Re: tinycore_v3.8rc2
Post by: danielibarnes on July 19, 2011, 07:52:02 PM
As 'time-nw.nist.gov' appears to have been AWOL now for a while (i.e. no response even with a 'ping') I'd like to suggest to change 'usr/bin/getTime.sh' to use 'time.nist.gov' instead.

Why not pool.ntp.org (http://www.pool.ntp.org/en/use.html)?
Title: Re: tinycore_v3.8rc2
Post by: vitex on July 19, 2011, 08:46:30 PM
As 'time-nw.nist.gov' appears to have been AWOL now for a while (i.e. no response even with a 'ping') I'd like to suggest to change 'usr/bin/getTime.sh' to use 'time.nist.gov' instead.

Why not pool.ntp.org (http://www.pool.ntp.org/en/use.html)?

getTime.sh uses Daytime Protocol (RFC-867), not Network Time Protocol (RFC-1305). 

Note that http://tf.nist.gov/tf-cgi/servers.cgi (http://tf.nist.gov/tf-cgi/servers.cgi) recommends using neither time-nw.nist.gov nor time.nist.gov.
Title: Re: tinycore_v3.8rc2
Post by: uggla on July 20, 2011, 01:00:33 AM
I'm unable to mount any dvd if a disc was in the player during boot. Mounting dvds works if player was empty during boot.

I'm running mc with xorg 7.5.
Title: Re: tinycore_v3.8rc2
Post by: TheNewbie on July 20, 2011, 04:07:22 AM
About the busybox applet removals -- TC is approximately 10 MB total, and I, personally, feel that any functionality loss isn't worth a gain of 11 KB of more space. Considering 10 MB is over 10000 KB, 11 KB is, what, 0.1% of the total size? Just IMHO, of course -- if the team feels otherwise, it's obviously not my decision to make. =P
Title: Re: tinycore_v3.8rc2
Post by: Rich on July 20, 2011, 09:51:10 AM
Hi TheNewbie
Quote
Considering 10 MB is over 10000 KB, 11 KB is, what, 0.1% of the total size?
That is same the narrow minded thinking the U.S. government uses to rationalize spending, you might
want to take a look at how that is working out.
Luckily, roberts takes the time to try to balance the size of Tinycore against what will benefit the most
users. The decisions that he makes are not to please everyone, they are to provide you with a lean
core for an operating system so that you as the end user can customize it to your personal needs
by adding the functions and niceties desired through the use of extensions.
It is because roberts pays attention to the size of a function that Tinycore can maintain it's roughly
10MB footprint instead of growing out of control.
Title: Re: tinycore_v3.8rc2
Post by: TheNewbie on July 20, 2011, 03:33:03 PM
Hi TheNewbie
Quote
Considering 10 MB is over 10000 KB, 11 KB is, what, 0.1% of the total size?
That is same the narrow minded thinking the U.S. government uses to rationalize spending, you might
want to take a look at how that is working out.

Luckily, roberts takes the time to try to balance the size of Tinycore against what will benefit the most
users. The decisions that he makes are not to please everyone, they are to provide you with a lean
core for an operating system so that you as the end user can customize it to your personal needs
by adding the functions and niceties desired through the use of extensions.

It is because roberts pays attention to the size of a function that Tinycore can maintain it's roughly
10MB footprint instead of growing out of control.

The issue with that is the US govt. has reason to rationalize spending, because it's debt is in the trillions -- it shouldn't have any spending, period.

I realize that perhaps the team might decide that those 11KB of whatever features are useless. When you've fit the entire OS into 10 MB (2 MB of which is just in the kernel), though, cutting back features without needing that space for others might be too much. Like I said, this is IMHO, I'm not trying to impose it on the team.
Title: Re: tinycore_v3.8rc2
Post by: maro on July 20, 2011, 05:44:08 PM
Note that http://tf.nist.gov/tf-cgi/servers.cgi (http://tf.nist.gov/tf-cgi/servers.cgi) recommends using neither time-nw.nist.gov nor time.nist.gov.

This might be true, but if they can't even update their page to show that 'time-nw.nist.gov' is unavailable (since quite some weeks now) I wonder how much we can trust their recommendations at all.

OTHO there will be only few TC users which are using this command, and I'd bet very few are running this on a regular basis (e.g. via 'cron'). I for one only need it if I have a TC system running in a VM were the host (e.g. WinXP in my case) gets hibernated over night and I want to sync up the time in the VM again. That creates typically one request from me per day. So I can't see that changing the server to 'time.nist.gov' in TC will put an undue burden on that server. I assume their recommendation is more targeting the users of frequently syncing services (e.g. NTP).

In the end don't care what server receives the "massive hit" that the TC users will jointly create. I just want that the command starts working again without having to remember every time that Microsoft (who "owns" 131.107.13.100) can't keep their house in order and I therefore have to use something like getTime.sh time.nist.gov (instead of getTime.sh).

Title: Re: tinycore_v3.8rc2
Post by: vitex on July 20, 2011, 08:56:00 PM

In the end don't care what server receives the "massive hit" that the TC users will jointly create. I just want that the command starts working again without having to remember every time that Microsoft (who "owns" 131.107.13.100) can't keep their house in order and I therefore have to use something like getTime.sh time.nist.gov (instead of getTime.sh).


The "All services busy, not recommended" comment about time.nist.gov is there for a reason:

Code: [Select]
$ date +%s ; nc time.nist.gov 13 ; date +%s
1311218229
time.nist.gov [192.43.244.18] 13 (daytime) : Connection timed out
1311218250

$ date +%s ; nc time.nist.gov 13 ; date +%s
1311218272

55763 11-07-21 03:17:54 50 0 0 522.3 UTC(NIST) *
1311218273

$ date +%s ; nc time.nist.gov 13 ; date +%s
1311218284
time.nist.gov [192.43.244.18] 13 (daytime) : Connection timed out
1311218305
 

NIST is warning that that server (among others) is already so overloaded that it is not dependable. 

The server wwv.nist.gov seems to be a more reliable choice for a Daytime server.  (An NTP-based solution would be even better if you can afford a bit more RAM.  Chrony uses multiple pool.ntp.org servers and requires no user configuration.)
Title: Re: tinycore_v3.8rc2
Post by: roberts on July 22, 2011, 02:28:27 PM
As 'time-nw.nist.gov' appears to have been AWOL now for a while (i.e. no response even with a 'ping') I'd like to suggest to change 'usr/bin/getTime.sh' to use 'time.nist.gov' instead.
Updated getTime.sh to use time.nist.gov
Title: Re: tinycore_v3.8rc2
Post by: vitex on July 22, 2011, 05:04:16 PM

Updated getTime.sh to use time.nist.gov

The overloaded server time.nist.gov is not a good choice; it sometimes times out and fails to set the clock.

The following results show the response times for 5 consecutive requests made at 10-second intervals:

Code: [Select]
$ while true ; do echo ; time getTime.sh -p time.nist.gov ; sleep 10 ; done

Fri Jul 22 23:17:51 UTC 2011
real 0m 21.20s
user 0m 0.00s
sys 0m 0.08s

2011-07-22 23:18:02 UTC(NIST)
Fri Jul 22 23:18:02 UTC 2011
real 0m 0.30s
user 0m 0.04s
sys 0m 0.14s

2011-07-22 23:18:16 UTC(NIST)
Fri Jul 22 23:18:16 UTC 2011
real 0m 3.34s
user 0m 0.02s
sys 0m 0.20s

2011-07-22 23:18:35 UTC(NIST)
Fri Jul 22 23:18:35 UTC 2011
real 0m 9.41s
user 0m 0.05s
sys 0m 0.22s

2011-07-22 23:18:46 UTC(NIST)
Fri Jul 22 23:18:46 UTC 2011
real 0m 0.22s
user 0m 0.01s
sys 0m 0.10s

The first request timed out after 21.20 seconds without retrieving the information needed to set the local clock; calling getTime.sh to set the clock would have failed. (I have seen four consecutive 10-second requests to that server fail.)

The four other requests to time.nist.gov returned useful information after 0.30, 3.24, 9.41, and 0.22 seconds. 

The server wwv.nist.gov does not seem to be overloaded.  I have never seen it fail to return information, although I have seen a few requests take as long as 3 seconds. 
Title: Re: tinycore_v3.8rc2
Post by: maro on July 22, 2011, 06:20:45 PM
vitex: I appreciate that your observations reflect your particular situation, but please be aware that this does not need to be the case for all other users.

Repeating your test from here I never had a timeout from 'time.nist.gov' (or 'wwv.nist.gov') and the response time from either one of them tends to be in the 1-3 seconds range.

I'm not objecting to any choice that Robert picks up in the end to fix 'getTime.sh', I just think the measurements of a single user that might be poorly served by one particular ISP (and/or the routing used by this ISP) might skew the picture ever so slightly.

BTW, I'm sorry that a minor request I added here has lead this thread to get a bit OT.
Title: Re: tinycore_v3.8rc2
Post by: meo on July 25, 2011, 04:23:10 AM
Hi Team TC!  ;)

Very nice work with the new TC 2.8rc2. I really like the new icons. Usually I have been booting with the "noicons" option. Now in this release I don't use it. So thanks for a good job!!!

Have fun continuing the development TC,
meo
Title: Re: tinycore_v3.8rc2
Post by: bmarkus on July 27, 2011, 12:17:14 AM
I see cases when OnBoot extension seems to be loaded. It is in /usr/local/tce.installed and loop mounted, its contents is in /tmp/tcloop/... However, it is not symlinked to its destination in /usr/local so doesn't available.

Title: Re: tinycore_v3.8rc2
Post by: roberts on July 27, 2011, 06:54:30 AM
Would need more specific information that could be reproduced. If not a local extension permission problem then possibly a low(er) memory system resulting in running out of inodes.
Title: Re: tinycore_v3.8rc2
Post by: bmarkus on July 27, 2011, 04:51:45 PM
/tce directory is stored on HDD's /sda1 partition ext4 formatted. System is booting from USB stick. There is 2GB RAM, an Intel Core2 dual core CPU. No tricks, it's an ordinary rc2, no extension loaded to RAM. From one boot to another same happenes, it is not random. First loaded extensions work as expected, failing ones are at the end of onboot list. There are not too many extensions, thes setup is used to compile simple extensions. If you need I can provide the onboot list. It happened with intltool.tcz first but it's not significant I'm sure. Changing onboot to ondemand it works fine.
Title: Re: tinycore_v3.8rc2
Post by: gerald_clark on July 27, 2011, 05:27:29 PM
Sounds to me like a depfile error.
Programs may run or not run depending on the order they are loaded.


I would identify the first that fails, remove it and all that follow from onboot.lst.
Then reboot and tce-load -i each in turn and look for errors.
Title: Re: tinycore_v3.8rc2
Post by: roberts on July 27, 2011, 08:30:30 PM
A depfile error should be found by using appsaudit. Order should not be a factor as dependencies are loaded prior to any parent extension.

There was a known issue with coreutils "overlaying" via path some busybox commands that are used to load the system. That issue was addressed in rc2

* Updated tce-setup & tce-load to ensure busybox calls thus avoiding conflicts with gnu utilities.

Sharing your onboot.lst would be helpful.
Title: Re: tinycore_v3.8rc2
Post by: gerald_clark on July 27, 2011, 08:34:18 PM
AppsAudit will only find a missing dependency listed in a dep file, not one that is missing from a  dep file.

I have found several dep files that were in error this way.
Title: Re: tinycore_v3.8rc2
Post by: roberts on July 27, 2011, 08:40:37 PM
True, but that should be caught by the extension maker. The very basis of initial testing and would indicate a rouge extension and not a bug in the base.
Title: Re: tinycore_v3.8rc2
Post by: bmarkus on July 28, 2011, 03:37:55 AM
A depfile error should be found by using appsaudit. Order should not be a factor as dependencies are loaded prior to any parent extension.

There was a known issue with coreutils "overlaying" via path some busybox commands that are used to load the system. That issue was addressed in rc2

* Updated tce-setup & tce-load to ensure busybox calls thus avoiding conflicts with gnu utilities.

Sharing your onboot.lst would be helpful.


The problem is coreutils. Extensions loaded after coreutils are not symlinked. Removing coreutils from onboot list everything is OK.

It is rc2
Title: Re: tinycore_v3.8rc2
Post by: roberts on July 28, 2011, 07:54:42 AM
Thanks for reporting. Will look into it further.
Title: Re: tinycore_v3.8rc2
Post by: roberts on July 28, 2011, 10:35:08 PM
Found, Fixed, and Verified.
Title: Re: tinycore_v3.8rc2
Post by: quanpin on July 29, 2011, 07:30:16 AM
v3.8rc1 and rc2 not support the max .tcz loop > /dev/loop87 ,  like gnome-desktop-base.tcz, it will echo" mount: could not find any free loop device.  "
but it can  run  in tc3.6 and 3.7.1 
Title: Re: tinycore_v3.8rc2
Post by: curaga on July 29, 2011, 08:29:20 AM
@quanpin

Hm, util-linux breakage as well? Would your loop86 be util-linux-ng by any chance?
Title: Re: tinycore_v3.8rc2
Post by: quanpin on July 29, 2011, 08:33:54 AM
it will run as like base, and up to mount /dev/loop87 ,can't mount  loop any more.
Title: Re: tinycore_v3.8rc2
Post by: curaga on July 29, 2011, 10:52:42 AM
Yes, but what is your loop86 (/87)?
Title: Re: tinycore_v3.8rc2
Post by: quanpin on July 29, 2011, 04:55:03 PM
/dev/loop82 on /tmp/tcloop/krb5 type squashfs (ro,relatime)
/dev/loop83 on /tmp/tcloop/cracklib type squashfs (ro,relatime)
/dev/loop84 on /tmp/tcloop/Linux-PAM type squashfs (ro,relatime)
/dev/loop85 on /tmp/tcloop/polkit type squashfs (ro,relatime)
/dev/loop86 on /tmp/tcloop/polkit-gnome type squashfs (ro,relatime)
/dev/loop87 on /tmp/tcloop/util-linux-ng type squashfs (ro,relatime)


/dev/loop82               1.1M      1.1M         0 100% /tmp/tcloop/krb5
/dev/loop83             160.0K    160.0K         0 100% /tmp/tcloop/cracklib
/dev/loop84             288.0K    288.0K         0 100% /tmp/tcloop/Linux-PAM
/dev/loop85             128.0K    128.0K         0 100% /tmp/tcloop/polkit
/dev/loop86              28.0K     28.0K         0 100% /tmp/tcloop/polkit-gnome
/dev/loop87             532.0K    532.0K         0 100% /tmp/tcloop/util-linux-ng

Title: Re: tinycore_v3.8rc2
Post by: roberts on July 29, 2011, 05:05:44 PM
Similar to bmarkus coreutils issue. It should be resolved with next rc, 3.8rc3.  I wlll post it soon.