Tiny Core Linux
Tiny Core Base => TCB News => Final Releases => Topic started by: Juanito on February 17, 2021, 06:12:34 AM
-
Team Tiny Core is proud to announce the release of Core v12.0
http://www.tinycorelinux.net/12.x/x86/release
http://www.tinycorelinux.net/12.x/x86_64/release
Changelog for 12.0:
Note:
* kernel updated to 5.10.3
* glibc updated to 2.32
* gcc updated to 10.2.0
* binutils updated to 2.35.1
* e2fsprogs base libs/apps updated to 1.45.6
* util-linux base libs/apps updated to 2.36.1
* busybox updated to 1.33.0
* busybox patched to load more than 9 extensions
* busybox patched to remove "Module has invalid ELF header"
* tc-config: no gratuitous permissions changes in /opt from bdantas
* tc-functions: version changes from andyj
* version: changes from andyj
* shutdown.sh: clarifying comment
* busybox-aliases: additions from bdantas
* filetool.sh: comments from bdantas
* tce-setup: remove neeedless timestamp from bdantas
* tce-config: more precise /opt copying from bdantas
* tce-config: rename autoscan from polikuo
* tc-config: similar awk rounding
* init: avoid awk rounding
* filetool.sh: dc syntax change fix from watt
* tce-audit: search fix from lhaley42
* tc-config: get tc version from tc-functions
* release.txt depreciated in favour of os-release
Note:
* extensions are in the process of being copied over from the 11.x repo.
* the libffi and readline extensions have been updated - this will break a lot of extensions, so fallback libffi6 and readline7 extensions have been created.
-
Congratulations to the team! Another solid release.
I'm grateful for Tiny Core Linux for so many reasons. In particular, thank you for:
- Your conservative approach to new releases (update key infrastructure + fix small issues), as it tends to cause zero breakage for users
- Your serious and ongoing committment to minimalism and Unix philosophy
Long live Tiny Core Linux!
-
Thanks to the team for 12.0!
I have noticed some small problems with two iso's, reproducable across 4 different machines. MD5 sums doublechecked, and known good sticks used to install by DD'ing to:
CorePlus installer image:
Apps will initially allow you to check and set the fastest mirror ok.
However, when it comes to browse the mirror to install something quickly say in cloud-mode like nano, it errors out with:
Error: Check network mirror or writable extension directory
A quick doublecheck with the previous 11.1 shows that the mirrors are up and browseable.
[UPDATE]
Used CorePlus and the tc-install gui to replicate itself onto another good stick.
After boot, the first time I tried to use Apps, it said that the mirror.tcz wasn't there, but brought up the apps window anyway. I *was* able to browse the default mirror, but only once. Changing the mirror resulted in no-browsable mirrors, even when set back to default.
Maybe a timing issue - once the apps window was up, I was able to manually restart the fastest-mirror utility and it brought me to my usual in Calgary and allowed me to set it. Unfortunately, it won't browse.
TinyCore:
Across all 4 machines, using either the default first option, or the second with waitusb=5, we are brought to the command line:
failed in waitforX
Using the other options to boot with the command line only work fine. And as another test, I was able to use tce-ab to quickly do a cloud mode download and install of nano as a test. So here, the mirrors seem to work.
I found it interesting that the iso images of 12.0 have different issues.
All sticks for initial installation were DD'ed via knoppix and devuan. MD5 sums checked. Sticks were re-tested by dd'ing the 11.1 release and have no issues.
So, just reporting what I'm seeing and maybe others can duplicate it to prove that I'm crazy or not. :)
Very grateful for 12.0 - not complaining as these can be overcome, but just some "out of box" local tests on the two iso's. (havent tested 64 bit yet)....
-
I confirm the TinyCore does not start X issue. Xvesa --help reports libfontenc.so.1 is missing.
-
The problem was in the Xvesa (and Xfbdev) tree file - TinyCore-12.0.iso and TinyCorePure64-12.0.iso reposted
-
Thanks to the team for the new Tiny Core 12 ! I will install it soon :)
-
Thanks Jaunito! I'll check out the new uploads of Tinycore.. I was scratching my head when my usual fixes like appending vga=791 still didn't work...
CorePlus fix! Sorta, but a workaround:
Something's up with the mirrors as seen in other threads. But some work. Apps utility doesn't like being fooled. :)
1) Just because you let the system "pick the fastest mirror" and make it your default, doesn't always mean it is working as it should. Ie Ibiblio, and possibly others that take it from them. In other words, they may *respond* well enough to satisfy the fastest-mirror util, but leads you to:
2) When choosing an alternate mirror of your own choosing, they too may not be working correctly and spit out that error notification.
3) BUT, when that happens and you go and choose yet another mirror, *MAKE SURE* that the url changes at the bottom of the util. If it does not, then QUIT the apps utility, and start again with a different mirror.
Seems like when the Apps util encounters more than say two failed changes of mirror, it won't accept any more user changes - so make sure the url changes, and if not, quit the app and fire it up again.
Sorry to sound like such a pita, but wanted to jump on the "Out of box" experience before filing any false bugs.
As usual, thanks for all the hard work to the entire dev team and user-contributors!
-
Congrats on the new release. I plan to install it on a VM this weekend and play around with it.
First notice: I downloaded the Corepure64 version and have a mismatch on MD5 on this file:
http://tinycorelinux.net/12.x/x86_64/release/distribution_files/corepure64.gz
The MD5 I calculate on my machine is: aa7786cc9cac5a66e1064ab1c63b87e2
The MD5 according to the md5.txt file is: 598db33adff41155f26e244e492916d0
-
Hi FlyingDutchman
That md5.txt file looks like it was a remnant for the TC11 corepure64.gz file.
corepure64.gz and corepure64.gz.md5.txt reposted.
-
For some reason xtables-addons-3.13 builds on 32-bit, but xtables-addons-3.15 does not. It fails with:
make[3]: Entering directory '/mnt/sdb1/lamp32-12/kernel/linux-5.10.3'
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/ACCOUNT/xt_ACCOUNT.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/pknock/xt_pknock.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/compat_xtables.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_CHAOS.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_DELUDE.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_DHCPMAC.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_DNETMAP.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_ECHO.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_IPMARK.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_LOGMARK.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_PROTO.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_SYSRQ.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_TARPIT.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_condition.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_fuzzy.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_geoip.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_iface.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_ipp2p.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_ipv4options.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_length2.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_lscan.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_psd.o
CC [M] /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/xt_quota2.o
MODPOST /mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/Module.symvers
ERROR: modpost: "__divdi3" [/mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/pknock/xt_pknock.ko] undefined!
This isn't a problem in 64-bit. It's a problem with TC 11 32-bit too. Basically, xt_pknock has been updated to use ktime_get_seconds() which I think is causing the breakage. Anyone know if there is a gcc option or some other magic to fix this?
-
Hi andyj
ERROR: modpost: "__divdi3" [/mnt/sdb1/lamp32-12/build/xtables-addons-3.15/extensions/pknock/xt_pknock.ko] undefined!
The error is because __divdi3 is for doing a 64 bit division on a platform that doesn't support it:
https://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html#Integer-library-routines
This seems to have a very good explanation and possible solution:
https://embdev.net/topic/129575
-
The kernel doesn't export symbols that no module uses. So it could be that no original module used 64-bit divisions, in the 32-bit build.
CONFIG_UNUSED_SYMBOLS is not set, but TRIM_UNUSED_SYMBOLS is not set either.
https://github.com/lwfinger/rtl8723bu/issues/119 has the same issue, and it says to use do_div if the divisor is constant.
-
I fixed it I think. It compiles anyway, I haven't actually tested the port knocking module. I would post the patch but I get "Internal Server Error" when trying to post it. Here is part of it.
static inline bool
has_logged_during_this_minute(const struct peer *peer)
{
- return peer != NULL && peer->login_sec / 60 == ktime_get_seconds() / 60;
+ unsigned long x = ktime_get_seconds();
+ unsigned long y = peer->login_sec;
+ return peer != NULL && do_div(y, 60) == do_div(x, 60);
}
Thanks to all who helped.
-
That's probably worth submitting upstream, though the time type may be wrong.
-
Hi andyj
I don't understand the point of the division operation here. What is being tested here appears to be:
if a/c == b/c
to which my response would be:
then a == b
So testing peer->login_sec / 60 == ktime_get_seconds() / 60 for equality would yield the same result
as testing peer->login_sec == ktime_get_seconds() for equality.
What am I missing here?
-
@Rich Now that you point it out, yes it does not look like the division is necessary. Based on the surrounding code it is probably for consistency but I could clean it up for speed. There is another further down that I did not post that is used as an argument to some other function so it should stay:
+ unsigned long x = ktime_get_seconds();
- epoch_min = ktime_get_seconds() / 60;
+ epoch_min = do_div(x, 60);
@curaga Yes, I believe the time type should be time64_t, but throughout this module long is used so I am going to stick with that.
-
Hi andyj
Forget what I said.
... if a/c == b/c
to which my response would be:
then a == b ...
That's not true for integer math since the remainder gets discarded. I'm guessing the divide by 60 is to convert to
whole minutes and discard any fractional minute.
-
Hi all,
I get a kernel panic after updating to v12.0 in VirtualBox Version 6.1.18 amd64 (Windows host).
The VM is Tiny Core x86.
Is anybody else using TC x86 in Virtualbox?
-
For the benefit of people who think TC is a minor distro and we can't create change in the world:
That's probably worth submitting upstream...
Done: https://www.spinics.net/lists/netfilter-devel/msg70361.html (https://www.spinics.net/lists/netfilter-devel/msg70361.html)
-
Hi andyj.
In the original code check peer for NULL prepends peer->login_sec reference.
static inline bool
has_logged_during_this_minute(const struct peer *peer)
{
- return peer != NULL && peer->login_sec / 60 == ktime_get_seconds() / 60;
+ unsigned long x = ktime_get_seconds();
+ unsigned long y = peer->login_sec;
+ return peer != NULL && do_div(y, 60) == do_div(x, 60);
}
Excuse me for maybe stupid question, but if the
peer == NULL
whould this code work:
unsigned long y = peer->login_sec;
?
-
Hi btlneck
Welcome to the forum.
Nice catch. If peer == NULL then this will segfault:
unsigned long y = peer->login_sec;
Maybe casting the times to a long would work:
return peer != NULL && do_div((long)peer->login_sec, 60) == do_div((long)ktime_get_seconds(), 60);
-
This is a kernel module, so I would expect it to OOPS. There is a lot of "short circuit" type logic throughout this package, so in this case it should be something like this:
- unsigned long x = ktime_get_seconds();
- unsigned long y = peer->login_sec + autoclose_time * 60;
- return peer != NULL && autoclose_time != 0 && time_after(x, y);
+ if (peer != NULL) {
+ unsigned long x = ktime_get_seconds();
+ unsigned long y = peer->login_sec + autoclose_time * 60;
+ return autoclose_time != 0 && time_after(x, y);
+ } else {
+ return 0;
+ }
I can't post the whole patch here because our forum software apparently has a few bugs.
-
Hi andyj
Looks OK. This should work too:
if ((peer == NULL) || (autoclose_time == 0))
return 0;
unsigned long x = ktime_get_seconds();
unsigned long y = peer->login_sec + autoclose_time * 60;
return time_after(x, y);
-
That section of code doesn't have the original presenting problem of long division so it doesn't actually need the check anyway because the short circuit would work in that case, and thanks to trying to avoid our forum bug with patches I didn't post the part I should have:
static inline bool
has_logged_during_this_minute(const struct peer *peer)
{
if (peer != NULL) {
unsigned long x = ktime_get_seconds(), y = peer->login_sec;
return do_div(y, 60) == do_div(x, 60);
} else {
return 0;
}
}
-
Hi andyj
... and thanks to trying to avoid our forum bug with patches I didn't post the part I should have: ...
That explains it. I thought maybe I'd missed something. :)
The compiler won't add any code because of it, but the return 0; doesn't need to be wrapped in an else clause.
-
There are always different ways to code to get the same end result. In most cases I have learned to prefer towards the solution that reads most naturally and explains what is happening so I won't have to figure it out again the next time I look at it. How many times did I do this in my youth:
(https://img.devrant.com/devrant/rant/r_25449_L5u5q.jpg)
Or worse, come behind someone else?
-
There are always different ways to code to get the same end result. In most cases I have learned to prefer towards the solution that reads most naturally and explains what is happening so I won't have to figure it out again the next time I look at it.
Hi, I don't know how I got here, but I suffer from XKCD 386 syndrome so when I saw this I felt the need to point out that there are very good reasons to prefer the early return approach: https://softwareengineering.stackexchange.com/questions/18454/should-i-return-from-a-function-early-or-use-an-if-statement
It's one of those things in programming I feel very strongly about. :P
-
Please note that glibc has been recompiled using uname_hack to force it to compile for i486.
rootfs.gz and the *Core* iso's have been replaced with ones containing the new glibc - as there is no corresponding change to CorePure, the version number has not been changed.
There is no need to update unless you have an i486 or similar.
-
Please note that glibc has been recompiled using uname_hack to force it to compile for i486.
rootfs.gz and the *Core* iso's have been replaced with ones containing the new glibc - as there is no corresponding change to CorePure, the version number has not been changed.
There is no need to update unless you have an i486 or similar.
downloaded, good md5sum, good cd burn(boots fine in other machines), still fails on the amd k6-2 166mhz machine. using debug i get:
traps: wbar[1181] trap invalid opcode ip:b7ac0484 sp:bf97ad58 error:0 in libgcc_s.so.1[b7ac0000+16000]
sorry to be the bearer of bad news.
-
libgcc_s.so.1 and libstdc++.so.6.0.28 have been recompiled using uname_hack to force i486.
rootfs.gz and the *Core* iso's have been replaced with ones containing the new gcc files - as there is no corresponding change to CorePure64, the version number has not been changed.
There is no need to update unless you have an i486 or similar.