Recent Posts

1

TCE Talk / Re: Xorg vulnerabilities, again because AI work

« Last post by Franio on October 12, 2026, 05:19:26 PM »

Ok but as long as those security bugs are not remote execute bugs there is little to nothing to worry about. Even if some of them are from remote vector does it mean that standard TCL installation with Xorg-7.7.tcz installed from repo will be exploitable? See, many features are disabled in order to lower depends for packages and in order to save space, memory etc. And I think Xorg doen't listen on 0.0.0.0 by default.

But keep an eye on tools that listens on network interfaces. There was some bugs in busybox dhcp client. Busybox is core of every tcl and other embedded tiny linux distros.

The other thing is there is no LTS (older and mature) kernel to select from and I understand supporting another kernel may cost more but I think LTS are just more secure and more stable (don't comes with regressions). I am going to say the first thing to protect is kernel because Linux is monolithic and single bug in kernel leads to code execution in kernel mode. There are some apis for user space drivers (EL0 drivers in arm) but make rare use of. I suggest 'git clone'ing linux repo, select lts branch, make olddefconfig, and then build kernel Image.gz and you can compile with modules built-in or without. And if single new release comes to world you just do 'git pull' and make recompiles only files that were modified or files that depend on files that were modified by recent release. By making dirty builds you save time and stay secure.

2

TCB Talk / populate /dev with mdev from busybox >1.31

« Last post by nick65go on October 12, 2026, 01:58:21 PM »

With BusyBox 1.38, you are fully covered. Netlink daemon mode (mdev -d) was introduced back in BusyBox 1.31, meaning your version natively supports listening to the kernel's netlink interface without needing the legacy /proc/sys/kernel/hotplug file.
Simply add mdev -d to your startup script after running your initial coldplug scan (mdev -s).

For a classic rcS startup script running under BusyBox 1.38, you can seamlessly integrate the netlink daemon by structure your script sequentially. Because standard rcS scripts run sequentially and expect services to background themselves, using mdev -d is the exact tool for the job. Here is the exact structural sequence you should add to your /etc/init.d/rcS file:

Code: [Select]

#!/bin/sh

# 1. Mount essential virtual filesystems
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t devtmpfs devtmpfs /dev

# 2. Trigger a coldplug scan to discover existing hardware
# This populates /dev before the daemon handles future events
mdev -s

# 3. Launch mdev in daemon mode
# The -d flag tells it to fork into the background and listen via netlink
mdev -d

Why this works perfectly here:
• No blocking: The -d flag implicitly forks mdev into the background. Your rcS script will immediately continue executing subsequent boot commands without stalling.
• Immediate response: Any USB device, MMC card, or network interface plugged in after this line executes will be caught instantly by mdev via the kernel netlink layer.

Code: [Select]

./busybox mdev --help
BusyBox v1.38.0 (2026-07-24 11:50:59 UTC) multi-call binary.

Usage: mdev [-vS] { [-s] | [-df] }

        -v      Verbose
        -S      Log to syslog too
        -s      Scan /sys and populate /dev
        -d      Daemon, listen on netlink
        -f      Run in foreground

Bare mdev is a kernel hotplug helper. To activate it:
        echo /sbin/mdev >/proc/sys/kernel/hotplug

It uses /etc/mdev.conf with lines
        [-][ENV=regex;]...DEVNAME UID:GID PERM [>|=PATH]|[!] [@|$|*PROG]
where DEVNAME is device name regex, @major,minor[-minor2], or
environment variable regex. A common use of the latter is
to load modules for hotplugged devices:
        $MODALIAS=.* 0:0 660 @modprobe "$MODALIAS"

If /dev/mdev.seq file exists, mdev will wait for its value
to match $SEQNUM variable. This prevents plug/unplug races.
To activate this feature, create empty /dev/mdev.seq at boot.

If /dev/mdev.log file exists, debug log will be appended to it.mdev -d is generally faster and significantly lighter than udev, particularly regarding resource consumption and boot times on embedded or minimalist Linux systems. The introduction of the daemon mode (-d) in BusyBox version 1.31 radically improved mdev performance, closing the main efficiency gap it previously had with udev

Why mdev -d is Faster
1. No Forking Overhead per Event: Historically, mdev operated as a kernel hotplug helper, forcing the kernel to fork and execute a new mdev process for every single hardware event. Running mdev -d launches it as a persistent daemon that listens to kernel netlink events directly. This completely eliminates process creation overhead during bursts of events.
2. Reduced Feature Bloat: udev manages advanced state stores, coordinates complex hardware database queries (hwdb), handles persistent device naming schemes, and integrates deeply with systemd. mdev -d strips all of this away to focus entirely on parsing kernel uevents and creating nodes in /dev.
3. Optimised Coldplugging: During system boot, mdev -d processes initial device discovery (coldplugging) without needing a secondary scanning tool (like mdev -s), allowing the system to populate device trees in a fraction of the time.

The Trade-off
While mdev -d wins on pure speed and memory footprint, it lacks the complex feature set of udev. Modern desktop environments (like GNOME or KDE) and display servers rely heavily on udev's subsystem tracking. If you are building a containers-based architecture, an embedded system, or a lightweight distribution (like Alpine Linux or postmarketOS), mdev -d offers vastly superior performance
FYI: A.I. help was used, and technically was correct as I search also other sources.

3

Off-Topic - Tiny Core Lounge / Re: Off topic: how do you spot the people who really grow a small community?

« Last post by MurrayMof86 on October 12, 2026, 05:20:34 AM »

Small follow-up for anyone searching this later: what finally worked for us was a lightweight invite tracker, the kind that drops people who leave within a few days. Numbers have stayed honest since.

4

TCB Talk / Re: connecting a smart phone to OS

« Last post by Rich on October 11, 2026, 04:59:20 PM »

Hi JunkYard

...

Somewhere in your phones menus there should be a section
for controlling various settings. There should be a section for
controlling how the USB port behaves. The default setting for
the USB port is probably  Charging.  You would need to change
that setting to  File Transfer  or similar.

... I found it in the "app" program. ...

After you found and highlighted it in the app program, you need
to click the  Go  button to download and install it.

... Without cutting the wire to see there is no actual was of telling if there are 2 or 4 wires inside of it

Yes. Install  usb-utils  and with the phone connected and powered
on, run:

Code: [Select]

lsusband check if you see any references to your phone. If you do, it's
a data cable. If not, it could mean it's not being seen due to the
USB port mode setting or a missing software driver or the cable is
only a USB Power cable.

5

TCB Talk / Re: connecting a smart phone to OS

« Last post by JunkYard on October 11, 2026, 02:42:09 PM »

Hi JunkYard
Also, make sure you are using a USB Data cable, not
a USB Power cable.

Its a special phone connector plug to a usb female port. that then plugged into a 1 meter male to male usb cable then into my computer. Without cutting the wire to see there is no actual was of telling if there are 2 or 4 wires inside of it

6

TCB Talk / Re: connecting a smart phone to OS

« Last post by JunkYard on October 11, 2026, 02:38:51 PM »

Hi JunkYard
Did you Did you change your phones USB connection mode from
Charging  to  File Transfer?

Did you install any software to support mounting an Android based
phone, such as  simple-mtpfs.tcz  for example?

You might need to ask Google how to use that software.

How do you download that please? I found it in the "app" program. Im pressing the enter key and its doing nothing (see attachment)

7

Off-Topic - Tiny Core Lounge / Re: Find cause for crashes on my VIA EDEN 500MHz 1core 32bit cpu

« Last post by Stefann on October 11, 2026, 04:57:50 AM »

small update, I think I get to some sort of conclusion:

Summary:
- Doing non-logic-changing modifications to the kernel changes Like custom built instead of download built or adding diagnostics to a custom built can change the crash behavior from minutes to weeks or verse versa.
- This makes me conclude the driving mechanism is a very rare race condition.
- I donot think this is in the "most commonly used part of the kernel" because "although rare", frequency is way to high to be a common problem.
- For that reason this is more likely to be a driver-specific problem and most likely in a "not so widely used driver".
- My biggest suspect is the 8139too.c Realtek network driver. This driver is used for some ancient 8139 network chips. More modern 8139 network chips use the 8139cp.c driver which seems to be coded a bit more robust. My [10ec:8139 rev 10] chip however cannot handle that driver.

My current configuration:
- custom built TC171 kernel with persistant ram configuration (otherwise standard).
- self built modified 8139too.c driver as kernel extension. Only diagnostics is added, logic has not been changed so this should crash just as hard as before. Diagnostics is added to a driver level tx timeout function. This function is almost never executed, I have not seen a single execution of this function over past 44 hours. So.. even if this function is as bad as "always crash" it could explain the rare crash observations.
- I have confirmation the driver is operational. I included a message during initialization to demonstrate that.
- my home application is using write() and using "ignore pipe signal" to avoid that the application crashes on pipe errors from write(). Standard write behavior is to send pipe signal to terminate the application in case of lost pipe but linux should not crash than. This code has been crashing within 2 hours multiple times with other kernel configurations. So... although the code is really correct, it can crash the kernel.
- dedicated stress program to drive cpu load to about 80% and network load to about 90%
- watchdog.tcz and wdt bootcode to reboot linux in case of crash. This actually is a really really good addition. As long as crashing is not so often it is inconvenient but not fatal. As this is controlling my full house as home automation "having the system in lockup for multiple hours" is however very bad. It messes my heating, solar power, battery and car charging.
- save of messages from persistent ram at every reboot

I'm now running without crash for 44hours.
I have no illusion that I have somehow magically fixed things "by not adding any fix" but at least:
- I'm in a workable condition due to the watchdog timer
- I have added diagnostics to the most suspicious driver code
- I have persistant ram that ensures I can check that logging after a crash

watchdog timer and persistant ram are tested and work.

So.....
Don't expect quick followups
But I'm "in the game" again.
The real good thing... I really feel I can now safely abandon TC15 and with that dare to use new functionality, new tcz from TC17.

itself 

rokespecially a driver for so
can made to crashes anywhere between few minutes and few weeks by doing non-logic-changes like: "do custom

8

TCB Talk / Re: connecting a smart phone to OS

« Last post by Rich on October 10, 2026, 09:47:24 AM »

Hi JunkYard
Also, make sure you are using a USB Data cable, not
a USB Power cable.

9

TCB Talk / Re: connecting a smart phone to OS

« Last post by Rich on October 10, 2026, 09:22:55 AM »

Hi JunkYard
Did you Did you change your phones USB connection mode from
Charging  to  File Transfer?

Did you install any software to support mounting an Android based
phone, such as  simple-mtpfs.tcz  for example?

You might need to ask Google how to use that software.

10

TCB Q&A Forum / Re: DVD will mount, but won’t play in VLC.

« Last post by BananaBro69 on October 10, 2026, 09:08:50 AM »

Hi
You could try like Rich says:

You could also try starting rhythmbox from a terminal and see if any
warnings or errors pop up.

Ignore my last post. i forgot to post an update about the Audio CDs, they work now.