I have achieved TinyCore Nirvana!

[PDP-8]

Stoked!  I've never been able to get this far!  Things are falling into place mentally..

Environment: TinyCorePure64 16.1 on uefi-only machine.  Ventoy 1.105 used to boot.  Separate ext2 data drive for initial tce-setdrive.

I was chasing many ghosts keeping me in the xfbdev environment, despite the good info here.  I could enter a nice Xorg environment, but upon reboot with added applications, I was constantly met by black screens, and the classic large X.  What I found!

1) On my Intel-based machine, the use of
firmware-i915.tcz
was MANDATORY for my little boxes in onboot.lst.  I could get a full Xorg system running, but without i915, the ghost problems appear.

This was followed in onboot.lst with
graphics-<kernel>
Xorg-7.7-3d

2) Even with 8gb on board, learned quickly not to be greedy by making *everything* on-boot!
Kept my onboot nice and tidy with a minimal environment.  That is, wifi firmware, followed by the Intel firmware, followed by Xorg.  Very small things like htop, and terminus-tcz fonts too.  That's it!

3) ON-Demand for the rest!!  This meant for wifi for example, the firmware is ok as "onboot", but the actual wifi.tcz was placed in the "on-demand" arena.  Followup favorite applications are ALSO "on-demand", not onboot!  Keep that tidy!  The firefox get-latest worked fantastic, but it too is placed in on-demand for first time fireup.

THIS!  Works for me.  YMMV.  Even with all that ram, the system seems happiest with a tidy onboot.  I was totally chasing weird crashes, blackouts, and the big bad X.

Improvements:
Now that the system is full accelerated Xorg, the standard gui utilies, are yeah, teeny.  Easiest fix:  Crank it up in .Xdefaults!

Code: [Select]

Xft.dpi: 160
Screensaver:  Just created a tiny script to let dpms turn it off after an hour without anything getting in the way:

xset s 5000 5000 (simply made it larger than the dpms value, like who cares now)
xset dpms 3600 3600 3600

I guess I'm overjoyed.  Things really fell into place tonight!

[Rich]

Hi PDP-8

... 2) Even with 8gb on board, learned quickly not to be greedy by making *everything* on-boot! ...

Considering extension contents get symlinked to the file system, RAM
should not be a problem. Especially with 8gb.

This is from a TC14 x86_64 laptop (8gb) with persistent /opt and /home:

Code: [Select]

tc@box:~$ du -cs /usr/local/bin/
1.6M    /usr/local/bin/
1.6M    total
tc@box:~$ du -cs /usr/local/lib/
9.3M    /usr/local/lib/
9.3M    total
tc@box:~$ du -cs /usr/local/share/
4.5M    /usr/local/share/
4.5M    totalLoaded extensions include firefox, gnumeric, gparted, gpicview,
grabber, mc, wifi, xfe, xjournal, evince, shotwell, librecad, inkscape,
libreoffice, ....

This is the current RAM status:

Code: [Select]

tc@box:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7729        3430        3764         256         535        3809
Swap:          1907           0        1907The vast bulk of the RAM used is from Firefox running with about 20 tabs open.
It's probably been running as long as the machine has been up, 89 days

Of course, if you have a  copy2fs.flg  or  copy2fs.lst  file in your tce directory, then
your RAM use will be higher.

[PDP-8]

Hi Rich!  Thanks.  I can duplicate this problem when I placed it on an Intel Nuc (bios forced into uefi-only mode) instead of the headed-for-the-recycler machine.

I wonder if it is particular to my setup - that is by booting the iso, I have both a CDE and a TCE directory (on the dedicated data-drive).  I have tried changing the grub boot entry from cde to tce=sda1, and same result.  That is, an app like wifi.tcz (or some others) only seem to work (not crash xorg) after being activated from on-demand, not on-boot.

Otherwise, the machine(s) rock with tinycorepure64.

AND, of course I'm not ruling out a possible issue with Ventoy (latest) being used as the initial bootloader.  Gotta' be honest, I look at *everything*.

I'm going to add apps back to the onboot.lst, and see which ones give me trouble.   Is it cde/tce combo from iso-booting confusing symlinks or leftover detritus?  Is it Ventoy?  Hmmm...

Thanks for the input - this will be fun tracking down - at least the machine(s) are in a totally usable state, but yeah, this isn't normal as you've shown.

[Rich]

Hi PDP-8
1. cde is meant for "read only" media only.
2. tce is meant for writable media only.
3. If installing an ISOs contents to writable media, rename cde to tce.

I don't know the effect of having both cde and tce, but I'm certain
Tinycore was never designed to support that. If you have both, go
to 1 - 3 above and use the appropriate directory type.

[PDP-8]

Hi Rich - I do have the tce directory as writable.  That was achieved after performing tce-setdrive.

I'm seeing this pattern to the issue:

System performs normally using apps like this in onboot.lst

Code: [Select]

firmware
Xorg stuff
commandline utilites
Xfe
Htop
emelfm
feh
imagemagic
fonts etc.
However, larger graphical programs like these require use with on-demand.  Just once of course, I don't mind the initial little wait.

Code: [Select]

wifi.tcz
netsurf
galculator
firefox
sakura
engrampa
...
The graphical issue is that when these are place into onboot, what I see is:

All extensions load.  Tinycore background with screwbolt appears briefly, but no wbar.  Screen goes black.

I fix it easily enough by dropping into a vt, and fixing my /dev/sda1/tce/onboot.lst with vi to remove the problem program, and reboot.

I'm on the case!