Oddity when loading libreoffice onboot (core 16.2, x86_64)

[Leee]

I have a 2017 vintage HP Stream 11 ( Celeron N3060 @ 1.6 GHZ, 4 GB RAM ) with Tiny Core 14.0 installed. I use it primarily to run LibreOffice to access a simple spreadsheet and it works just fine.

I recently installed Core 16.2 in a dual boot config with 14.0 remaining in it's last-used condition - each version having its own installation directory and its own tce direcetory.  I used a copy of the onboot.lst from the old version to download all needed onboot extensions for the new version, with dependencies resolved at download time.  Then I brought forward a copy of mydata.tgz and other relevant files from the old version's tce directory to the new version's tce directory.  Everything works perfectly except...

When I boot up the new version, libreoffice.tcz, which is listed in onboot.lst, does not load.  However, once the system is up, I can tce-load -i libreoffice and it loads without problems and works perfectly.  All md5sums check out, the system is not short on RAM and storage device is 80% free.  Hexdump shows no unusual characters in onboot.lst.

Any idea what might cause perfectly good extension to not load onboot?

[gadget42]

bitflip? somewhere? perhaps? maybe? whoknows?

nevertheless, bit-flips are interesting and thought-provoking(and thusly time-consuming):

https://blog.robertelder.org/causes-of-bit-flips-in-computer-memory/

https://blog.robertelder.org/importance-of-ecc-memory/

@Leee, keep us posted on your investigation!

[Leee]

Well... I still don't know -why- but apparently it just needs to try twice.

I moved libreoffice.tcz to the first line of onboot.lst - no luck.

Moved it to the last line - no luck.

Tried leaving it in its original position but also making it a dependency of another extension - THAT WORKED.

Reverted the modified dep file but simply put libreoffice into onboot.lst twice (on two consecutive lines, using copy and paste - so no typos in either entry) and THAT ALSO WORKED.


The first two tries above - I really didn't expect to work and they didn't... but then I really didn't expect the third and fourth tries to work either but they did.

[patrikg]

You can add showapps to your kernel command line args so when booting it shows what tcz being loaded, and you maybe see whats wrong.

[Rich]

Hi Leee

... When I boot up the new version, libreoffice.tcz, which is listed in onboot.lst, does not load. ...

Add the bootcode:

Code: [Select]

syslog
Then check /var/log/messages (and /var/log/messages.0 if present) for errors
and/or warnings when it's loading extensions.

... Then I brought forward a copy of mydata.tgz ...

Maybe something in your backup is causing problems when restored?

... and other relevant files from the old version's tce directory to the new version's tce directory. ...

That sounds suspicious. What other relevant files?

Although libreoffice has not changed from TC14 to TC16, its dependency tree has.

To see what changed ....
Take the .tree files and create sorted lists of all dependencies:

Code: [Select]

awk '$1=$1' libre14.tree | sort -u > libre14deps
awk '$1=$1' libre16.tree | sort -u > libre16deps
To see what got removed:

Code: [Select]

rich@tcbox:~$ diff -u libre14deps libre16deps | grep -E "^\-"
--- libre14deps 2025-11-13 13:43:18.000000000 +0100
-aspell-en.tcz
-atk.tcz
-at-spi2-atk.tcz
-gnutls35.tcz
-libEGL.tcz
-libICE.tcz
-libSM.tcz
-nettle3.tcz
-openssl-1.1.1.tcz
rich@tcbox:~$
To see what got added:

Code: [Select]

rich@tcbox:~$ diff -u libre14deps libre16deps | grep -E "^\+"
+++ libre16deps 2025-11-13 13:43:28.000000000 +0100
+elfutils.tcz
+gdk-pixbuf2-xlib.tcz
+gnutls38.tcz
+icu74.tcz
+libexif.tcz
+libffi7.tcz
+libgphoto2.tcz
+libpoppler23.tcz
+libvdpau.tcz
+libXtst.tcz
+llvm19-lib.tcz
+mesa.tcz
+nettle39.tcz
+spirv-tools.tcz
+util-linux.tcz
rich@tcbox:~$
You might also want to let your system run an update:

Code: [Select]

tce-audit builddb
tce-audit updatedeps
tce-audit fetchmissing
tce-update
exitcheck.sh reboot
I think the system creates a tce/optional/update directory if you want to see
what might change before running the  exitcheck.sh reboot  command.

Well... I still don't know -why- but apparently it just needs to try twice. ...

Maybe some interaction with one or more  /usr/local/tce.installed/  scripts?

You can add showapps to your kernel command line args ...

That's also a good idea.

[Leee]

Thanks Rich and patrickg.  I'm working through all of these suggestions but I have some IRL things going on so it might take a couple more days.

[Leee]

Thanks to all for your help and suggestions.  This problem is solved - mostly.

The suggestion to use tce-audit surprised me by retrieving several extensions - even though the install was fresh (a couple of days old at most) including downloading all dependencies of the extensions listed in onboot.lst.  I probably should have been more concerned about that than I initially was.

The suggestion to use the showapps bootcode proved to be key.  It showed me that one extension, gst-plugins-bad.tcz (a deep dep of libreoffice.tcz), wasn't loading.  But instead of simply checking that extension's md5sum I checked every .md5.txt file in my local store, en masse.  No checksum errors detected so clearly not a bad extension.   WRONG.  After much spinning of wheels I decided to just download a fresh copy of the (seemingly) offending extension and see if it matched the existing copy and/or the existing .md5sum.txt file.  But not only was the faulty .tcz file incomplete but its .md5.txt file had never been downloaded either.  This meant that A) the md5sum test never took place and B) tce-audit and/or tce-update probably pretty much ignored it.

So I did download a fresh copy of gst-plugins-bad.tcz and its md5.txt and dep files and the listed dependencies and now libreoffice.tcz loads on the first try.

The only remaining issue is, "Why the heck did it previously work when I loaded it twice?"  I think I can envision a path where that might have worked - perhaps if gst-plugins-bad.tcz itself wasn't a hard dependency but one of -its- dependencies -was- ....  I don't have enough brain cells still functioning to follow that through the whole way right now.