Tiny Core Linux
Tiny Core Base => TCB News => Alpha Releases => Topic started by: Juanito on January 03, 2026, 08:33:15 AM
-
Team Tiny Core is pleased to announce that Tiny Core 17.0 Alpha1 is available for public testing:
http://repo.tinycorelinux.net/17.x/x86/release_candidates/distribution_files
http://repo.tinycorelinux.net/17.x/x86_64/release_candidates/distribution_files
This is an alpha level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.
Since this is an alpha cut, we ask that only experienced users test. This cut is not for general use. The features in any alpha are not fixed and may change before a public release candidate is available.
We appreciate testing and feedback.
Changelog for 17.0 alpha1:
* kernel updated to 6.18.2
* glibc updated to 2.42
* gcc updated to 15.2.0
* binutils updated to 2.45.1
* e2fsprogs base libs/apps updated to 1.47.3
* util-linux base libs/apps updated to 2.41.2
* provides.sh: Update scripts to work with https mirrors from mbartlett21
* tce-update: Undo changes around fetchzsync from mbartlett21
* tc-functions: Update https checking from mbartlett21
* tc-functions: Change subshell from mbartlett21
* update-everything: Add /usr/local/bin to PATH from mbartlett21
* shutdown.sh: handle empty lines in /opt/.xfiletool.lst from mbartlett21
* 50-udev-default.rules: expanded input device permissions from bdantas
-
libopenal.tcz is missing from the TCL17 x86_64 repo:
$ tce-load -wil devede
...
wget: server returned error: HTTP/1.1 404 Not Found
md5sum: libopenal.tcz.md5.txt: No such file or directory
Error on libopenal.tczdevede depends on mplayer-cli which depends on libopenal.
-
Hi GNUser
There is no libopenal.tcz. I don't know if there ever was. I searched
all the way beack to TC10 x86_64 and did not find it. There is an
openal.tcz that contains libopenal.so.
mplayer-cli.tcz.dep changed libopenal.tcz to openal.tcz.
Thank you for reporting this.
-
Hi Juanito
xtables-addons-6.12.11-tinycore64.tcz and xtables-addons-6.12.11-tinycore.tcz
don't belong in the 17.x repos, do they?
-
Making a start with a new dir for 17/tce with copied over TCEs. A trap I fall for nearly every time is load something which depends on 16x python and in case it helps
ls -al /usr/local/bin/python3
lrwxrwxrwx 1 root root 9 Jan 4 07:04 /usr/local/bin/python3 -> python3.9
sudo rm -rf /usr/local/bin/python3
sudo ln -s /usr/local/bin/python3.14 /usr/local/bin/python3
# and jwm-full
inxi -S
System:Host: box Kernel: 6.18.2-tinycore64 arch: x86_64 bits: 64
Desktop: JWM v: 2.4.6 Distro: TinyCore 17.0-alpha1
-
after downloading the alsa-modules-KERNEL and graphics-KERNEL
I have sound and with vulkan-tools I have spinning vkcube as expected, so Xorg-7.7-3d is working as expected.
-
Using GUI apps compiletc says missing api headers, probably because I already had the 16x compiletc in 17x TCEDIR....but yellow line I believe claims download is good. Manual download works as expected
tce-load -w linux-6.18_api_headersI did not need to edit the compiletc dep file
-
I am aware I should be testing TCB, but TCEs are also important to me. Running TCE=ps-mem currently using python3.9...I will update later gives clues as to how big a memory hog firefox running 2 tabs one with embedded videos
no firefox (empty code lines removed...bottom line are totals)
sudo ps-mem -S
Private + Shared = RAM used Swap used Program
128.0 KiB + 266.5 KiB = 394.5 KiB 0.0 KiB init
252.0 KiB + 368.5 KiB = 620.5 KiB 0.0 KiB sh
384.0 KiB + 324.5 KiB = 708.5 KiB 0.0 KiB dbus-launch
380.0 KiB + 556.0 KiB = 936.0 KiB 0.0 KiB busybox (2)
720.0 KiB + 275.5 KiB = 995.5 KiB 0.0 KiB dbus-daemon
1.5 MiB + 141.5 KiB = 1.7 MiB 0.0 KiB elogind-daemon
2.7 MiB + 646.5 KiB = 3.3 MiB 0.0 KiB udevd (3)
5.6 MiB + 7.8 MiB = 13.4 MiB 0.0 KiB jwm
21.5 MiB + 9.7 MiB = 31.2 MiB 0.0 KiB lxterminal
100.8 MiB + 2.6 MiB = 103.3 MiB 0.0 KiB Xorg
156.5 MiB 0.0 KiB
with firefox
sudo ps-mem -S
Private + Shared = RAM used Swap used Program
124.0 KiB + 186.5 KiB = 310.5 KiB 0.0 KiB init
252.0 KiB + 282.5 KiB = 534.5 KiB 0.0 KiB sh
384.0 KiB + 163.5 KiB = 547.5 KiB 0.0 KiB dbus-launch
688.0 KiB + 92.5 KiB = 780.5 KiB 0.0 KiB dbus-daemon
380.0 KiB + 415.0 KiB = 795.0 KiB 0.0 KiB busybox (2)
1.5 MiB + 70.5 KiB = 1.6 MiB 0.0 KiB elogind-daemon
1.8 MiB + 104.5 KiB = 1.9 MiB 0.0 KiB crashhelper
2.7 MiB + 505.5 KiB = 3.2 MiB 0.0 KiB udevd (3)
5.4 MiB + 5.5 MiB = 10.8 MiB 0.0 KiB jwm
14.0 MiB + 9.4 MiB = 23.5 MiB 0.0 KiB lxterminal
57.3 MiB + 22.7 MiB = 80.0 MiB 0.0 KiB Xorg
523.0 MiB + 143.3 MiB = 666.3 MiB 0.0 KiB firefox-bin (12)
790.2 MiB 0.0 KiB
-
Hi aus9
Using GUI apps compiletc says missing api headers, probably because I already had the 16x compiletc in 17x TCEDIR ...
The TC16 compiletc.tcz.dep contains linux-6.12_api_headers.tcz which don't
exist in TC17. That 's why you got the missing headers error.
... I did not need to edit the compiletc dep file
The TC17 compiletc.tcz.dep contains linux-6.18_api_headers.tcz. If you don't
fix the .dep file, it will try to load the linux-6.12_api_headers.tcz which you
shouldn't have in this install.
-
Rich well explained dep file my end adjusted
-
Got my first kind of error booting Xorg-7.7-3d-vulkan in boot list with renamed kernel etc so grub line reads
menuentry "17" {
linux /boot/vmlinuz17 home=LABEL=tc1 tce=/mnt/sdb1/17/tce waitusb=10 quiet lang=en_AU.UTF-8 tz=Australia/Perth blacklist=snd-hda-intel nozswap
initrd /boot/amd-ucode.img /boot/rootfs17.gz /boot/modules17.gz
}
desktop appears ....I pressed Ctrl Alt F1 and saw a rapid moving messgage scroll by
something about udev timeout killing things
I tried to go back to desktop Ctrl Alt F2.....and screen appears blank
warm reboot reset and started a movie to try capture the messages....and this time it behaved
However...I vaguely recall seeing a lot of messages regarding udev and pci and usb
Edit attach 16dmeg.txt
16x Ctrl Alt F1....nothing unusual seen
-
assuming its some of udev rule playing up....I try to get it to play up again by inserting a webcam on usb lead
dmesg gives if interested
[ 449.423148] usb 1-7: USB disconnect, device number 5
[ 478.593691] usb 1-7: new high-speed USB device number 6 using xhci_hcd
[ 479.026996] usb 1-7: Warning! Unlikely big volume range (=3072), cval->res is probably wrong.
[ 479.027005] usb 1-7: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1
[ 479.027201] usbcore: registered new interface driver snd-usb-audio
[ 479.030489] elogind-uaccess-command[5214]: Failed to apply ACL: Operation not supported
[ 479.030532] elogind-uaccess-command[5215]: Failed to apply ACL: Operation not supported
[ 613.766289] usb 1-7: USB disconnect, device number 6
I have multiple mentions of Failed to apply ACL: Operation not supported but true also for the 16x dmesg
and that works fine.....anyone know how I can get the glitch to reappear and log it?
-
@aus9: https://forum.tinycorelinux.net/index.php/topic,27648.msg178644.html#msg178644 (https://forum.tinycorelinux.net/index.php/topic,27648.msg178644.html#msg178644)
here again: is not critical, a fast and dirty search give me something about kernel config#ifdef CONFIG_TMPFS_POSIX_ACLsource: https://blog.tfiu.de/-failed-to-reset-acl-with-elogind-why-.html (https://blog.tfiu.de/-failed-to-reset-acl-with-elogind-why-.html)
-
@nick65go
thanks for that.
@Rich
Does $env need to be made $ENV in the rule /etc/udev/rules.d/73-seat-late.rules
for this part .....$env{ID_SEAT}
ACTION=="remove", GOTO="seat_late_end"
ENV{ID_SEAT}=="", ENV{ID_AUTOSEAT}=="1", ENV{ID_FOR_SEAT}!="", ENV{ID_SEAT}="seat-$env{ID_FOR_SEAT}"
ENV{ID_SEAT}=="", IMPORT{parent}="ID_SEAT"
ENV{ID_SEAT}!="", TAG+="$env{ID_SEAT}"
TAG=="uaccess", ENV{MAJOR}!="", RUN+="/usr/local/lib/elogind/elogind-uaccess-command %N $env{ID_SEAT}"
LABEL="seat_late_end"
-
@Rich
forget that....just logged into voidlinux they too use lowercase
ACTION=="remove", GOTO="seat_late_end"
ENV{ID_SEAT}=="", ENV{ID_AUTOSEAT}=="1", ENV{ID_FOR_SEAT}!="", ENV{ID_SEAT}="seat-$env{ID_FOR_SEAT}"
ENV{ID_SEAT}=="", IMPORT{parent}="ID_SEAT"
ENV{ID_SEAT}!="", TAG+="$env{ID_SEAT}"
TAG=="uaccess", ENV{MAJOR}!="", RUN{program}+="/usr/libexec/elogind/elogind-uaccess-command %N $env{ID_SEAT}"
LABEL="seat_late_end"
-
OK managed to photo with handheld camera the K messages scrolling by
Image names are left for left side of monitor and right
right is
https://i.postimg.cc/P5JZHnPn/right.png
To save you clicking it --reads
/sbin/modprobe -bv acpi:PNP0C02 [changing number in this field]
left side is
https://i.postimg.cc/B6RsjDCn/left.png
to save you clicking it --reads SNIP numbers
udevd timeout: killing /sbin/modprobe as per right image
-
Now I attempt to look at ACL as per link
https://www.linuxbash.sh/post/enabling-and-managing-acls-on-filesystems
my system is on /dev/sdb1 and
tune2fs -l /dev/sdb1 | grep "Default mount options:"
Default mount options: user_xattr acl
So next I edit my fstab so it reads
/dev/sdb1 /mnt/sdb1 ext4 users,exec,acl 0 1
and full reboot but dmesg still shows Failed to apply ACL: Operation not supported
I am not a coder but maybe its my rootfs I need to check?
getfacl /dev
getfacl: Removing leading '/' from absolute path names
# file: dev
# owner: root
# group: staff
user::rwx
group::rwx
other::r-x
beyond my pay scale at this point
-
xtables-addons-6.12.11-tinycore64.tcz and xtables-addons-6.12.11-tinycore.tcz
don't belong in the 17.x repos, do they?
Correct - removed, thanks
-
Hi Juanito
xtables-addons-6.12.11-tinycore64.tcz and xtables-addons-6.12.11-tinycore.tcz
don't belong in the 17.x repos, do they?
I'm working on those.
-
This little tidbit from the GCC 15 changes page is proving to be a challenge for several of the extensions I maintain:
To aid the transition to C23, various diagnostics have been enhanced to clarify type errors such as incompatible function types, incorrect argument counts, and those involving bool.
I know that a lot of extensions are being copied from earlier TCL releases because they seem to run, but could they be complied on the newest release? Should this be one of the tests?
-
Does this mean I have to recompile mariadb:
lto1: fatal error: bytecode stream in file '/tmp/tcloop/mariadb-12.1-dev/usr/local/mysql/lib/libmariadb.a' generated with LTO version 14.0 instead of the expected 15.1
-
I confirm that python3.14 works for updated yt-dlp I am submitting
-
I know its early days....I can not see python3.14-pip and can work around it but python complained
python3.14 setup.py install --prefix=/usr/local --root=/tmp/$P
SNIP
Please avoid running ``setup.py`` directly. Instead, use pypa/build, pypa/installer or other standards-based tools.and gave a link
https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html
SNIP setup.py install -> pip install
thanks for reading
-
I can not see python3.14-pip and can work around it but python complained
pip is provided by python3.14
-
oops
-
I know that a lot of extensions are being copied from earlier TCL releases because they seem to run, but could they be complied on the newest release? Should this be one of the tests?
There are usually some problems with compiling with a new major version of gcc, but this is gcc-15.2.0, so it's been out a while, so you would think that most problems have been ironed out.
For the issues related to c23, you could try building with an earlier version of the c/c++ standards specified?
-
Does this mean I have to recompile mariadb:
lto1: fatal error: bytecode stream in file '/tmp/tcloop/mariadb-12.1-dev/usr/local/mysql/lib/libmariadb.a' generated with LTO version 14.0 instead of the expected 15.1
That's the first time I've seen such an error - are you using python3.14? Would using "-fno-lto" help?
As an aside, when I compile the few extensions I maintain that include static libraries, I make a second pass without lto specifically for the static libs, because otherwise they will be massively inflated in size by lto.
-
For the issues related to c23, you could try building with an earlier version of the c/c++ standards specified?
I did set some to use -std=gnuc17 which solved some problems. However, I'm getting this with Postgresql 16+ (earlier versions don't have this problem, and none of them did in TCL 16):
/usr/local/bin/msgfmt: Cannot convert from "ISO-8859-1" to "UTF-8". msgfmt relies on iconv(). This version was built without icon
Did something change that could affect this?
-
That's the first time I've seen such an error - are you using python3.14? Would using "-fno-lto" help?
As an aside, when I compile the few extensions I maintain that include static libraries, I make a second pass without lto specifically for the static libs, because otherwise they will be massively inflated in size by lto.
Recompiling mariadb fixed the issue. Regarding the static libraries, mariadb uses cmake. I looked through the various cmakefile's and I didn't find anything that I thought looked like it would have the same affect as --disable-static would.
As for python, I don't use it intentionally so I don't know what version is being used.
-
/usr/local/bin/msgfmt: Cannot convert from "ISO-8859-1" to "UTF-8". msgfmt relies on iconv(). This version was built without iconv
Did something change that could affect this?
gettext is updated in tc-17, but I have seen this error from time to time in previous versions.
Sometimes loading glibc_apps/glibc_gconv/glibc_i18n_locale has solved the problem and once I removed the test for iconv in a configure script and the resulting app worked...
-
I didn't find anything that I thought looked like it would have the same affect as --disable-static would.
In those cases I build with lto and keep the result in a safe place, discarding the static libs, then rebuild without lto and keep only the static libs
-
Sometimes loading glibc_apps/glibc_gconv/glibc_i18n_locale has solved the problem and once I removed the test for iconv in a configure script and the resulting app worked...
This is what I have now:
tc@box:/mnt/sdb1/lamp$ tce-status -i|grep glibc
glibc_add_lib
glibc_apps
glibc_base-dev
glibc_gconv
glibc_i18n_locale
I also have this:
tc@box:/mnt/sdb1/lamp$ tce-status -i|grep icu
icu67
icu70
icu74
icu74-bin
icu74-dev
Maybe this is the problem. I just have to find out why I'm getting icu67 and icu70 pulled in since I'm not doing it in a script.
I just have to look in here:
tc@box:/mnt/sdb1/lamp$ tce-status -i|wc -l
490
-
I feel like I'm doing the first part, what does the second part do?
In those cases I build with lto and keep the result in a safe place, discarding the static libs, then rebuild without lto and keep only the static libs
export CC="gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe -fno-strict-aliasing -I/usr/local/include/ncursesw"
export CXX="g++ -flto -fuse-linker-plugin -mtune=generic -Os -pipe -fno-strict-aliasing -I/usr/local/include/ncursesw -fpermissive"
The static libraries get put in the -dev extension. How does this compare to what the second part above does?
-
What I mean to say is that I compile the source once using -flto, but discard the static libs (which can be up to 10x larger than the static libs compiled without -flto).
I then compile the source again without using -flto and keep only the static libs -i.e. using you example: export CC="gcc -mtune=generic -Os -pipe -fno-strict-aliasing -I/usr/local/include/ncursesw"
export CXX="g++ -mtune=generic -Os -pipe -fno-strict-aliasing -I/usr/local/include/ncursesw -fpermissive"
-
Hi there, I've encountered issues running iptables (1.8.11 legacy) on Core x86 (Tiny Core 17.0 Alpha).
Is there anything I'm missing?
"sudo depmod -a" has no effect.
Should I recompile iptables to be compatible with kernel 6.18.2?
tc@box:~$ sudo modprobe ip_tables
modprobe: module ip_tables not found in modules.dep
tc@box:~$ sudo modprobe ip6_tables
modprobe: module ip6_tables not found in modules.dep
tc@box:~$ sudo iptables -L -n
modprobe: module ip_tables not found in modules.dep
iptables v1.8.11 (legacy): can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
tc@box:~$ uname -r
6.18.2-tinycore
-
Zhe
Until you get a better repy I see that repo has both the 32 bit and the 64 bit modules
http://tinycorelinux.net/17.x/x86/tcz/
ipv6-netfilter-6.18.2-tinycore64.tcz......ipv6-netfilter-6.18.2-tinycore.tcz
try this
tce-load -w ipv6-netfilter-KERNELyou may have accidently downloaded the 64 bit module?
Hmm the dep looks right
http://tinycorelinux.net/17.x/x86/tcz/iptables.tcz.dep
Did you check for updates in Apps?
-
Hi, aus9
I checked, this is my tcz list.
/mnt/sda1/tce/optional/ipv6-netfilter-6.18.2-tinycore.tcz
/mnt/sda1/tce/optional/net-sched-6.18.2-tinycore.tcz
I've checked the TCZs available for update, but it seems that there aren't any related to iptables.
-
Hi Zhe
TC16 had ip6_tables.ko.gz in ipv6-netfilter-6.12.11-tinycore.tcz.
It does not exist in TC17 ipv6-netfilter-6.18.2-tinycore.tcz.
Searching provides.db all the way back to TC10 showed no sign
of ip_tables.ko ever existing.
-
Hi Rich.
Thanks for your time. It seems like it's time to switch from iptables to nftables.
The ip_tables.ko module does exist in kernel 6.12.11—I was able to use it normally before.
Until I figure things out, I'll stick with using nftables for now.
I just have a bit of concern about the memory spike that occurs when nftables handles large tables with over 100,000 records—though I may not end up needing tables that large.
Besides, what do other people think about enabling full eBPF support in the kernel?
For example
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y
CONFIG_CGROUPS=y
CONFIG_KPROBES=y
CONFIG_NET_INGRESS=y
CONFIG_NET_EGRESS=y
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_CLS_BPF=m
CONFIG_NET_CLS_ACT=y
CONFIG_BPF_STREAM_PARSER=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
CONFIG_DEBUG_INFO_BTF=y
CONFIG_KPROBE_EVENTS=y
CONFIG_BPF_EVENTS=y
-
Hi Zhe
... The ip_tables.ko module does exist in kernel 6.12.11—I was able to use it normally before. ...
I searched the TC16 repo and ip_tables.ko does not show up anywhere.
I booted up TC16 and searched /lib/modules/... to see if it was included in base.
It was not.
I checked http://tinycorelinux.net/16.x/x86/release/src/kernel/config-6.12.11-tinycore
and found this:
# IP: Netfilter Configuration
CONFIG_IP_NF_IPTABLES_LEGACY=y
----- Snip -----
CONFIG_IP_NF_IPTABLES=yThis shows both versions of iptables were built into the kernel. That means no
loadable modules were created.
I then checked http://tinycorelinux.net/17.x/x86/release/src/kernel/config-6.18.2-tinycore
and found this:
# IP: Netfilter Configuration
CONFIG_IP_NF_IPTABLES=yIt appears the legacy version may have been dropped. Maybe that's what caused your issue.
-
Hi Zhe
One more thing, IP6_NF_IPTABLES_LEGACY also disappeared from:
http://tinycorelinux.net/17.x/x86/release/src/kernel/config-6.18.2-tinycore
-
Hi Rich
I am on x86_64. I built a software firewall called iptables-nft.....and can remember that it worked on the release I built it on 15x....just tested and it fails on 16x and 17x with a similar module issue. It has v4 ruleset and an empty v6 as I had no-one to cheat off. I will try to build my TC64 TCE on 17x and report if I can get around this module issue. We can then look at v6 ruleset. Then we can look at TC32/TC64 build script that Zhe might be able to build for x86
-
Rich
I think someone may need to look at our K modules based on this wiki
https://wiki.nftables.org/wiki-nftables/index.php/Building_and_installing_nftables_from_sources
section=Validating your installation
tce-load -i ipv6-netfilter-KERNEL
ipv6-netfilter-6.18.2-tinycore64 is already installed!
sudo modprobe nf_tables
lsmod | grep nf_tables
nf_tables 200704 0
sudo modprobe nf_tables_ipv4
modprobe: module nf_tables_ipv4 not found in modules.depand last line stops me from going any further
IMHO we need some extra modules. I do not have the 17x config but 16x config does not appear to have all same modules as proposed by wiki
CONFIG_NFT_EXTHDR=m
CONFIG_NFT_META=m
CONFIG_NFT_CT=m
CONFIG_NFT_RBTREE=m
CONFIG_NFT_HASH=m
CONFIG_NFT_COUNTER=m
CONFIG_NFT_LOG=m
CONFIG_NFT_LIMIT=m
CONFIG_NFT_MASQ=m
CONFIG_NFT_REDIR=m
CONFIG_NFT_NAT=m
CONFIG_NFT_QUEUE=m
CONFIG_NFT_REJECT=m
CONFIG_NFT_REJECT_INET=m
CONFIG_NFT_COMPAT=m
CONFIG_NFT_CHAIN_ROUTE_IPV4=m
CONFIG_NFT_REJECT_IPV4=m
CONFIG_NFT_CHAIN_NAT_IPV4=m
CONFIG_NFT_MASQ_IPV4=m
# CONFIG_NFT_REDIR_IPV4 is not set
CONFIG_NFT_CHAIN_ROUTE_IPV6=m
CONFIG_NFT_REJECT_IPV6=m
CONFIG_NFT_CHAIN_NAT_IPV6=m
CONFIG_NFT_MASQ_IPV6=m
# CONFIG_NFT_REDIR_IPV6 is not set
CONFIG_NFT_BRIDGE_META=m
CONFIG_NFT_BRIDGE_REJECT=m
for example I searched for CHAIN_NAT_IPV4 and CHAIN_NAT_IPV6 on 16x config with no hits
-
It looks like iptables is replaced by nftables
@GNUser
I have just spotted you have nftables on x86_64. Does that need any kernel modules?
I have no experience at using it...does it work on 17x?
I cheated off debian wiki does this look Ok to you? I became full root to save typing sudo
root@box:/# nft add table inet filter
root@box:/# nft add chain inet filter input { type filter hook input priority 0\; }
root@box:/# nft add rule inet filter input counter accept
root@box:/# nft list table inet filter
table inet filter {
chain input {
type filter hook input priority filter; policy accept;
counter packets 3 bytes 214 accept
}
}
root@box:/# nft list tables
table inet filter
I have a router firewall so using an external firewall checker will hit against that and any firewall my network provider has too
-
@GNUser
I have just spotted you have nftables on x86_64. Does that need any kernel modules?
Yes, nftables needs several kernel modules. The modules are provided by ipv6-netfilter-KERNEL.tcz, which is a dependency of nftables.tcz.
nftables.tcz is the only extension you need to load. It provides the nft command line tool you need to configure the firewall.
I have no experience at using it...does it work on 17x?
Yes, it's been working perfectly for me since I first tried it with TCL12 Pure64, up until now with TCL17 Pure64.
My wireless router is running TCL17 Pure64, with nftables for firewall. I switched from iptables to nftables back in 2021 and have never looked back: Since the switch, my firewall has been much easier to understand and customize. The only downside is that there still seems to be more documentation/how-tos for iptables than for nftables, but nft is easier to understand and has cleaner syntax than iptables, so that compensates for the relatively scanty online documentation.
-
Hi Rich, happy to find out the root of the problem—thanks for looking into it!
Hi aus9.
nftables can work normally on Core 16.x and 17.x, and you no longer need to run the command "sudo modprobe nf_tables_ipv4".
However, the content at https://wiki.nftables.org/wiki-nftables/index.php/Building_and_installing_nftables_from_sources (https://wiki.nftables.org/wiki-nftables/index.php/Building_and_installing_nftables_from_sources) was last edited on 9 February 2021 at 19:57, so there is a discrepancy with the facts.
Currently, in the x86 software repository, nftables still requires the missing libxtables dependency. I plan to fix this in Core 16.x, while in Core 17.x, I will avoid the dependency on libxtables by disabling xtables.
-
@Rich
as GNUser is confirming his TCE works with current K modules can you remove my TCE=iptables-nft from both 16x and 17x x86_64
Being lazy....I can get by with my router firewall for now but will have to learn nftables.
Optionally can you edit my post called reply 42 and say aus9 withdraws his request to look into K modules and/or delete entire post
or edit the top to say no longer relevant due to reply number 44
thanks
-
Ok this next bit is a gremlin that my brain has not resolved. On another thread I had a built a bash script and Rich suggested it probably needs locale set etc. I thought I would test it....in my boot list called onboot.lst I removed mylocale.tcz tzdata.....and on grub boot line I removed the timezone and booted to test the change.
What I expected was that the bash script should fail....but it was only failing in copying and pasting a foreign (to me font) but was translating a manual input phrase.
so I looked at what apps thought my boot list was and there are differences to my saved file to what Apps thinks I loaded. If interested images expire in one month
https://i.postimg.cc/J7SWBcgs/apps-bootlist.png
to prove I had grub correct from my point of view
https://i.postimg.cc/zXN0MyHh/dmesg-grub-line.png
I have only 2 other boot list files .....onboot.lst-vulkan ( a backup which has no bottom entry of zip)
and xwbar.list a zero byte file
My brain hurts trying to explain this one.....any clues....anyone game to verify they too can get a diff in loading to their own boot list?
to save you clicking either link......apps has extras especially mylocale tcdata and the give away clue
zip at the bottom of list.....near the top apps wants Xorg vulkan while I only wanted Xorg 2d
The removal of the grub tz entry has impacted on the clock showing in screenshot which is to be expected
thanks for reading
-
I copied gettext* from TCL 16 and now all versions of postgresql compile. I don't know what's wrong with the latest gettext because the error message doesn't have any useful information, but I know it's not right.
-
Hi aus9
... What I expected was that the bash script should fail....but it was only failing in copying and pasting a foreign (to me font) but was translating a manual input phrase. ...
That's good. That means the commands in the script were written in plain ASCII, not UTF-8.
Please keep future comments on this topic in your original thread:
https://forum.tinycorelinux.net/index.php/topic,27957.msg180886.html#msg180886
-
I copied gettext* from TCL 16 and now all versions of postgresql compile. I don't know what's wrong with the latest gettext because the error message doesn't have any useful information, but I know it's not right.
As it's difficult to trace the iconv() error, I replaced gettext in the 17.x repos with that from the 16.x repos
-
Hi Juanito
I'm guessing it's probably not the issue, but I ran:
readelf -d /usr/local/bin/msgfmt | grep NEEDEDon the original gettext in TC17 x86_64 and noticed a dependency
on libxml2.so that did not previously exist.
-
It depends on whether gettext was built in the toolchain chroot with very few dependencies present or not - as you say, it’s probably not the source of the issue.
I have seen the same problem in tc-16.x with configure checks not finding iconv in at least a couple of cases.
-
I normally rebuild gettext after the system is running. (Not in a limited chroot environment). But the web is definately getting more tangled.
-
I have lost the ability to have a grub entry lst=filename.lst
I thought it was in /etc/init.d/tc-config under the section called
# Here we check all the boot parameters using the fastest way known to men, case & loop
-
I thought it was in /etc/init.d/tc-config under the section called
# Here we check all the boot parameters using the fastest way known to men, case & loop
It's worse than you think. https://forum.tinycorelinux.net/index.php/topic,23835.msg149704.html#msg149704 (https://forum.tinycorelinux.net/index.php/topic,23835.msg149704.html#msg149704)
-
@Rich
my reply number 47 is completely wrong as I failed to spot that I was editting the 16x onboot.lst
sorry for my poor testing.
Feel free to remove that reply if it misleads anyone
-
@Juanito
I do not blame you if you now dismiss my musings due to recent poor testing. but in ref to
I have seen the same problem in tc-16.x with configure checks not finding iconv in at least a couple of cases.
In attempting to build a 17x python script with gettext-dev and other TCEs I am seeing this in my terminal if interested
pip3 install . # SNIP
/tmp/pip-build-env-o14s3qhd/overlay/lib/python3.14/site-packages/setuptools/config/_apply_pyprojecttoml.py:82: SetuptoolsDeprecationWarning: `project.license` as a TOML table is deprecated
By 2026-Feb-18, you need to update your project and remove deprecated calls or your builds will no longer be supported.
/usr/local/bin/msgfmt: Cannot convert from "ISO-8859-1" to "UTF-8". msgfmt relies on iconv(). This version was built without iconv().
error: command '/usr/local/bin/msgfmt' failed with exit code
its this line that concerns me
By 2026-Feb-18, you need to update your project and remove deprecated calls or your builds will no longer be supported.
-
@Juanito
while we are at the alpha stage, would you consider converting /etc/os-release to UTF-8 ?
due to claims in link.....
The os-release file is expected to be encoded in UTF-8
https://distro.readthedocs.io/en/latest/
file /etc/os-release
/etc/os-release: ASCII text