AMD K6-2 166Mhz, 512MB ram, desktop - TC11.1 runs fine TC12 fails.

[CNK]

16mb is very likely not enough either, the faq says an old microcore required 28mb, so probably at least 32mb for current versions.

Yes I found another old 486 laptop with 20MB RAM and a working floppy - the bootloader finishes and Linux starts booting, but then it dies with a suggestion to use the "root=" parameter in the kernel line and lists a bunch of ram(x) options to use for it (trying a few always results in an "out of memory" type error).

I don't really understand where all the data is coming from - maybe for decompressing rootfs.gz? But I tried booting an uncompressed rootfs file and it caused another boot error, though there must be a way to do that. Or maybe a TC feature (compressed swap space in RAM?) that I need to disable? I won't have time to do any research for a while.

On my Pentium 1 which has 80MB RAM + 100MB swap partition, core.gz runs fine but booting a TC 10.1 Core Plus CD it gets stuck loading extensions, which probably is from running out of RAM. A bigger swap partition might help at that stage though, so RAM isn't entirely a hard limit on these old PCs if you can get the base system loaded up.

[Rich]

Hi CNK

... Or maybe a TC feature (compressed swap space in RAM?) that I need to disable? ...

That would be the  nozswap  boot code.

[Juanito]

normally i just download and use TCxx.x(TinyCore...and assuming all TC/TinyCore are gui)
however, as per your request to test a Core(microcore/mc) i did try out the cli..

OK, so:

32mb < Core < 64mb
96mb < Tinycore < 128mb

..if I understand correctly

[gadget42]

normally i just download and use TCxx.x(TinyCore...and assuming all TC/TinyCore are gui)
however, as per your request to test a Core(microcore/mc) i did try out the cli..

OK, so:

32mb < Core < 64mb
96mb < Tinycore < 128mb

..if I understand correctly

yes, you are correct. from what i observed i do believe that if someone "fiddled" with either/both of them(TinyCore/Core) they both might successfully boot with the lesser amount of ram(but they would soon run out of ram and/or become unusable/unreliable).

also i am assuming you saw my bonus data post on the TC1.3rc3:

32mb < TinyCore-TC1.3rc3 < 64mb
(and again, i am assuming that fiddling around with boot codes and such might result in a successful cli/terminal session with the lesser amount of ram...but with no real reliability/usefulness)

[gadget42]

Hi nick65go

... what is the purpose for a 486 CPU compatibility for a TC12 (5.10.3 kernel) if it will be (mostly) not practical on phisical old machines? ...

There is still hardware being made that contains Vortex processors. Some of those processors claim to be 686 compatible
but really are not.  Google  vortex86 mini pc  or  vortex86 pc104  for current hardware.

Some people re-purpose thin clients. These can have processors by VIA, SiS, National Semiconductor, etc. that may
either be 486 based or have quirks that make them not fully 686 compatible. A great site about many thin clients is:
https://www.parkytowers.me.uk/thin/hware/hardware.shtml

Tinycore (and this forum) have users from all around the world. For various reasons (availability, financial, etc.) some
users may not have access to more current hardware. As a distro, Tinycore does its best to be inclusive and not push
any users out.

the TL;DR version might read:
TinyCoreLinux-current-version aspires to successfully boot any-where/any-time/any-machine/within-reason
(using cd/dvd/usb/hdd/ssd/etc - as always your mileage may vary - not responsible for roadkill/magic-smoke)

+1 for the parkytowers website reference!

[nick65go]

my test on windows_10, with qemu_5.1, to see what minimum RAM TC ask for.
take it with a pinch of salt (can be bugs in qemu implementation for win10), but at least we know some rough limits.
To boot virgin TCxx.iso, I used commands similar with:
"\qemu51\qemu-system-i386.exe -cpu max -m 30 -L vgabios-stdvga.bin -cdrom TinyCore-4.7.7.iso -hda sda-empty.qcow2"

Code: [Select]

tc_ver kernel   RAM-min GUI
4.7.7   3.0.21  30 MB  cli
4.7.7   3.0.21  36 MB  gui
--
6.4.1   3.16.6    36 MB   cli
6.4.1   3.16.6    128 MB   gui now working (bug)
7.2     4.2.9       64 MB    gui now working (bug)
--
12.0    5.10.3    56 MB  cli
12.0    5.10.3    64 MB  guiPS: just because tc12 booted, does not mean that you can run many (or simultanously) programs in the tiny free RAM available after boot.

