Core install with 32 MB RAM on 486

[youxiaojie]

yeah！meet a friend to work it on real 486.
1did you get grub work? it's fail to boot in real 486,syslinux is ok.
2 is there way to build minimum kernel make tinyconfig and modify with menuconfig with busybox initramfs?
3 is xserver compile in ititramfs? how to make an scm of xserver?

[branpurn]

yeah！meet a friend to work it on real 486.
1did you get grub work? it's fail to boot in real 486,syslinux is ok.
2 is there way to build minimum kernel make tinyconfig and modify with menuconfig with busybox initramfs?
3 is xserver compile in ititramfs? how to make an scm of xserver?

No such success

Regrettably I barely get to touch this it's mostly a curiosity for now

It would be neat if Core had a kernel downselect menu like Floppinux, which from 1.44 MB floppy requires 20 MB RAM and 486DX for latest kernel (https://github.com/w84death/floppinux)

[youxiaojie]

http://repo.tinycorelinux.net/16.x/x86/release/distribution_files/

can rootfs.xxx file be extract to hdd as rootfs?

[Rich]

Hi youxiaojie
It can, but Tinycore was not designed to run that way.
We do not support that mode of installation.

[CNK]

http://repo.tinycorelinux.net/16.x/x86/release/distribution_files/

can rootfs.xxx file be extract to hdd as rootfs?

That's how I installed it on a 486 with 16MB RAM (also needed a custom kernel build due to the limited RAM).

Instructions for doing that were quoted in the first post in this thread!

[neonix]

What is the purpose of this file?
http://repo.tinycorelinux.net/16.x/x86/release/distribution_files/rootfs.gz

[Rich]

Hi neonix
Just what it says. It's the root file system. It contains:

Code: [Select]

tc@E310:~$ tree -d TinycoreISOs/Rootfs64TC14
TinycoreISOs/Rootfs64TC14
|-- bin
|-- dev
|   |-- fd -> /proc/self/fd
|   |-- input
|   |-- net
|   |-- pts
|   |-- shm
|   `-- usb
|-- etc
|   |-- init.d
|   |   `-- services
|   |-- pcmcia
|   |-- profile.d
|   |-- skel
|   |-- sysconfig
|   `-- udev
|       `-- rules.d
|-- home
|-- lib
|   |-- modules
|   `-- udev
|-- mnt
|-- opt
|-- proc
|-- root
|-- run
|   `-- udev
|-- sbin
|-- sys
|-- tmp
|-- usr
|   |-- bin
|   |-- lib
|   |   `-- gconv
|   |-- local
|   |   |-- bin
|   |   |-- lib
|   |   |   `-- modules
|   |   `-- tce.installed
|   |-- sbin
|   `-- share
|       |-- doc
|       |   |-- License
|       |   `-- tc
|       |-- i18n
|       |   `-- charmaps
|       |-- kmap
|       |-- locale
|       |-- misc
|       |-- syslinux
|       |-- tabset
|       |-- terminfo
|       |   |-- a
|       |   |-- l
|       |   |-- r
|       |   |-- v
|       |   `-- x
|       `-- udhcpc
`-- var
    |-- cache
    |-- lib
    |-- lock
    |-- log
    |-- run
    |-- spool
    |   |-- cron
    |   |   `-- crontabs
    |   `-- lpd
    `-- tmp -> /tmp

69 directories
I only listed the directories. There are also about 600 files in there.

If you wish to see all of the contents yourself:

Code: [Select]

mkdir tempdir
cd tempdir
zcat /path/to/existing/rootfs.gz | sudo cpio -i

[neonix]

Why I can't unpack core.gz? If TinyCore was was not designed to run that way, then why rootfs.gz was placed in repo?

[Leee]

Why I can't unpack core.gz? If TinyCore was was not designed to run that way, then why rootfs.gz was placed in repo?

There's no reason you can't unpack core.gz using the same method as for rootfs.gz.

As I understand it, core.gz is literally just rootfs.gz appended to modules.gz.  This is part of a modular approach to building software.  The existence of core.gz just makes it so that you can put together a system with two files (vmlinuz and core.gz) instead of three (vmlinuz, rootfs.gz and modules.gz).

[Rich]

Hi neonix

... then why rootfs.gz was placed in repo?

Here's a couple of reasons.

If you do this:

Code: [Select]

cat rootfs.gz modules64.gz > core64.gzand then boot vmlinuz64 along with core64.gz.
It allows you to run 32 bit programs under a 64 bit kernel.

This gives you a kernel that can manage a large amount of RAM and
allocate up to 4 Gig of RAM to each 32 bit program you are running.

You can not run 64 bit programs in this type of environment.

If you don't want or need any of the included drivers, you can use
rootfs.gz instead of core.gz for your initrd.

[branpurn]

Picked up a 2 GB CF card and an IDE adapter, so did frugal install of Core to that.

Installing from ISO, I specified the following boot options at the end of tc-install.sh: nozswap udev.children-max=1 mem=nopentium

Code: [Select]

SYSLINUX 6.03 CHS 2014-10-06 Copyright (C) 1994-2014 H. Peter Anvin et al
Booting kernel failed: Invalid argument
boot: nozswap udev.children-max=1
_

I am positive I typed the boot options correctly at end of tc-install.sh, if I remove mem=nopentium it "continues..."

I get a "high low" beep code, and then it sits with a blinking cursor. I'll leave it sit for an undetermined amount of time.

[patrikg]

Do you use a editor thats wrap the line ?
If using nano add -w to set nowrap.

Code: [Select]

sudo nano -w /mnt/sda2/boot/extlinux/extlinux.conf

[CNK]

I am positive I typed the boot options correctly at end of tc-install.sh, if I remove mem=nopentium it "continues..."

My understanding is that mem=nopentium should be default on a 486 anyway. It's described more clearly in older docs:

You can also use the boot argument `mem=nopentium' to  turn  off  4  MB
pagetables  on  kernels  configured  for IA32 systems with a pentium or
newer CPU.

I get a "high low" beep code, and then it sits with a blinking cursor. I'll leave it sit for an undetermined amount of time.

That sounds about typical for if it ran out of RAM while unpacking core.gz into initramfs. However I don't use Syslinux on 486 (I boot from MSDOS with LOADLIN, to a HDD install without core.gz as described earlier), so perhaps there's another problem with it. It reminds me of what LOADLIN does (after a long loading delay) when it runs out of RAM unpacking core.gz though.