(Tiny)Core x86 : is there a reason not to enable PAE ?

[SeventhSin]

Hello,

TinyCore-10.1.iso
Boot Core (command line only) + nozswap option

OK: VM with 1024 MB RAM => tce-load -wil htop => MEM = 36.1/1006M
OK: VM with 2048 MB RAM => tce-load -wil htop => MEM = 41.3/1.97G

NOT OK: VM with 3072 MB RAM => tce-load -wil htop => MEM = 40.8/2.97G
NOT OK: VM with 4096 MB RAM => tce-load -wil htop => MEM = 41.6/2.97G

So we're capped a 2.97G, hmm... A little bit of research shows PAE is missing from http://tinycorelinux.net/10.x/x86/release/src/kernel/config-4.19.10-tinycore. There is no

Code: [Select]

CONFIG_HIGHMEM64G=y
configuration flag set. Quite quaint since PAE is available on all CPUs starting circa 1995-1999 (there were a couple of exceptions, long time defunct now).

So, is there any reason not to enable PAE on x86 (Tiny)Core ?

[Rich]

Hi SeventhSin

... So, is there any reason not to enable PAE on x86 (Tiny)Core ?

This was the first reason I found, there may be other threads with more info:
http://forum.tinycorelinux.net/index.php/topic,20282.msg126269.html#msg126269

If your processor is 64 bit, you can run a 64 bit kernel and 32 bit apps:
http://forum.tinycorelinux.net/index.php/topic,22306.msg139639.html#msg139639
http://forum.tinycorelinux.net/index.php/topic,20089.msg124921.html#msg124921

[SeventhSin]

Hi Rich,

If your processor is 64 bit, you can run a 64 bit kernel and 32 bit apps:
http://forum.tinycorelinux.net/index.php/topic,22306.msg139639.html#msg139639
http://forum.tinycorelinux.net/index.php/topic,20089.msg124921.html#msg124921

There is no official ISO for (Tiny)Core64 on https://distro.ibiblio.org/tinycorelinux/downloads.html & subsections. I found it mentioned in some old threads I had been reading, but the absence of an official ISO makes me wonder if it is something that has been merely overlooked for 10x or it is not supposed to exists at all.

[Juanito]

There has never been an iso for Core64, but it works

[SeventhSin]

There has never been an iso for Core64, but it works

That it works, I have no doubt. 

That being said, which is the best forum section to put forth a suggestion/request for such an addition to the website download section? 

[Juanito]

..or, install Core, then make the minor changes required to run Core64.

[SeventhSin]

..or, install Core, then make the minor changes required to run Core64.

That could definitely work for me. However, one could argue pro another or:

... or upload a (Tiny)Core64 ISO to the website so that everyone can build software on x86 without seeing non-sense such as this:

Code: [Select]

ld: final link failed: No space left on device
... when there is more than 1.2 GB of RAM available at the time the error manifests and the build directory is on /mnt/sda1 which has roughly 6 GB of free space. 

[Juanito]

I’d guess there’s something amiss since I can build libreoffice on Core with 4gb ram (with the source on permanent storage).

[SeventhSin]

I’d guess there’s something amiss since I can build libreoffice on Core with 4gb ram.

My guess as well. I've seen "No space left on device" errors on Pure64 as well, however in that case the system was indeed out of RAM. All I had to do was to add a bit more RAM to the build VM and the error would go away, depends on what I build and how many dependencies I have to pull.

On x86 however, (bot installed and ephemeral RAM only boot), "No space left on device" does not make sense when looking at the resources available to the machine. What makes it worse is that the issue is semi-reproducible. Sometimes it happens, other times it doesn't.

Unfortunately, just adding more RAM isn't a solution due to no PAE in the kernel. As a matter of fact, that's what prompted me to open this thread in the first place. I was hoping to get away without a) having to build a custom Core x86 + 64 bit kernel ISO or b) having to investigate the issue further.   

As a note, I noticed this issue mentioned on a couple of older threads (2009-2011 if I remember correctly). In the threads that I saw, the original poster(s) were asked for all kinds of command output from their system (relating to RAM & DISK), however everything seemed fine. No solution was available as far as I remember.