[jazzbiker]

Hi nick65go,

I don't know what does qemu means about TinyCore 6.4.1, but I have one Pentium MMX with 64M of RAM which runs TC 6.4.1 with GUI and without any problems. Of course it has 256M of swap and is much more comfortable with CLI, but it is almost always on and has runtime in the range of months. It is I guess 25 years old - serious guy! We are good friends besides Pentium is equipped with F00F bug (!) and BIOS is buggy (I was not able to test new TC12 486 version by Jaunito, sorry).

[nick65go]

Maybe qemu has some bugs (both running from linux or windows). I checked again, this time from TC12_64 with qemu_6.0, using commands like:
"qemu-system-i386 -accel kvm -cpu 486 -m 30M -cdrom TC-4.7.7-K_3.0.21.iso"
This assume a PC has no HDD (so no swap allowed), just pure CDROM (with virgin TCxx.iso) and RAM.
Without a physical PC to test, qemu is the next best instrument, when no user reports are provided from real hardware tests.

tc_ver_Kernel     GUI/CLI  RAM-minim_MB
TC-1.4-K_2.6.26.iso  CLI   32MB+ qemu_6.0 bug

TC-4.7.7-K_3.0.21.iso CLI  30MB
TC-4.7.7-K_3.0.21.iso GUI  36MB

TC-5.4-K_3.8.13.iso   CLI 128MB+  qemu_6.0 bug
TC-6.4.1-K_3.16.6.iso CLI 128MB+  qemu_6.0 bug

TC-7.2-K_4.2.9.iso    CLI  40MB
TC-7.2-K_4.2.9.iso    GUI 128MB qemu_6.0 bug

TC-8.2.1-K_4.8.17.iso CLI   42MB
TC-8.2.1-K_4.8.17.iso GUI   50MB

TC-9.0-K_4.14.10.iso  CLI   46MB
TC-9.0-K_4.14.10.iso  GUI   50MB

TC-10.1-K_4.19.10.iso  CLI  48MB
TC-10.1-K_4.19.10.iso  GUI  52MB

TC-11.1-K_5.4.3.iso   CLI   52MB 
TC-11.1-K_5.4.3.iso   GUI   54MB

TinyCore-12.0-K_5.10.3.iso CLI  56MB
TinyCore-12.0-K_5.10.3.iso GUI  60MB (issued on 07 July 2021)

Summary: qemu shows that
- With 16 MB RAM core can not be run.
-Core (CLI) needs MINIMUM 32 MB RAM, and a basic Tinycore (GUI) could be run in 64 MB RAM. I suspect qemu has a problem with its CD driver simulation.

[jazzbiker]

I rechecked my Pentium without swap at all. Note, that this is not .iso boot but standard install with extlinux, XVesa and flwm. One more note - laptop is offline and is booted with "nodhcp".
These figures are not exact values, it is offline, if it is important I can carry screenshots through flash drive.
Pentium MMX, RAM 64M, HDD 4.3G, TC 6.4.1

base noswap nozswap nodhcp norestore - 58M total 16M used
vga=788 base noswap nozswap nodhcp norestore  -  58M total 16M used
vga=788 noswap nozswap nodhcp - 58M total 55M used (immediately after boot)
after 'sudo cache-clear': 30M used. XVesa + flwm + aterm

[nick65go]

Hi jazzbiker,
If you work offline with max 64MB RAM, then maybe you can shave 4.4MB from memory by deleting /lib/modules/5.10.3-tinycore/kernel/drivers/net. After booting with a script on-demand (flexible), or better before booting (shrink or build a different modules.gz for boot-loader).

For restrictive RAM but large HDD size, the best could be: many small statically linked utilities, (like a busybox split in pieces) and each piece statically linked with uClib, sym-linked from HDD/CD, so not to pre-load it in RAM until you need that appl. Hm, but then is not TC anymore, is nano-core.

[jazzbiker]

Hi nick65go,

