Tiny Core Linux
Tiny Core Base => TCB News => Alpha Releases => Topic started by: roberts on September 05, 2011, 09:02:07 AM
-
Tiny Core 4.0 Alpha3 is available for public testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/4.x/x86/alpha/
Change log:
alpha1:
* Updated kernel to 3.0.3
* Updated udev to 173
* Updated glibc to eglibc-2.13
* Updated e2fsprogs base libs to 1.41.14
* Updated gcc base libs to 4.6.1
* Updated util-linux base libs to 2.19.1
* Updated all the custom core utilities to use the new repository area:
http://distro.ibiblio.org/tinycorelinux/4.x/x86/tcz/
alpha2:
* New loadcpufreq to handle module loading.
* Updated eglibc for 486/586 support.
* Updated busybox 1.19 with latest patches and fix for chpasswd segfault.
* Updated ondemand for console based extensions via Freedesktop Exec=cliorx prgname
* Adjusted .xsession to handle X startup failure.
* Adjusted .setbackground colors for wallpaper handling.
alpha3:
* Replaced ldd and ldconf with original versions not dependent on bash.
* Restored ssb module to base.
* Updated AppBrowser Search and Keyword as described below.
* Updated ab Search and Keyword.
* Updated search.sh internal script support for new search method shared by AppBrowser & ab
* New keyword.sh internal script support for new keyword method shared by AppBrowser & ab
Notes:
The Search method for both AppBrowser and ab is now a local info.lst seach.
To use enter the starting few characters of the desired extension, e.g., abi for abiword, or oper for opera
Both AppBrowser and ab now offer Keyword searching.
Examples: enter browser to display browsers, enter game to list games.
Attn: microcore users will need new Xprogs.tcz from 4.x repository.
-
Notes:
Both AppBrowser and ab now offer Keyword searching.
Examples: enter browser to display browsers, enter game to list games.
finally! but these keywords are stored where?
-
On our servers. words.db is generated from the extension's Description: field.
-
Ok, I think a package maker should be able to watch all the keywords listed in words.db to get an idea of the keyword when he use for a package.
A clickable list of words appbrowers may be valid?
-
words,db is not a set of predefined words rather the actual words from the extension's Description field. While it is true that garbage in results in garbage out. It should not be difficult for extension makers to use the new keyword search infrastructure that I have provided. Let's not make a mountain.
-
It was only the prospect of a similar situation:
text_editor
editor_text
doc_edit
code_editor
...
all for the same tipology of software
-
Its mainly when I'm fooling around with alphas and betas and testing out a new release or when I'm trying to debug an installation that has gone astray (most of which are the case right now), that I wish for this. If we already laid this question to rest, please remind me, but since we're heading into 4.x I though I'd bring it up.
I've got lines in my menu.lst including the following boot codes:
For tc 3.8.3:
... tce=LABEL=pnyfob0 ...
For tc 3.8.4:
... tce=sdb1/tce3.8.4
For tc 4.0A3:
... tce=sdb1/tce40A3 ...
I can't use the LABEL clause for tc 3.8.4 or tc 4.0A3 because I want to specify a directory other than just plain "tce". However "pnyfob0", a USB flash drive, gets different device IDs on different hosts so I'm forever having to adjust the "sdb1" part to reflect the actual device.
Any chance we could revisit the tce boot code so something like the following would work?
... tce=LABEL=pnyfob0:/tce4.0A3 ...
-
Lee, I'm pretty sure that I've tested this a while ago (albeit with UUID instead of LABEL) and IIRC it was working just fine.
One thing I noticed is that you where using 'tce=sdb1/tce40A3' for the working boot code and 'tce=LABEL=pnyfob0:/tce4.0A3' (which includes a colon and a dot which I would have not expected to see) for your "target" one.
Is that a simple typo in your posting or actually copied from the config file (which would make the latter then probably wrong)?
-
It was a typo. I was just putting that out as "for instance" because I didn't remember the issue having been resolved. It has been a long time since I tried anything like this. I'll try
tce=LABEL=pnyfob0/tce40A3
(no dot and no colon) next time I reboot.
Edit 2011-09-07 05:35:
Wow! Do I ever feel sheepish! I can't believe I either knew about that and forgot it, or I missed it entirely, but there it is - works exactly as I had hoped.
Thank you, maro, for pointing it out to me and Thank -you-, roberts, for implementing it. Have I mentioned lately, "Thank you to the whole Tiny Core team and the community for making TC what it is"? TC just keeps getting better and better. :)
-
There was a small mixup with the 64-bit modules. Look forward to the next release.
-
Any idea how to avoid the 10-15% size increase of 4.0 built extensions compared to 3.x build? In most cases no need for GCC 4.61. Adding GCC from 3.x to 4.0 repo would help. BTW, 4.0 repo contains GCC 3.3.6 also.
-
Why not ask the gcc folks on what changed with -Os from 4.4 to 4.6? If there's a reproducible test case, some small package etc, they should listen.
-
Why not ask the gcc folks on what changed with -Os from 4.4 to 4.6? If there's a reproducible test case, some small package etc, they should listen.
For sure there are test cases (all extensions maintained by me :) ) Will make a try
-
Here is link noticing a change in the behavior of gcc 4.6, perhaps building gcc with "--enable-frame-pointer" can restore the smaller size binaries generated by the previous gcc. May be worth a try, if I am reading that page right. (EDIT:I don't see -fomit-frame-pointer along with -Os causing a larger binary size with the TC 3.x I have available to test with remotely, so may not be the cause.)
http://www.mail-archive.com/coreboot@coreboot.org/msg30467.html (http://www.mail-archive.com/coreboot@coreboot.org/msg30467.html)
-
Here is link noticing a change in the behavior of gcc 4.6, perhaps building gcc with "--enable-frame-pointer" can restore the smaller size binaries generated by the previous gcc. May be worth a try, if I am reading that page right. (EDIT:I don't see -fomit-frame-pointer along with -Os causing a larger binary size with the TC 3.x I have available to test with remotely, so may not be the cause.)
http://www.mail-archive.com/coreboot@coreboot.org/msg30467.html (http://www.mail-archive.com/coreboot@coreboot.org/msg30467.html)
I ran some quick builds of ccache to look at the different optimizations. The build tests failed without the -fno-omit-frame-pointer switch. The builds finished and produced the binary but the binary failed at runtime with the testsuites. I would recommend adding the --enable-frame-pointer into gcc to prevent any runtime problems.
Here is a table of optimizations ran:| optimization | binary size |
| -Os | 74.9k |
| -O1 | 75.6k |
| -O2 | 72.2k |
| -O3 | 89.0k |
| -Ofast | 85.9k |
I find it interesting that the -O2 gives the smallest binary size, though it is over 33% larger then in 3.x.
Also, compiletc depends on linux-3.0.1_api-headers, is this correct? I thought the kernel was 3.0.3.
-
Hi,
I have a USB CompactFlash card reader. When I use it with a 64MB CompactFlash card on TC3 and DSL, I get a message like this:
usb 2-2: new full speed USB device using uhci_hcd and address 2
scsi1 : usb-storage 2-2:1.0
scsi 1:0:0:0: Direct-Access Generic STORAGE DEVICE 0.01 PQ: 0 ANSI: 0
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 1:0:0:0: [sdb] 125185 512-byte logical blocks: (64.0 MB/61.1 MiB)
sd 1:0:0:0: [sdb] Test WP failed, assume Write Enabled
sd 1:0:0:0: [sdb] Assuming drive cache: write through
sd 1:0:0:0: [sdb] Test WP failed, assume Write Enabled
sd 1:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
sd 1:0:0:0: [sdb] Test WP failed, assume Write Enabled
sd 1:0:0:0: [sdb] Assuming drive cache: write through
sd 1:0:0:0: [sdb] Attached SCSI removable disk
My memory card looks like this:
tc@box[~]$ fdisk -l /dev/sdb
Disk /dev/sdb: 64 MB, 64094720 bytes
2 heads, 62 sectors/track, 1009 cylinders
Units = cylinders of 124 * 512 = 63488 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 1009 62527 83 Linux
TC3:
Linux box 2.6.33.3-tinycore #2012 SMP Wed May 12 17:05:42 EEST 2010 i686 GNU/Linux
DSL:
Linux box 2.4.31 #1 SMP Sat Jul 12 16:12:42 EDT 2008 i686 GNU/Linux
But, when I connect the same device to Alpha3, I get a message like this:
usb 2-2: new full speed USB device number 2 using uhci_hcd
scsi3 : usb-storage 2-2:1.0
scsi 3:0:0:0: Direct-Access Generic STORAGE DEVICE 0.01 PQ: 0 ANSI: 0
sd 3:0:0:0: Attached scsi generic sg2 type 0
sd 3:0:0:0: [sdc] 125185 512-byte logical blocks: (64.0 MB/61.1 MiB)
sd 3:0:0:0: [sdc] Test WP failed, assume Write Enabled
sd 3:0:0:0: [sdc] Cache data unavailable
sd 3:0:0:0: [sdc] Assuming drive cache: write through
sd 3:0:0:0: [sdc] Test WP failed, assume Write Enabled
sd 3:0:0:0: [sdc] Cache data unavailable
sd 3:0:0:0: [sdc] Assuming drive cache: write through
sdc: sdc1
sd 3:0:0:0: [sdc] Test WP failed, assume Write Enabled
sd 3:0:0:0: [sdc] Cache data unavailable
sd 3:0:0:0: [sdc] Assuming drive cache: write through
sd 3:0:0:0: [sdc] Attached SCSI removable disk
sd 3:0:0:0: [sdc] Unhandled sense code
sd 3:0:0:0: [sdc] Result: hostbyte=0x10 driverbyte=0x08
sd 3:0:0:0: [sdc] Sense Key : 0x3 [current]
sd 3:0:0:0: [sdc] ASC=0x14 ASCQ=0x0
sd 3:0:0:0: [sdc] CDB: cdb[0]=0x28: 28 00 00 01 e9 00 00 00 01 00
end_request: critical target error, dev sdc, sector 125184
Buffer I/O error on device sdc, logical block 125184
Is this a kernel problem? By the way, my memory card is fine.
Thank you.
-
Also, compiletc depends on linux-3.0.1_api-headers, is this correct? I thought the kernel was 3.0.3.
The toolchain was built with the linux-3.0.1 api headers - I don't believe (I may be wrong) that changing to the 3.0.3 kernel requires re-building the toolchain.
-
Also, compiletc depends on linux-3.0.1_api-headers, is this correct? I thought the kernel was 3.0.3.
The toolchain was built with the linux-3.0.1 api headers - I don't believe (I may be wrong) that changing to the 3.0.3 kernel requires re-building the toolchain.
only thing that is really influenced by kernel headers is (e)glibc feature set during build time.
also minor releases are just security updates, as 3.0.x series is.
also, i cannot install sdl. the sdl.tcz file starts downloading but i eventually get 404 error. where should i report this ?
-
Hi hjkl
Try the following boot code:
usb-storage.quirks=VID:PID:cw
Where VID is the vendor ID and PID is the product ID for the storage device.
You can get the VID:PID by running lsusb which is found in usb-utils.tcz
If that does not fix it you can try:
usb-storage.quirks=VID:PID:bcw
-
Hi Rich,
Thank you for the information. The boot code you suggested fixed the problem.
Now, my extlinux.conf looks like this:
label tc
kernel /tc4/vmlinuz
append vga=791 usb-storage.quirks=05e3:0700:cw initrd=/tc4/tinycore.gz
The error message I got changed from:
sd 3:0:0:0: [sdc] 125185 512-byte logical blocks: (64.0 MB/61.1 MiB)
.
.
end_request: critical target error, dev sdc, sector 125184
Buffer I/O error on device sdc, logical block 125184
to:
sd 3:0:0:0: [sdc] Adjusting the sector count from its reported value: 125185
sd 3:0:0:0: [sdc] 125184 512-byte logical blocks: (64.0 MB/61.1 MiB)
Thank you.
-
hjkl, please open a bug against the kernel's usb system with these details. It's a regression from the previous kernel.
-
I ran some quick builds of ccache to look at the different optimizations. The build tests failed without the -fno-omit-frame-pointer switch. The builds finished and produced the binary but the binary failed at runtime with the testsuites. I would recommend adding the --enable-frame-pointer into gcc to prevent any runtime problems.
Looking at http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html#Optimize-Options: (http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html#Optimize-Options:)
-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging
Starting with GCC version 4.6, the default setting (when not optimizing for size) for 32-bit Linux x86 and 32-bit Darwin x86 targets has been changed to -fomit-frame-pointer. The default can be reverted to -fno-omit-frame-pointer by configuring GCC with the --enable-frame-pointer configure option.
Given: -fomit-frame-pointer
Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.
..it is somehow hard to see why including "instructions to save, set up and restore frame pointers" makes the size of compiled binaries smaller.
I'll look at this some more in the next couple of days.
-
hjkl, please open a bug against the kernel's usb system with these details. It's a regression from the previous kernel.
Hi curaga,
I got your suggestion. But, I'm afraid I don't know where to go from here in order to report "a bug against the kernel's usb system." I realize that I have to learn a lot more. :(
-
Hi curaga,
I got your suggestion. But, I'm afraid I don't know where to go from here in order to report "a bug against the kernel's usb system." I realize that I have to learn a lot more. :(
It would be bugzilla.kernel.org, but kernel.org is down right now after the server was rooted.