I also noticed another error. I don't have the precise text handy right now, but it was related to mounting dependency extensions: cannot mount loopXXX blah-blah and then some mention to not enough space left. There was of course enough RAM & DISK available.

[andyj]

What are the use cases for needing more than 4 GB on a 32-bit system in 2019? The only one I know of is compiling mariadb, and I have to use a VM to even have that kind of environment. A non-PAE capable processor is going to be quite old, and the rest system it comes with will be limited as well. This is one of the use cases for TC. Requiring PAE would create at least a few orphans.

[SeventhSin]

What are the use cases for needing more than 4 GB on a 32-bit system in 2019?

Well, one possible use case would be to easily work-around issues such as the ones mentioned above. Allocate more RAM to the VM, build possibly won't be failing anymore.

Another possible use case would be using ephemeral systems for builds, eg. RAM only build machines, that can be easily reverted to a pristine state with a mere reboot and reconfigured on the fly by build agents. This is my current approach, not theoretical in the slightest.

And yet another possible use case is when one wants to go rampant with make -j xxx. Depending on what one builds, increasing parallelism increases RAM usage significantly but it also decreases build time. Instead of waiting 40 minutes one could only wait 10 minutes for a build to complete. This matters when time is of significance.

[SeventhSin]

A non-PAE capable processor is going to be quite old, and the rest system it comes with will be limited as well. This is one of the use cases for TC. Requiring PAE would create at least a few orphans.

Some Wikipedia stuff:

PAE was first implemented in the Intel Pentium Pro in 1995,[3] although the accompanying chipsets usually lacked support for the required extra address bits.[4]
PAE is supported by the Pentium Pro, Pentium II, Pentium III, and Pentium 4 processors. The first Pentium M family processors ("Banias") introduced in 2003 also support PAE; however, they do not show the PAE support flag in their CPUID information.[5] It was also available on AMD processors including the AMD Athlon[6][7] (although the chipsets for are limited to 32-bit addressing[8]) and later AMD processor models.

TinyCore's recommended configuration:

Recommended configuration: A Pentium 2 CPU and 64 MB of RAM are recommended for Tiny Core.[5]

Enabling PAE on x86 would take supported CPUs back to Pentium Pro (1995 CPU line) and would kill this:

The minimum CPU is an i486DX.[5]

.

I wonder if anyone would shed 1 (one) tear. I literally want to see 1 person still using a pre-Pentium Pro CPU nowadays. Now THAT would be something to behold!

PS: not that I'm positioning myself as an advocate for PAE on Core x86. It just seemed something useful to have enabled by default. However having to recompile the kernel + all the politics behind such a decision (because you know... reasons.. Linus Torvalds hates PAE & such) makes me think a Core64 ISO available to the world would be the best possible answer.  One can dream.

[Rich]

Hi SeventhSin
I wanted to boot Tinycore from a thumb drive on an HP Proliant ML150 G6 in 32 bit mode and still take advantage of the 6 Gig of
installed RAM. I started by installing Tinycore to the thumb drive. Next I fetched modules64.gz, rootfs.gz, and vmlinuz64:
http://tinycorelinux.net/10.x/x86/release/distribution_files/
and saved them where the 32 bit kernel and initrd are stored. Then create  core64.gz  like this:

Code: [Select]

cat rootfs.gz modules64.gz > core64.gz
I have grub on my thumb drive. My  menu.lst  looks like this:

Code: [Select]

default 1
timeout 10

title TC9_32bit
root (hd0,0)
kernel /tce/boot/vmlinuz quiet  waitusb=5:UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" tce=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" home=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" opt=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" printk.time=1 syslog enable_mtrr_cleanup
initrd /tce/boot/core.gz

title TC9_Core64
root (hd0,0)
kernel /tce/boot/vmlinuz64 quiet  waitusb=5:UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" tce=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" home=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" opt=UUID="1ad696eb-3913-4434-bb9e-25dd4b980c09" printk.time=1 syslog enable_mtrr_cleanup
initrd /tce/boot/core64.gzBoth  core  and  core64  share the same /home, /opt, and tce/optional directories as well as the same  onboot.lst  file:

Code: [Select]

firmware.tcz
aterm.tcz
fltk-1.3.tcz
flwm_topside.tcz
freetype.tcz
imlib2-bin.tcz
imlib2.tcz
libfontenc.tcz
libICE.tcz
libjpeg-turbo.tcz
libpng.tcz
libSM.tcz
libX11.tcz
libXau.tcz
libxcb.tcz
libXdmcp.tcz
libXext.tcz
libXfont.tcz
libXi.tcz
libXmu.tcz
libXpm.tcz
libXrandr.tcz
libXrender.tcz
libXt.tcz
libdrm.tcz
wbar.tcz
Xlibs.tcz
Xprogs.tcz
mc.tcz
pci-utils.tcz
curl.tcz
gzip.tcz
graphics-KERNEL.tcz
Xorg-7.7.tcz
alsa-config.tcz
alsa.tcz
alsamixergui.tcz
grabber.tcz
geany.tcz
wireshark.tcz
firefox-ESR.tcz
libavcodec.tcz
gnumeric.tcz
nfs-utils.tcz
pulseaudio.tcz
numlockx.tcz
gtk1.tcz
adwaita-icon-theme.tcz
util-linux.tcz
gparted.tcz
ntfsprogs.tcz
e2fsprogs.tcz
dosfstools.tcz
mtools.tcz
hfsprogs.tcz
tc-install-GUI.tcz
bind.tcz
usbutils.tcz
scsi-KERNEL.tcz
lsscsi.tcz
mdadm.tczYou'll note the 2 entries containing the word  KERNEL.  tce-load  will load the version (32 or 64 bit) that matches your running kernel.
My  tce/optional  directory contains both versions:

Code: [Select]

filesystems-4.14.10-tinycore.tcz
filesystems-4.14.10-tinycore64.tcz
graphics-4.14.10-tinycore.tcz
graphics-4.14.10-tinycore64.tcz
i2c-4.14.10-tinycore.tcz
i2c-4.14.10-tinycore64.tcz
mtd-4.14.10-tinycore.tcz
mtd-4.14.10-tinycore64.tcz
raid-dm-4.14.10-tinycore.tcz
raid-dm-4.14.10-tinycore64.tcz
scsi-4.14.10-tinycore.tcz
scsi-4.14.10-tinycore64.tcz
It's just a 32 bit install running  vmlinuz64  and 64 bit modules. That's all there is to it.

[andyj]

If there is something you want and it doesn't already exist it may be because you're the first to want it. Instead of complaining that someone else should have come before you and paved the way, you could make what you want and contribute so there might be some pavement for the next person.

I'll be nice and ignore for now the much more likely scenario that no one else wanted it for some obscure reason like there was a better way. 

[SeventhSin]

If there is something you want and it doesn't already exist it may be because you're the first to want it.

That is possible, although not certain. Maybe people wanted it but didn't dare to ask for it or didn't ask strongly enough.   

Instead of complaining

Please, no shadow boxing. Nobody's complaining, this thread is a conversation.

that someone else should have come before you and paved the way, you could make what you want and contribute so there might be some pavement for the next person.

What I want (I am restating here for brevity) is to be able to build non-trivial software on x86. Right now that is impossible for me due to "no space left on device" weirdness. Easy way around the aforementioned are:

a) PAE on x86 kernel
b) Core64 ISO

Both a) and b) would allow allocating more memory to ephemeral build machines. I can do both for myself, but that won't be paving the way for anyone else. I could even share a build script for b), but unless that results in an upload (for which I have no permissions) that would be a waste of my time.

I'll be nice

Please don't be.

and ignore for now the much more likely scenario

How much more likely? Abstract talk doesn't lead anywhere.

that no one else wanted it

Is this certain?

for some obscure reason like there was a better way. 

An unknown ("some obscure reason") plus a general abstraction ("there was a better way") add precisely zero actionable information to this conversation.