Thanks for the advice, I think You are quite right about RAM saving method. I don't use this laptop for something important, it is really slow HDD has I guess IDE interface and has reading speed around half a megabyte per second Sometimes I use it for small temporary tasks, like testing some snippet in C or in Lua. I enjoy the fact that TinyCore can run even on such ancient hardware, just to remind myself that TinyCore is one of the World Wonders of our days

I have the question about busybox. I was trying to examine memory consumption by busybox utilities, and noticed that once loaded (probably init) then all other busybox utilities reuse the same code, which is already resides in RAM. Am I right?

[nick65go]

Hi jazzbiker,
My oldest /slowest PC (Dell mini 10, has 8+ years old?) has already 1GB RAM. So my "studies" for minimum RAM for a small/rescue linux (not necesary tinycore) were focused on virtual machines (VM). The pristine (virginity) boot state of pseudo-HDD is not a concern for VM, so goal was to use less RAM for guest, from main host RAM.

TC is wonderfull for 64+ MB RAM. For 32Mb up to 64MB RAM the number of applications are VERY limited in scope (for me). Maybe something like DSL (damn small linux) is more suitable. For basic/primitive things (partitioning, formating, text edit, audio, even basic network) I am still looking at Kolibri linux, with 8 MB RAM demand or wonders like http://www.toms.net/rb/ for less than 4 MB RAM.

About busybox: as long as just someone call a busybox applet (like grep, from /init script?), then all busybox code loads in RAM (and stays in RAM as long as there is still free RAM) and give speed to other busybox-applets (like you later call the mount applet), without more RAM consumption.
My aproach thinking was a little slow speed but less RAM consumption. Load "mount" or "grep" when/if I need them (not so often).
You see, one size does not fit all cases. But for very low RAM, exceptional methods are summoned.

[Rich]

Hi jazzbiker

... I have the question about busybox. I was trying to examine memory consumption by busybox utilities, and noticed that once loaded (probably init) then all other busybox utilities reuse the same code, which is already resides in RAM. Am I right?

All of the busybox commands are just links back to  /bin/busybox.  Run the command  ls -l /bin  to see that.
Busybox checks to see what name was used to run it to decide which command to execute, something like this:

Code: [Select]

#include <stdio.h>

/******************************************************************/
int main(int argc, char *argv[])
{
printf("My name is %s\n", argv[0]);

return(0);
}

Code: [Select]

tc@E310:~/xyzzy$ gcc testlink.c -o testlink
tc@E310:~/xyzzy$ ln -s testlink mylink
tc@E310:~/xyzzy$ ls -l
total 20
lrwxrwxrwx 1 tc staff     8 Jul  9 06:55 mylink -> testlink
-rwxr-xr-x 1 tc staff 15140 Jul  9 06:55 testlink
-rw-r--r-- 1 tc staff   180 Jul  9 06:54 testlink.c
tc@E310:~/xyzzy$ ./testlink
My name is ./testlink
tc@E310:~/xyzzy$ ./mylink
My name is ./mylink
tc@E310:~/xyzzy$
Whether you rename the  testlink  binary or call it through a link, it will always know what name (and path) was
used to run it.

[gadget42]

...
TC is wonderfull for 64+ MB RAM. For 32Mb up to 64MB RAM the number of applications are VERY limited in scope (for me). Maybe something like DSL (damn small linux) is more suitable. For basic/primitive things (partitioning, formating, text edit, audio, even basic network) I am still looking at Kolibri linux, with 8 MB RAM demand ;) or wonders like http://www.toms.net/rb/ for less than 4 MB RAM.
...

after visiting http://www.toms.net i fell down a rabbithole and somehow ended up at https://wiki.osdev.org/User:Johnburger/Demo/Overview which was interesting enough to share.
(although i will refrain from the linkstorm that would be required to climb back out of that hole...lol)

[jazzbiker]

Core/TinyCore/CorePlus isos reposted

Hi, Juanito!

New rootfs version boots successfully on my old Mobile Pentium MMX, family 5, model 8, 64M RAM.
Previous version issued message about BIOS bug (something wrong with ACPI) and then hang with panic, I was wrong to expect that this bug was the reason.
The new version reports the same BIOS bug and boots successfully! You are wizard!