Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: jazzbiker on December 16, 2023, 09:34:57 PM
-
Greetings!
After tce-update of TC14 x86 many extensions were broken. At least wifi, mc, fonts and another ones. TC14 x86 becomes unusable. Many extensions ask for libatomic.so.1. I may have missed whether this is related to openssh update or pcre novations.
What can someone recommend to do in order to make TC14 x86 work?
Thanks in advance!
-
Hi jazzbiker
Does installing gcc_libs.tcz fix it?
-
Hi jazzbiker
The new openssl.tcz now has a dependency on gcc_libs.tcz.
The tree in TC13 looked like this:
mc.tcz
glib2.tcz
libffi.tcz
libssh2.tcz
openssl-1.1.1.tcz
slang.tcz
pcre.tcz
bzip2-lib.tcz
gpm.tcz
ncursesw.tcz
In TC14 it now looks like this:
mc.tcz
glib2.tcz
libffi.tcz
pcre21042.tcz
libssh2.tcz
openssl.tcz
gcc_libs.tcz
slang.tcz
pcre.tcz
bzip2-lib.tcz
gpm.tcz
ncursesw.tcz
pcre.tcz
bzip2-lib.tczlibssh2.tcz gained a dependency on openssl.tcz , which should have
pulled in gcc_libs.tcz.
These extensions have been recompiled against the new openssl"
https://forum.tinycorelinux.net/index.php/topic,26588.msg171487.html#msg171487
-
Hi RIch!
Using TC13 x86 I've added gcc_libs.tcz to my TC14 onboot.lst.
Booted TC14 x86, was able to connect to wifi network, executed update-everything. It showed that some dep files were updated. Then I've removed gcc_libs from onboot.lst and rebooted.
Still no libatomic, so no wifi, strange mc, another strangenesses, shut it down.
Guys, never use tce-update!
PS: looks like I'm the only user of TC14 x86 (
-
gcc_libs provides libatomic, did you check the openssl dep file?
-
tc@box:~$ ls /mnt/sdb3/tce14/optional/openssl.tcz.dep
ls: /mnt/sdb3/tce14/optional/openssl.tcz.dep: No such file or directory
-
Hi jazzbiker
Bingo, there's your problem.
This should fix it:
echo "gcc_libs.tcz" > /mnt/sdb3/tce14/optional/openssl.tcz.dep
-
Bingo, there's your problem.
Really? I thought it is problem of update-everything ...
@GNUser, we need You! Otherwise please rename update-everything into update-almost-everything :-)
-
I've never had success updating tinycore using the update command, do I feel like I've had bad luck? If this is common with everyone, the script definitely needs to be reworked.
I currently keep an entire copy of the repository in /optional and use this rsync command to update, very fast and with zero worries.
-
Hi jazzbiker
... Really? I thought it is problem of update-everything ...
@GNUser, we need You! Otherwise please rename update-everything into update-almost-everything :-)
Are you using an unsanctioned script for updates? :o
Try it like this:
tce-audit builddb
tce-audit updatedeps
tce-audit fetchmissing
tce-update
exitcheck.sh reboot
-
Hi jazzbiker
Does this find an md5 file:
ls /mnt/sdb3/tce14/optional/openssl.tcz.md5.txt
If not, then this would explain the missing .dep file:
Hi GNUser
If an extension does not have a .md5.txt file included, do you still update the .dep file?
Hi Rich. No. update-everything does not touch foo.tcz.dep if local foo.tcz.md5.txt is missing:
elif [ ! -f $OPTIONALDIR/$extension.md5.txt ]; then
continue # if user deleted local md5.txt, it's likely a custom extension--leave it alone
-
tc@box:~$ ls /mnt/sdb3/tce14/optional/openssl.tcz.md5.txt
/mnt/sdb3/tce14/optional/openssl.tcz.md5.txt
-
Try it like this:
tce-audit builddb
tce-audit updatedeps
tce-audit fetchmissing
tce-update
Yes! This magic is able to resurrect even the .dep files gone!
-
Hi jazzbiker. Sorry for the hassle. You found a bug in how update-everything deals with .dep files.
Currently, update-everyhing makes sure that the .dep files on the system are identical to those in the repository. It does not currently check for missing .dep files or for extraneous .dep files (i.e., .dep files that exist on the local system but no longer exist in the repository). I will add this missing functionality.
-
Hi jazzbiker. I added the missing functionality:
* if .dep file is missing, it is added
* if .dep file is extraneous, it is removed
I tested it and it is working as intended:
https://gnuser.ddns.net/public/update-everything
I'll submit a pull request on github.
P.S. update-everything only looks at extensions with a .md5.txt extension. This is intentional so that:
* custom extensions (those without md5 file) are left in peace
* repo extensions with custom (changed/added/removed) .dep files can be left in peace if user deletes the extension's .md5.txt file
-
Are you using an unsanctioned script for updates? :o
Hi Rich. update-everything is part of base system and the current improved version can do everything that the four separate "sanctioned" commands can do.
The big advantage of update-everything is that it updates all of the user's .dep files with a single download from the TCL repo (dep.db.gz), rather than potentially hundreds of downloads (redownloading each and every individual .dep file in tce/optional/).
P.S. Other than the special logic to use dep.db.gz, update-everything is 100% powered by tce-audit and tce-update.
-
Hi GNUser!
Nice that update-everything is finally improved, i.e. works correctly ;-) I think that use of tce-update separately from tce-audit magic must be deprecated in some way, as it can cause problems.
Thanks, I've loaded the improved version.
-
Hi jazzbiker! Thanks for grabbing the improved version. If you can think of any way to make it better, please let me know. I want it to be as fast and efficient as possible. You provided valuable tips when this script was originally created :)
P.S.
While on the topic of system updates, one situation that comes up rarely is that Juanito will deprecate an extension (i.e., completely remove it from the repository). This recently happened with icu67-bin.tcz, for example. If that extension is present on user's system, tce-update shows an error saying that the extension cannot be updated. This error also shows up when using update-everything, of course.
I think this situation is rare enough that it is not worth complicating tce-update and/or update-everything to ask the user what to do. In other words, I think it's fine for the tce-update step of update-everything to show an error when an extension has been deprecated, and let the user figure out the best course of action (which is usually to remove the deprecated extension from their system and run update-everything again).
-
By the way individual .dep files are not necessary and even may produce conflicts since dep.db.gz is present in the repo.
-
I agree. I'm a huge fan of all the benefits made possible by dep.db.gz, obviously ;D
-
Hi GNUser
Are you using an unsanctioned script for updates? :o
Hi Rich. update-everything is part of base system ...
I didn't know it had been incorporated into the base.
... can do everything that the four separate "sanctioned" commands can do. ...
The term unsanctioned was the result of my twisted sense of humor. ;D
-
I didn't know it had been incorporated into the base.
...
The term unsanctioned was the result of my twisted sense of humor. ;D
Haha, no worries. My wife often doesn't understand my own sense of humor, so I know how you feel!
The script is simply a variation on the four commands that you recommended to me a few years ago (thank you), tweaked to take advantage of dep.db.gz.
I hope you find the script to be useful and convenient. Please let me know if you can think of a way to make it better.
-
The new updated update-everything script has a little danger in it.
1) If there is a problem downloading or unpacking dep.db.gz, then it will remove all of your depfiles from your system.
2) It will also remove dep files from any custom extensions a user might have. FOr example and extension downloaded from a 3rd party location, as long as it has an md5.txt file.
Suggestions:
1) the function get_depdb needs some sort of error trap to make sure the downloaded deb.db is somewhat sensible before continuing.
2) the list if extensions to be updated should be checked to make sure they exist on the current mirror.
- Get a list of md5 files from the optional dir. Check that list against md5.db
- use the checked list to find dep file changes
Edit: Updated with suggestions
-
Hi Paul_123. The two dangers are real, thank you for pointing them out.
I like your suggestion for how to mitigate danger #2. I will implement a check so that .dep file is only considered superfluous and deleted if all these conditions are true:
* the extension has an md5 file on user's system
* there is no dep file for the extension in dep.db
* extension has been verified to exist in the repository (because there is an entry for it in md5.db)
What do you think would be a sensible mitigation for danger #1? How about checking that the download of dep.db.gz completed successfully and the downloaded file is a valid .gz archive with nonzero size?
-
I would think as long as gunzip has an exit code of zero, it’s probably fine. A quick check to make sure it contains a few common entries that should always exist.
For example check for zstd.tcz.dep. That would also check to make sure something didn’t happen during server file generation creating a short read.
-
Hi GNUser
This is how I once handled a similar situation:
# If we have a working URL, fetch the list containing each extensions md5.
[ "$URLreachable" == "Yes" ] && wget -q -O $Dest.md5.db.gz $RepoURL/md5.db.gz > /dev/null 2>&1
# Assume the file was received and intact. Attempt to unzip it and then test for errors.
gunzip $Dest.md5.db.gz > /dev/null 2>&1
if [ "$?" == 0 ]
then # Do a case sensitive sort on md5.db. The current sort is case insensitive.
sort -k2 $Dest.md5.db > $Dest.md5.sorted
mv $Dest.md5.sorted $Dest.md5.db
else # Set a flag if gunzip failed.
md5RepoSkipped="1"
fi
-
Thank you both.
https://github.com/tinycorelinux/Core-scripts/pull/64