Tiny Core Linux
Tiny Core Extensions => TCE Tips & Tricks => Topic started by: nick65go on March 11, 2026, 03:55:54 PM
-
Using QEMU emulator version 10.2.1, I tested the requested RAM to run the latest TC17 32 bits (kernel 6.12). Before thinking to improve TC, I need to measure its PRACTICAL demands, which for me now seems to be minimum 256 MB RAM without a HDD/USB storage touching.
qemu-system-i386 -accel tcg -cpu 486-v1 -machine pc -m 128M -cdrom TinyCore-17.0.isototal memory 128M= 128*1024= 131,072 = TOTAL(117,704) +swap=17,816 (13%); remains free=79,932
minim RAM to boot in command prompter (no GUI)=71MB; at 70MB RAM will not boot.
total memory 71M= 71*1024= 72,704 KB => TOTAL(59,132) +swap=2,472 (13%); remains free=23,496 KB
what you can do with less than 24 MB free is now up to you.
qemu-system-i386 -accel kvm -machine pc -m 90M -cdrom TinyCore-17.0.iso
GUI at 89MB RAM will not boot. With GUI, minim RAM=90MB, total useful=78,428, swap=7,788, free to use=13,804 KB (so near useless). Of course, you could have a swap on HDD (not in RAM, by remastering), delete after boot the not-needed drivers (network mostly) so maybe get some 4MB more to use. Or else use a not-supported "scattered" install TC on HDD.
This proves that using TC17 (kernel 6.12 or 6.18) for a very old PC with less than 90MB RAM is good as a prove of concept, but near useless daily. So you need at least 128MB RAM and humble acknowledge your pay-grade (application total space less than 79 MB) with such a constrained 486 device.
Demo: I just add fluff.tcz and freemem is now 8MB (from initial 128 MB RAM).
Summary:
1. for users of limited /less than 128 MB RAM, try do NOT update TC over version 17. You gain nothing.
2. for RAM=256MB, I boot fresh and add fluff.tcz (minim FLTK GUI file manager), then dillo.tcz (minim internet GUI browser for forum help) and then abiword.tcz (or +gnumeric.tcz add +2MB) for some "productive" work. Now the freemem=17MB (to save some documents in RAM). So now add alsa.tcz for sound (+2.3MB). I can NOT add mplayer-cli.tcz (it asks for extra 66 MB), neither vlc.tcz (asks for 99MB just to install it). So I could settle to just listing music only (not movies) by using mpd-minimal.tcz (asks for 9MB) or cmus.tcz (I did not find in TC17 the xmms.tcz).
This is a variant/experience of what you may expect from limited 256MB RAM. Same as you would expect from (now dead/frozen) DSL - Damn Small Linux. Oh boy, sic transit gloria mundi.
FYI: intentionally I did not use some HDD space, to be fully nomadic + no trace on HDD.
My original purpose was to test if latest TC17 truly runs on just 486 CPU instructions (so I used qemu -accel tcg -cpu 486), and to demystify that TC17 can run on less than 71 MB (CLI) or 90 MB (GUI). Q:E.D
-
Hi nick65go
... Of course, you could have a swap on HDD (not in RAM, by remastering), ...
You don't need to remaster anything. Take a thumb drive and place a swap
partition on it. If a swap partition is present when booting, Tinycore will find it.
/init reserves 25% of RAM for zswap. When RAM is tight, a swap partition and
nozswap boot code will help.
... (I did not find in TC17 the xmms.tcz). ...
sox.tcz is available.
-
Hi @Rich, thanks for your replay.
Today I can not buy (in the country where I live) any device with less than [2..4] GB RAM: and I have 32 GB RAM in latest laptop ;) . Basically I have no problem with any linux distro. For me is just intellectual challenge to " improve" the specifications, like what could be the minimum RAM required to run TC17 32 bit version.
So for me, in TC environment, I would like to push the hardware request to the minimum, without changing many things that can be upgraded with next TC version.
I consider hardware RAM more important than swap HDD, because someone can buy a new CDROM-disk or USB-pen more easy than upgrade the RAM memory (which is specific to machine socket, size, etc). Plus the RAM usually comes in lots of 64MB, 128 MB, 256 MB and further combinations. Starting from RAM 256 MB is no focus for me to "improve" a TinyCore-17.0.iso of 25MB.
But I think that TC17 could boot/run usable in less than 64MB, a possible nice achievement to advertise to TC web-site. The goal will be to improve the core CLI, because when considering GUI is game over for less than 64MB.
One idea is about /init, specifically theinodes=`grep MemFree /proc/meminfo | awk '{printf("%d\n", $2/3)}'`
mount / -o remount,size=90%,nr_inodes=$inodesThe 10% default choose for RAM swap from 64MB could be bypassed with a IF/case for MeeFree < 64MB, so TC17 can be used as CLI rescue CD/USB. The only thing 90% RAM is used is because cmd line parameter "noembed" for tar + switch_root, which is not justified for less than 64MB RAM.
A 2-nd idea is about to do not automatically load in RAM what you not need just to boot and rescue. Like no network-card driver into modules.gz, but load later from another net-drv.gz if necessary. So split modules.gz in 2-3 parts.
A 3-rd idea can be to split /bin/busybox in the pieces, you already did it using busybox.id (is suid). Some busybox applets maybe are not necessary at boot/rescue (fonts, dumpkey, etc).
A 4-th idea, things like /bin{e2fsk, mke2fs} + /usr/lib{lib*, gconv} can be in another gz/tcz loaded on demand (or RAM> 64MB).
Summary: TC will have ALL original programs (some loaded on demand), with few structural changes. Feed-back is welcome, why is too much effort or not good/practical ideas for extreme limited RAM. Or maybe not too many TC users still use 486 CPU + 64MB RAM.
-
Hi nick65go
... One idea is about /init, specifically theinodes=`grep MemFree /proc/meminfo | awk '{printf("%d\n", $2/3)}'`
mount / -o remount,size=90%,nr_inodes=$inodesThe 10% default choose for RAM swap from 64MB ...
Sorry, my mistake. zswap is set up in tc-config and is 25% of free RAM:
tc@HP-G62:~/Downloads$ grep zram /etc/init.d/tc-config
while [ ! -e /dev/zram0 ]; do usleep 50000; done
grep MemFree /proc/meminfo | awk '{printf("%dK\n", $2/4)}' > /sys/block/zram0/disksize
mkswap /dev/zram0 >/dev/null 2>&1
swapon /dev/zram0
echo "/dev/zram0 swap swap defaults,noauto 0 0" >> /etc/fstab # Lets swapoff -a work
-
Calculation for minim RAM need to load (core.gz + vmlinuz) in memory, using 7zip.exe from windows11.
Isolinux needs to load + keep the lump-sum of the following pieces (in Bytes!):
A = core.gz = 13,952,288
A1 = core.cpio = 20,470,784 (un-gzip of core.gz)
B = vmlinuz = 6,087,168 [sectionions: b1 +b2 +b3]
b1 = name.1 = 16,532
b3 = name.3 = 47,225
b2 = 2.gz = 6,023,411 (is gzip of .text section =c)
c = 2.gz-ungipped = 13,092,640 (= 1.elf + name.2)
So total = (A +A1) + (B + b1 +b3 + b2 + c) =
= (13,952,288 + 20,470,784) + (16,532 + 47,225 + 6,023,411) + 13,092,640
= 53,602,880 bytes (aprox. 53 MB)
so even without delayed/ondemand load of network drivers (= 5,935,341 bytes)
(TinyCore-17.0.iso\boot\core.gz\core.cpio\lib\modules\6.18.2-tinycore\kernel\drivers\net\)
we could boot CLI with 53MB RAM, practically with physical 64MB RAM.
FYI: you do remember that linux booted from floppy and have a lot of rescue tools. Do not you challenge yourself in these day to squeeze more from this modern TC?
Would @curaga or @juanito consider inserting a new line in /init script to test condition MemFree<64MB for 100% instead of 90% remount rw?
Or even better, a case tests for some RAM ranges, because (for example) at 16GB-32GB someone may not need zram of 10% in TC. latest kernel are better at OOM (out of memory) stress to do not freeze the system.
-
News: first the two bad, then the good one.
1. advdef.tcz is weeker in TC17 64 vs. TC17 32 bits !? Can anyone else check and confirm this about advdef.tcz?
ex: I unpacked and then quickly packed back (without any change) the rootfs.gz;the final result is (test.gz vs. rootfs.gz) as 3,701,085 vs. 3,697,459. #extract roofs.gz
cd tmp && zcat ../rootfs.gz | sudo cpio -i -H newc -d#re-package and compress new test.gz
cd tmp
sudo find | sudo cpio -o -H newc | sudo gzip -2 > ../test.gz
cd ../ && advdef -z4 test.gz
2. I need 46 MB to boot. 45 MB will not boot even if a change (in /init) the size to 95%, or 99% or 100%, or even eliminate the if loop + just "exec /sbin/init". I tried with all combinations -accel kwm/tcg or -cpu 486/host, etc
Something is fishy here... with tmp size or inodes?> cat test.gz modules.gz > coreNEW.gz
> qemu-system-i386 -accel kvm -cpu host -machine pc -m 45M -kernel ./vmlinuz -initrd ./coreNEW.gz
> qemu-system-i386 -accel tcg -cpu 486-v1 -machine pc -m 46M -kernel ./vmlinuz -initrd ./coreNEW.gz
3. Now the good news: CROM will not boot with less than 71MB, but if someone manage to "install" the core.gz + vmlinuz on HDD, then it boots with just 45 MB RAM. > cat rootfs.gz modules.gz > coreOLD.gz
> qemu-system-i386 -accel kvm -cpu host -machine pc -m 45M -kernel ./vmlinuz -initrd ./coreOLD.gz
PS: another strange thing here with 45MB RAM: total memory 45M= 45*1024= 46,080, but command free shows
Mem (32,728) +swap=1,376 (4.2%) =34,154 (not 45MB!, missing 11,926 bytes); remains free=14,112 KB
-
I do not know if exist any physical machine with 41 MB RAM (but I assume there is not). Anyway, for the pleasure to promote how good a "modern" TC17 32 bits (kernel 6.18.2, wow) could be, booting and running in less than 41 MB RAM, here below are my reproducible results.
I lowered the demands WITHOUT eliminating ANY original program, but just load some of them with delay (on-demand), from the same storage as vmlinuz+core.gz, like you also load any tce/tcz. I extracted the original rootfs.gz in ./01, move out few files (listed below), re-create the new-rootfs.gz, Et voilà.
sudo find | sudo cpio -o -H newc > ../x1.cpio
cd ../ && gzip -1 ./x1.cpio
./advdef -z4 ./x1.cpio.gz
cat x1.cpio.gz modules.gz > coreNEW.gz
qemu-system-i386 -accel kvm -m 41M -machine pc -kernel vmlinuz -initrd coreNEW.gz -append nozswap
# here are files size
ls -aB ./*.gz
.rw-r--r-- 3.697.459 abc 8 Mär 15:22 ./rootfs.gz
.rw-r--r-- 2.203.231 abc 14 Mär 16:52 ./x1.cpio.gz# files not in x1.cpio.gz (4.3MB), allow booting with 41MB (instead of 45MB)
du -h 01
540K 01/sbin
100K 01/usr/sbin
100K 01/usr/lib/gconv
3,2M 01/usr/lib
3,3M 01/usr
444K 01/lib
4,3M 01
sudo find ./01 -type f -printf '%s %p\n' | sort -nr
2988956 ./01/usr/lib/libstdc++.so.6.0.34
414192 ./01/lib/libext2fs.so.2.4
310688 ./01/sbin/e2fsck
226880 ./01/usr/lib/libgcc_s.so.1
129536 ./01/sbin/mke2fs
104800 ./01/sbin/tune2fs
80904 ./01/usr/sbin/visudo
31456 ./01/lib/libe2p.so.2.3
25988 ./01/usr/lib/gconv/ANSI_X3.110.so
13748 ./01/usr/sbin/mklost+found
13708 ./01/usr/lib/gconv/UNICODE.so
13700 ./01/usr/lib/gconv/ISO8859-2.so
13700 ./01/usr/lib/gconv/ISO8859-1.so
13700 ./01/usr/lib/gconv/ISO8859-15.so
3916 ./01/usr/lib/gconv/gconv-modules
132 ./01/usr/lib/libgcc_s.so
After boot in cmd line, I had near. 12.3 MB free memory and I could load the "missing" pieces of 4.3 MB :)
Continue on the same principle (on-demand loading) I "investigate" further the module,gz, for potential 4-5 MB more from kernel/drivers/net.
But I wonder who will be happy to boot with 36 MB RAM and why?
-
I think I can summaries and close this topic with conclusion: The 37 MB RAM is the minimum to boot in qemu. (aka not from CDROM but from a USB/HDD /tmpfs).
qemu-system-i386 -accel kvm -m 37M -machine pc -kernel vmlinuz -initrd x1.cpio.gz -append nozswapAfter booting with 37 MB RAM, using just x1.cpio.gz (without loading module,gz), memory available was 10.9 MB (=11224/1024), but a "ls -aR /" will kill me out to prompter "box login:" (=Out of memory Killed process ...sh). The aggressive kernel OOM killed the shell because no HDD swap.
It was fun. You could test it yourself and then maybe advertise the TC minim technical specifications.
-
I have great news about TC: minimal demands to CLI (text prompter) boot is 27 MB RAM, without swap (neither in RAM, nor on HDD) and not need to compile anything, all program form original core.gz are functional, etc. Here are the details:
1. As I exposed in my previous post, the initial rootfs.gz should be slimmed down; specifically to move few files in another container (tcz /tce / compressed or not, whatever you want). It can be loaded few seconds later (or on demand) from the same storage (CDROM/USB/HDD) where vmlinuz + core.gz already exist (so yes, that storage even read-only).
2. Two files should be modified - /init , where a boot parameter (ex: LowRam) can be queried, same as you check for "noembed", and if found then just change the line mount / -o remount,size=90%,nr_inodes=$inodesreplacing 90% with 100%. I am not sure if this is realty need, but it worked for my test.
- /etc/init.d/tc-config, line 104 add --children-max=1, AFTER you adding test for boot parameter (ex: LowRam) just before the line. "/sbin/udevd --daemon --children-max=1 2>&1 >/dev/nullI made a new x02.cpio.gz and I tested (with and without a swap partition). Attached are snapshots from qemu running this TC17.You can see this from "free" command that initial ram=27MB !
FYI: one trick was that adding temporary a HDD swap,qemu-img create ./swap100MB.raw 100M
qemu-system-i386 -accel tcg -m 31M -machine pc -kernel vmlinuz -initrd x2.cpio.gz -append "nozswap" -hdd ./swaph100MB.raw &I saw the small swap used = [988-1,824] KB, and "top" shows 3 process (each of 2,220 KB) of "/sbin/udev --daemon" still running.
-
And here are the latest results: TC17 32 bits boots in 26 MB RAM, if you allow swap on HDD.
Snapshots images from qemu are attached!
To boot in 26MB RAM the change in /init (90% => 100%) is mandatory, but optionally for 27MB RAMif ! grep -qw lowram /proc/cmdline; then
mount / -o remount,size=90%,nr_inodes=$inodes
else
mount / -o remount,size=100%
fi And in /etc/init.d/tc-config I moved "modprobe loop 2>/dev/null" just before "[ -n "$LANGUAGE" ] || LANGUAGE="C" to allow a little more memory for "hungry" udev.
PS: I have read the TC forum, when in year 2011 people struggled to boot with 32 MB RAM, having even the old TC3.x (smaller size kernel) + not-recommended "scattered" method.